- stunnel-users - stunnel.org

Trouble between linux client and windows server
by Louis Young 09 Nov '05

09 Nov '05

Hi guys I'm trying to use stunnel between a windows server and a linux client. On the windows server: [VNC] accept = 5901 connect = 5900 and on the linux client: ; VNC server on 192.168.100.57 accept = 5901 connect = 192.168.100.65:5901 But, alas: Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused Trying ::1... telnet: connect to address ::1: Connection refused It's almost as if stunnel isn't listening on that port on the linux client. Any ideas? -- Regards Louis Young Systems Administrator Kwikpay SA (Pty) Ltd

1 1

Re: [stunnel-users] Solaris: new_context, makecontext
by Hans Werner Strube 09 Nov '05

09 Nov '05

Michal Trojnara wrote: > Please try: ftp://stunnel.mirt.net/stunnel/stunnel-4.15b1.tar.gz The changes to common.h and sthreads.c with respect to new_context and makecontext are reasonable. However, there are two problems: 1. Line 92 of sthreads.c, (char *)ctx->ctx.uc_stack.ss_sp+=STACK_SIZE-8; causes a compiler warning: "a cast does not yield an lvalue." 2. The Solaris <9 SPARC peculiarity concerning the third argument of makecontext might be taken into account. Both would be fixed by the following changes. ***Caveat: I do not know how the third argument of makecontext behaves in Solaris x86 for versions <9 vs. >=9. Have no machine to test this. *** sthreads.c.15b1 Wed Nov 9 12:18:18 2005 --- sthreads.c Wed Nov 9 14:56:18 2005 *************** *** 78,85 **** return NULL; } ctx->ctx.uc_link=NULL; /* it should never happen */ ! ctx->ctx.uc_stack.ss_sp=ctx->stack; ! #if defined(__sgi) || (defined(CPU_SPARC) && ( \ defined(OS_SOLARIS2_0) || \ defined(OS_SOLARIS2_1) || \ defined(OS_SOLARIS2_2) || \ --- 78,84 ---- return NULL; } ctx->ctx.uc_link=NULL; /* it should never happen */ ! #if defined(CPU_SPARC) && ( \ defined(OS_SOLARIS2_0) || \ defined(OS_SOLARIS2_1) || \ defined(OS_SOLARIS2_2) || \ *************** *** 88,96 **** defined(OS_SOLARIS2_5) || \ defined(OS_SOLARIS2_6) || \ defined(OS_SOLARIS2_7) || \ ! defined(OS_SOLARIS2_8))) ! (char *)ctx->ctx.uc_stack.ss_sp+=STACK_SIZE-8; #endif ctx->ctx.uc_stack.ss_size=STACK_SIZE; ctx->ctx.uc_stack.ss_flags=0; --- 87,101 ---- defined(OS_SOLARIS2_5) || \ defined(OS_SOLARIS2_6) || \ defined(OS_SOLARIS2_7) || \ ! defined(OS_SOLARIS2_8)) ! #define MCtxA 2 ! #else ! #define MCtxA 1 #endif + #if defined(__sgi) || (MCtxA == 2) + ctx->stack+=STACK_SIZE-8; + #endif + ctx->ctx.uc_stack.ss_sp=ctx->stack; ctx->ctx.uc_stack.ss_size=STACK_SIZE; ctx->ctx.uc_stack.ss_flags=0; *************** *** 121,127 **** if(!ctx) return -1; s_log(LOG_DEBUG, "Context %ld created", ctx->id); ! makecontext(&ctx->ctx, (void(*)(void))cli, 1, arg); return 0; } --- 126,132 ---- if(!ctx) return -1; s_log(LOG_DEBUG, "Context %ld created", ctx->id); ! makecontext(&ctx->ctx, (void(*)(void))cli, MCtxA, arg); return 0; }

1 0

Re: [stunnel-users] Solaris: new_context, makecontext
by Hans Werner Strube 09 Nov '05

09 Nov '05

Alexander Lazic wrote: > The semantics of the uc_stack member of the ucontext_t structure have > changed as they apply to inputs to makecontext(). Prior to Solaris 10, > the ss_sp member of the uc_stack structure represented the high memory > address of the area reserved for the stack. The ss_sp member now > represents the base (low memory address), in keeping with other uses of > ss_sp. > > This change in the meaning of ss_sp is now the default behavior. The > -D__MAKECONTEXT_V2_SOURCE compilation flag used in Solaris 9 update > releases to access this behavior is obsolete. Solaris 9_x86 does not use __MAKECONTEXT_V2_SOURCE, see /usr/include/ucontext.h: *** Solaris 9: #if defined(__MAKECONTEXT_V2_SOURCE) && defined(__sparc) #ifdef __PRAGMA_REDEFINE_EXTNAME #pragma redefine_extname makecontext __makecontext_v2 #else #define makecontext __makecontext_v2 #endif #endif *** Solaris 10: #ifdef __sparc #ifdef __PRAGMA_REDEFINE_EXTNAME #pragma redefine_extname makecontext __makecontext_v2 #else #define makecontext __makecontext_v2 #endif In libc.so.1, __makecontext_v2 is the "new" function and makecontext the "old" one (binary compatible to Solaris 8 and earlier). For Solaris x86, there is only one function makecontext in all versions. Thus the behavior might not have been changed. A small test program in Solaris 9_x86 (have no earlier versions) indicated the "new" behavior.

2 1

IPTables/Stunnel Help needed
by Alaric Dailey 08 Nov '05

08 Nov '05

Ok, I have a fairly complex firewall setup on my Linux box with 7 host IPs, 2 Internet connections, and a DMZ. I need to direct 1 IP to stunnel on the firewall to be forwarded to the mail server in the DMZ on ports 8383, 993, 995 etc.. but leave ports 25, and 3389 forwarded via iptables, can anyone lend a hand?

1 0

Re: [stunnel-users] Solaris: new_context, makecontext
by Hans Werner Strube 08 Nov '05

08 Nov '05

Michal Trojnara wrote: > I had no Solaris 10 to test it... So what's the correct way to detect > Solaris 10? This must probably be done by a modified configure and a new #if or #ifdef. uname -r gives 5.10 for Solaris 10. > Solaris 9 behaves correctly if __MAKECONTEXT_V2_SOURCE is defined (it > is defined in common.h). I've tested this case. Yes, of course. I have not stated anything different. > The manual claims: > The value of > argc must match the number of integer arguments passed to > func, otherwise the behavior is undefined. > (SunOS mion 5.9 Generic_112233-12 sun4u sparc SUNW,Ultra-250) > > I only pass single argument... Yes, but up to Solaris 8 it claimed: The integer value of argc must be one-greater-than the number of arguments that follow argc; otherwise, the behavior is undefined. For 5 arguments, the value of argc must be 6. AfaIk this would also hold for Solaris 9 without __MAKECONTEXT_V2_SOURCE, but this is deprecated. Btw, Solaris 9 and 10 can still handle binaries compiled under earlier versions.

1 0

Re: stunnel 4.14 and openssl 0.9.8a
by MeeAGhost 08 Nov '05

08 Nov '05

I am using stunnel to tunnel my VNC connection. As recent as version 4.12 I have been able to use the libeay32.dll and libssl32.dll files I created with openssl 0.9.X.X using Msys and Mingw with the steps below: 1. I comment out line 910 in the openssl Configure script 2. Create .def for dll's: perl util/mkdef.pl 32 libeay > ms/libeay32.def perl util/mkdef.pl 32 ssleay > ms/ssleay32.def 3. Execute the openssl configure script ./Configure mingw 4. Execute the make for openssl make 5. After the make completes I create the dlls dllwrap --dllname libeay32.dll --output-lib libeay32.a --def ms/libeay32.def libcrypto.a -lwsock32 -lgdi32 dllwrap --dllname libssl32.dll --output-lib libssl32.a --def ms/ssleay32.def libssl.a libeay32.a When I place the resulting dlls on the remote machine with version 4.14installed and establish a VNC connection to machine stunnel crashes and generates a Dr. Watson error. If I revert back to version 4.12 the dlls I created using the steps above --- everything works. If I install the 0.9.7idlls (which come as a part of the 4.14 Win Install package) everything works. I am trying to keep server and clients on the same version of openssl which is why I have been compling new dlls whenever I have upgraded the servers. Is there something unique being done in version 4.14 that prevents dlls created with 0.9.8a from being used? -- Chris

2 3

Solaris: new_context, makecontext
by Hans Werner Strube 08 Nov '05

08 Nov '05

Concerns all versions of sthreads.c using ucontext: As far as I know from the Solaris documentation and some experiments, the context treatment in new_context() is not universally correct. #if defined(__sgi) || (defined(__sparc) && !defined(HAVE___MAKECONTEXT_V2)) ctx->ctx.uc_stack.ss_sp=ctx->stack+STACK_SIZE-8; #else /* not an IRIX or old and buggy Solaris on Sparc */ ctx->ctx.uc_stack.ss_sp=ctx->stack; #endif The first case is wrong for Solaris 10, since HAVE___MAKECONTEXT_V2 is not defined there but the behavior is _always_ as with HAVE___MAKECONTEXT_V2 in Solaris 9 SPARC. (Solaris 9 SPARC behaves like Solaris 7 and 8 SPARC ["old and buggy"] if HAVE___MAKECONTEXT_V2 is not set, and like Solaris 10 if it is set.) In the "old and buggy" case, the third argument of makecontext() should be 2 instead of 1 (although the latter _may_ work). I do not know how this is in Solaris x86. At least, HAVE___MAKECONTEXT_V2 has no meaning there.

3 3

stunnel 4.14 released
by Michal Trojnara 03 Nov '05

03 Nov '05

The ChangeLog entry for stunnel 4.14: Version 4.14, 2005.11.02, urgency: HIGH: * Bugfixes - transfer() fixed to avoid random stalls introduced in version 4.12. - poll() error handing bug fixed. - Checking for dynamic loader libraries added again. - Default pidfile changed from $localstatedir/run/stunnel.pid to $localstatedir/stunnel/stunnel.pid. - Basic SSL library initalization moved to the beginning of execution. * Release notes - This is an important bugfix release. Upgrade is recommended. sha1sum for stunnel-4.14.tar.gz: b2edb3a2473367f2a9f04a877adcb332483a5267 Home page and download: http://stunnel.mirt.net/ Best regards, Mike

2 2

I: error=certificate signature failure
by Pulcini Maddalena 03 Nov '05

03 Nov '05

________________________________ Da: Pulcini Maddalena Inviato: gio 03/11/2005 8.58 A: stunnel Oggetto: I: error=certificate signature failure ________________________________ Da: Pulcini Maddalena Inviato: mer 02/11/2005 17.14 A: stunnel Oggetto: error=certificate signature failure Hi All, someone could help me to understand what happens and what my client needs to verify the peer? Thanks&Regards I configure stunnel in this way: stunnel.conf ================================ client = yes debug=7 cert = client69f.pem key = chiave69.pem cafile=cacert.pem verify = 1 capath= . [telnet] accept = 23 connect = 10.36.3.191:4433 ============================ I put all the files configured above in the same directory where stunnel-4.07.exe runs; I have a machine in which ssl server runs with a certificate signed by the same CA (cacert.pem). The log file is : ====================================== 2005.11.02 16:33:47 LOG5[1456:1084]: stunnel 4.07 on x86-pc-mingw32-gnu WIN32+IPv4 with OpenSSL 0.9.7f 22 Mar 2005 2005.11.02 16:33:47 LOG7[1456:1504]: Snagged 64 random bytes from C:/.rnd 2005.11.02 16:33:47 LOG7[1456:1504]: Wrote 1024 new random bytes to C:/.rnd 2005.11.02 16:33:47 LOG7[1456:1504]: RAND_status claims sufficient entropy for the PRNG 2005.11.02 16:33:47 LOG6[1456:1504]: PRNG seeded successfully 2005.11.02 16:33:47 LOG7[1456:1504]: Certificate: client69f.pem 2005.11.02 16:33:47 LOG7[1456:1504]: Key file: chiave69.pem 2005.11.02 16:33:47 LOG7[1456:1504]: Loaded verify certificates from cacert.pem 2005.11.02 16:33:47 LOG7[1456:1504]: Verify directory set to . 2005.11.02 16:33:47 LOG5[1456:1504]: No limit detected for the number of clients 2005.11.02 16:33:47 LOG7[1456:1504]: FD 156 in non-blocking mode 2005.11.02 16:33:47 LOG7[1456:1504]: SO_REUSEADDR option set on accept socket 2005.11.02 16:33:47 LOG7[1456:1504]: telnet bound to 0.0.0.0:23 2005.11.02 16:34:14 LOG7[1456:1504]: telnet accepted FD=168 from 127.0.0.1:2501 2005.11.02 16:34:14 LOG7[1456:1504]: FD 168 in non-blocking mode 2005.11.02 16:34:14 LOG7[1456:1504]: Creating a new thread 2005.11.02 16:34:14 LOG7[1456:1504]: New thread created 2005.11.02 16:34:14 LOG7[1456:1320]: telnet started 2005.11.02 16:34:14 LOG5[1456:1320]: telnet connected from 127.0.0.1:2501 2005.11.02 16:34:14 LOG7[1456:1320]: FD 192 in non-blocking mode 2005.11.02 16:34:14 LOG7[1456:1320]: telnet connecting 10.36.3.191:4433 2005.11.02 16:34:14 LOG7[1456:1320]: connect_wait: waiting 10 seconds 2005.11.02 16:34:14 LOG7[1456:1320]: connect_wait: connected 2005.11.02 16:34:14 LOG7[1456:1320]: Remote FD=192 initialized 2005.11.02 16:34:14 LOG7[1456:1320]: SSL state (connect): before/connect initialization 2005.11.02 16:34:14 LOG7[1456:1320]: SSL state (connect): SSLv3 write client hello A 2005.11.02 16:34:14 LOG7[1456:1320]: SSL state (connect): SSLv3 read server hello A 2005.11.02 16:34:14 LOG4[1456:1320]: VERIFY ERROR: depth=1, error=certificate signature failure: /C=Siena/O=amtec/OU=elsag/CN=CERTIFICATION AUTHORITY 2.0/description=CA CERTIFICATE/L=Abbadia San Salvatore 2005.11.02 16:34:14 LOG7[1456:1320]: SSL alert (write): fatal: handshake failure 2005.11.02 16:34:14 LOG3[1456:1320]: error stack: 14090086 : error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 2005.11.02 16:34:14 LOG3[1456:1320]: error stack: D089006 : error:0D089006:asn1 encoding routines:ASN1_verify:EVP lib 2005.11.02 16:34:14 LOG3[1456:1320]: SSL_connect: 4077068: error:04077068:rsa routines:RSA_verify:bad signature 2005.11.02 16:34:14 LOG7[1456:1320]: telnet finished (0 left)

1 0

4.14b1+0.9.7i client loop in s_poll_wait/scan_waiting_queue
by Richard.Hall 30 Oct '05

30 Oct '05

Obviously stunnel problems are like London buses - you wait years for one, then two come along inside a week ;-) Having fixed my server-side problems by installing 4.14b1, I now have a problem on the client side. Apologies for the voluminous diagnostics below, but hopefully they will help make the problem clear. I am running Apache + mod_jk, stunneling to a remote JBoss server. The client is stunnel 4.14 on i686-pc-linux-gnu UCONTEXT+POLL+IPv4 with OpenSSL 0.9.7i 14 Oct 2005 When things are running normally, everything is sweetness and light. However, if I 'kill -HUP' the Apache server (eg to do a log rotation), the mod_jk connection to stunnel gets closed, and stunnel goes into a loop. If I enable DEBUG_UCONTEXT in network.c, and add a few lines of diagnostics:- $ diff -c network.c.orig network.c.loop *** network.c.orig Thu Oct 20 08:37:47 2005 --- network.c.loop Thu Oct 27 13:07:10 2005 *************** *** 31,37 **** #include "common.h" #include "prototypes.h" ! /* #define DEBUG_UCONTEXT */ #ifndef USE_WIN32 static int signal_pipe[2]={-1, -1}; --- 31,37 ---- #include "common.h" #include "prototypes.h" ! #define DEBUG_UCONTEXT #ifndef USE_WIN32 static int signal_pipe[2]={-1, -1}; *************** *** 156,167 **** for(i=0; i<ctx->fds->nfds; i++) { ctx->fds->ufds[i].revents=ufds[nfds].revents; #ifdef DEBUG_UCONTEXT ! s_log(LOG_DEBUG, "CONTEXT %ld, FD=%d, (%s%s)->(%s%s)", ctx->id, ufds[nfds].fd, ufds[nfds].events & POLLIN ? "IN" : "", ufds[nfds].events & POLLOUT ? "OUT" : "", ufds[nfds].revents & POLLIN ? "IN" : "", ! ufds[nfds].revents & POLLOUT ? "OUT" : ""); #endif if(ufds[nfds].revents & (POLLIN|POLLOUT)) ctx->ready++; --- 156,170 ---- for(i=0; i<ctx->fds->nfds; i++) { ctx->fds->ufds[i].revents=ufds[nfds].revents; #ifdef DEBUG_UCONTEXT ! s_log(LOG_DEBUG, "CONTEXT %ld, FD=%d, (%s%s)->(%s%s%s%s%s)", ctx->id, ufds[nfds].fd, ufds[nfds].events & POLLIN ? "IN" : "", ufds[nfds].events & POLLOUT ? "OUT" : "", ufds[nfds].revents & POLLIN ? "IN" : "", ! ufds[nfds].revents & POLLOUT ? "OUT" : "", ! ufds[nfds].revents & POLLERR ? "ERR" : "", ! ufds[nfds].revents & POLLHUP ? "HUP" : "", ! ufds[nfds].revents & POLLNVAL ? "NVAL" : ""); #endif if(ufds[nfds].revents & (POLLIN|POLLOUT)) ctx->ready++; I get (with fd=9 being the mod_jk socket, fd=10 the SSL one, and TIMEOUTidle set to 35 seconds for demo purposes) ... 2005.10.27 13:13:42 LOG7[1286:0]: Waiting 35 second(s) for 7 file descriptor(s) 2005.10.27 13:13:42 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:13:42 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:13:42 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:13:42 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:13:42 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:13:42 LOG7[1286:0]: CONTEXT 2, FD=9, (INOUT)->(OUT) 2005.10.27 13:13:42 LOG7[1286:0]: CONTEXT 2, FD=10, (IN)->(IN) 2005.10.27 13:13:42 LOG7[1286:2]: SSL_read returned WANT_READ: retrying 2005.10.27 13:13:42 LOG7[1286:0]: Waiting 35 second(s) for 7 file descriptor(s) 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 2, FD=9, (IN)->(IN) 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 2, FD=10, (IN)->() 2005.10.27 13:13:43 LOG7[1286:2]: Socket closed on read ... ie mod_jk has disconnected. Everything carries on for a while ... 2005.10.27 13:13:43 LOG7[1286:2]: SSL write shutdown 2005.10.27 13:13:43 LOG7[1286:0]: Waiting 60 second(s) for 6 file descriptor(s) 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:13:43 LOG7[1286:0]: CONTEXT 2, FD=10, (INOUT)->(OUT) 2005.10.27 13:13:43 LOG7[1286:2]: SSL alert (write): warning: close notify 2005.10.27 13:13:43 LOG7[1286:2]: SSL_shutdown retrying 2005.10.27 13:13:43 LOG7[1286:2]: SSL doesn't need to read or write 2005.10.27 13:13:43 LOG7[1286:0]: Waiting 60 second(s) for 6 file descriptor(s) 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 2, FD=10, (IN)->(IN) 2005.10.27 13:13:45 LOG7[1286:0]: Waiting 35 second(s) for 7 file descriptor(s) 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 2, FD=10, (IN)->() 2005.10.27 13:13:45 LOG7[1286:0]: CONTEXT 2, FD=9, (OUT)->(OUT) [...] 2005.10.27 13:13:46 LOG7[1286:0]: Waiting 60 second(s) for 6 file descriptor(s) 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 2, FD=10, (IN)->(IN) 2005.10.27 13:13:46 LOG7[1286:2]: SSL_read returned WANT_READ: retrying 2005.10.27 13:13:46 LOG7[1286:0]: Waiting 60 second(s) for 6 file descriptor(s) 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 2, FD=10, (IN)->(IN) 2005.10.27 13:13:46 LOG7[1286:0]: Waiting 35 second(s) for 7 file descriptor(s) 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 2, FD=10, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 2, FD=9, (OUT)->(ERRHUP) ... but eventually we start getting ERRHUP (ie POLLERR | POLLHUP), not OUT, on fd 9, and then we end up in a tight loop of 2005.10.27 13:13:46 LOG7[1286:0]: Waiting 35 second(s) for 7 file descriptor(s) 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 2, FD=10, (IN)->() 2005.10.27 13:13:46 LOG7[1286:0]: CONTEXT 2, FD=9, (OUT)->(ERRHUP) ... until eventually we get [...] 2005.10.27 13:14:23 LOG7[1286:0]: Waiting 2 second(s) for 6 file descriptor(s) 2005.10.27 13:14:23 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:14:23 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:14:23 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:14:23 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:14:23 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:14:25 LOG7[1286:0]: CONTEXT 2, FD=9, (OUT)->(ERRHUP) 2005.10.27 13:14:25 LOG7[1286:0]: Waiting 0 second(s) for 6 file descriptor(s) 2005.10.27 13:14:25 LOG7[1286:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:14:25 LOG7[1286:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:14:25 LOG7[1286:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:14:25 LOG7[1286:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:14:25 LOG7[1286:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:14:25 LOG7[1286:0]: CONTEXT 2, FD=9, (OUT)->(ERRHUP) 2005.10.27 13:14:25 LOG6[1286:2]: s_poll_wait timeout: connection reset 2005.10.27 13:14:25 LOG5[1286:2]: Connection reset: 260 bytes sent to SSL, 24734 bytes sent to socket The problem seems to be in network.c:s_poll_wait(), in the code while(!ready_head) /* no context ready */ scan_waiting_queue(); because poll() returns > 0, but scan_waiting_queue() never sets ready_head because no fd has yielded POLLIN or POLLOUT:- if(ufds[nfds].revents & (POLLIN|POLLOUT)) ctx->ready++; The end result is that we chew up CPU until TIMEOUTidle expires (which is rather a long time if left at the default of 12 hours!!) I have fudged a circumvention as follows (because I couldn't follow the logic well enough to do it cleanly, and time is running out on me, I'm afraid.) $ diff -c network.c.loop network.c *** network.c.loop Thu Oct 27 13:07:10 2005 --- network.c Thu Oct 27 13:05:21 2005 *************** *** 166,172 **** ufds[nfds].revents & POLLHUP ? "HUP" : "", ufds[nfds].revents & POLLNVAL ? "NVAL" : ""); #endif ! if(ufds[nfds].revents & (POLLIN|POLLOUT)) ctx->ready++; nfds++; } --- 166,172 ---- ufds[nfds].revents & POLLHUP ? "HUP" : "", ufds[nfds].revents & POLLNVAL ? "NVAL" : ""); #endif ! if(ufds[nfds].revents & (POLLIN|POLLOUT|POLLERR|POLLHUP|POLLNVAL)) ctx->ready++; nfds++; } ... which seems to solve the problem but produces a rather untidy result:- 2005.10.27 13:17:46 LOG7[1759:0]: Waiting 35 second(s) for 7 file descriptor(s) 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 2, FD=10, (IN)->(IN) 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 2, FD=9, (OUT)->(OUT) 2005.10.27 13:17:46 LOG7[1759:0]: Waiting 35 second(s) for 6 file descriptor(s) 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=3, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=5, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=6, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=7, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 1, FD=8, (IN)->() 2005.10.27 13:17:46 LOG7[1759:0]: CONTEXT 2, FD=9, (OUT)->(ERRHUP) 2005.10.27 13:17:46 LOG3[1759:2]: INTERNAL ERROR: s_poll_wait returned 1, but no descriptor is ready 2005.10.27 13:17:46 LOG5[1759:2]: Connection reset: 260 bytes sent to SSL, 41132 bytes sent to socket ... i.e it sorts itself out quickly, but at the cost of logging an INTERNAL ERROR, which doesn't look very good ;-) As far as I could tell (but haven't shown), everything actually got close'd correctly. As I say, I appear to have a circumvention, so I'm not hanging on a proper fix (unless anyone can see any fatal flaw in what I've done?) Regards, Richard

2 1