[Please keep me CC'ed on replies! I'm not on any stunnel lists.]
Stunnel 4.07 and 4.08 don't build under HPUX 10.20. 4.06 appears to build, but doesn't appear to work---with a config file like this, running on the local host:
pid = /usr/local/var/stunnel/stunnel.pid client = yes foreground = yes # debug = debug
[pop3s] accept = 110 connect = our-pop-host:995
...and an attempt like this, using (for instance) Emacs 21.4a's movemail:
movemail po:foner:localhost NEWMAIL [the-password]
...I get an infinite hang. Enabling debugging causes stunnel to spit out an infinite stream of a single line at maximum rate, and seems unaffected by whether I'm trying to connect to it or not:
# stunnel test-stunnel.conf 1900.01.00 00:00:00 LOG5[9738:0]: stunnel 4.06 on hppa1.1-hp-hpux10.20 FORK+POLL with OpenSSL 0.9.7e 25 Oct 2004 1900.01.00 00:00:00 LOG7[9738:0]: Snagged 64 random bytes from /users/foner/.rnd 1900.01.00 00:00:00 LOG7[9738:0]: Wrote 1024 new random bytes to /users/foner/.rnd 1900.01.00 00:00:00 LOG7[9738:0]: RAND_status claims sufficient entropy for the PRNG 1900.01.00 00:00:00 LOG6[9738:0]: PRNG seeded successfully 1900.01.00 00:00:00 LOG6[9738:0]: file ulimit = 60 (can be changed with 'ulimit -n') 1900.01.00 00:00:00 LOG6[9738:0]: poll() used - no FD_SETSIZE limit for file descriptors 1900.01.00 00:00:00 LOG5[9738:0]: 27 clients allowed 1900.01.00 00:00:00 LOG7[9738:0]: FD 3 in non-blocking mode 1900.01.00 00:00:00 LOG7[9738:0]: FD 4 in non-blocking mode 1900.01.00 00:00:00 LOG7[9738:0]: FD 5 in non-blocking mode 1900.01.00 00:00:00 LOG7[9738:0]: SO_REUSEADDR option set on accept socket 1900.01.00 00:00:00 LOG7[9738:0]: pop3s bound to 0.0.0.0:110 1900.01.00 00:00:00 LOG7[9738:0]: Created pid file /usr/local/var/stunnel/stunnel.pid 1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22) 1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22) 1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22) 1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22) [ . . . and forever more . . . ]
I can't imagine that this is supposed to be how debug works, since it's totally useless for debugging if it spits out the same line as fast as it can.
I'm running the stunnel as root, and netstat seems to show that it's bound to port 110, but doesn't seem to indicate any outbound connection from stunnel to our pop host after I invoke movemail.
I have no idea if versions before 4.06 work; I haven't tried. Sure, this is an old OS, but zillions of other things, including the entire GNU toolchain, seem to work on it, so stunnel should, too.
Builds for all three versions I've tried may be found in at the following URLs. Note that 4.07 and 4.08 fail on different files, but in essentially the same way.
http://foner.www.media.mit.edu/people/foner/Sys/stunnel-4.06.build http://foner.www.media.mit.edu/people/foner/Sys/stunnel-4.07.build http://foner.www.media.mit.edu/people/foner/Sys/stunnel-4.08.build
I've done some websearching, and I've searched the stunnel archives at mirt.net, but haven't found anything relevant.
Any clues? Thanks...
[email protected] wrote:
1900.01.00 00:00:00 LOG5[9738:0]: stunnel 4.06 on hppa1.1-hp-hpux10.20 FORK+POLL with OpenSSL 0.9.7e 25 Oct 2004
[cut]
1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22)
The manual (http://docs.hp.com/en/B3921-90010/poll.2.html) claims: [EINVAL] timeout is a negative number other than -1. This bug was fixed in stunnel 4.07. Please upgrade!
BTW: I recommend to upgrade your HP-UX to version 11.0 or higher that supports posix threads.
Best regards, Mike
On Mon, Feb 28, 2005 at 04:29:34AM -0500, [email protected] wrote:
[Please keep me CC'ed on replies! I'm not on any stunnel lists.]
Stunnel 4.07 and 4.08 don't build under HPUX 10.20. 4.06 appears to build, but doesn't appear to work---with a config file like this, running on the local host:
pid = /usr/local/var/stunnel/stunnel.pid client = yes foreground = yes # debug = debug [pop3s] accept = 110 connect = our-pop-host:995...and an attempt like this, using (for instance) Emacs 21.4a's movemail:
movemail po:foner:localhost NEWMAIL [the-password]...I get an infinite hang. Enabling debugging causes stunnel to spit out an infinite stream of a single line at maximum rate, and seems unaffected by whether I'm trying to connect to it or not:
# stunnel test-stunnel.conf
[snip]
1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22) 1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22) 1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22) 1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22) [ . . . and forever more . . . ]I can't imagine that this is supposed to be how debug works, since it's totally useless for debugging if it spits out the same line as fast as it can.
You can fix this particular problem by editing the src/network.c file and replacing the poll() invocation around line 128 with:
retval=poll(fds->ufds, fds->nfds, timeout<0 ? -1 : 1000*timeout);
...as it is in 4.07's network.c.
I'm not sure about the 4.07 and 4.08 build errors; I might take a closer look later on.
G'luck, Peter
On Mon, Feb 28, 2005 at 11:03:13AM +0100, Michal Trojnara wrote:
[email protected] wrote:
1900.01.00 00:00:00 LOG5[9738:0]: stunnel 4.06 on hppa1.1-hp-hpux10.20 FORK+POLL with OpenSSL 0.9.7e 25 Oct 2004
[cut]
1900.01.00 00:00:00 LOG6[9738:0]: daemon_loop: s_poll_wait: Invalid argument (22)
The manual (http://docs.hp.com/en/B3921-90010/poll.2.html) claims: [EINVAL] timeout is a negative number other than -1. This bug was fixed in stunnel 4.07. Please upgrade!
But he says he can't :) And also gives URL's to build logs :)
http://foner.www.media.mit.edu/people/foner/Sys/stunnel-4.07.build
G'luck, Peter
Stunnel 4.07 and 4.08 don't build under HPUX 10.20. 4.06 appears to build, but doesn't appear to work---with a config file like this, running on the local host:
Yes, there is a bug with Stunnel -4.06. Yes, it will hang on HP-UX mchines because of the infinite loop error with daemon_loop ( ). And a patch was released to overcome this.
you can find the information about this on the list's archives at; http://mirt.net/pipermail/stunnel-users/2004-December/000224.html
I have attached that patch with this mail. Also I was able to compile stunenl- 4.07 on HP-UX 11.11 and 11.22, So it must compile on 10.20 series. Anyway post errors clearily on the list, we will help you.
-- Senthil Prabu.S
Date: Mon, 28 Feb 2005 11:35:59 +0100 From: "Michal Trojnara" [email protected]
Peter Pentchev wrote: > But he says he can't :) And also gives URL's to build logs :)
Oops. Sorry. Here is the patch for stunnel 4.08: ftp://stunnel.mirt.net/stunnel/socklen_t.patch
Thank you! 4.08 now builds and works on HPUX 10.20. Much appreciated!
[Thank you also to [email protected] to the pointer into the archives, but I can see why I didn't find it: (a) that message came in a couple days -after- I first tried to build 4.06 and went on to other issues when it seemed buggy, and (b) when I did another search yesterday, I never would have realized it even described the same bug: the actual message in the archive doesn't even say what the bug -was-, and following the pointer to the patch reveals only the patch---the only clue is the name of the patch, namely poll_timeout, but doesn't mention, e.g., "poll_wait", which is what occurs in the error message...]
Date: Mon, 28 Feb 2005 12:45:22 -0500 (EST) From: [email protected]
Date: Mon, 28 Feb 2005 11:35:59 +0100 From: "Michal Trojnara" [email protected]
Peter Pentchev wrote: > But he says he can't :) And also gives URL's to build logs :)
Oops. Sorry. Here is the patch for stunnel 4.08: ftp://stunnel.mirt.net/stunnel/socklen_t.patch
Thank you! 4.08 now builds and works on HPUX 10.20. Much appreciated!
Whoops!
I spoke too soon. Now stunnel cores after each connection is closed:
# /usr/local/src/stunnel-4.08/src/stunnel test-stunnel.conf 1900.01.00 00:00:00 LOG5[16181:0]: stunnel 4.08 on hppa1.1-hp-hpux10.20 FORK+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004 1900.01.00 00:00:00 LOG7[16181:0]: Snagged 64 random bytes from /users/foner/.rnd 1900.01.00 00:00:00 LOG7[16181:0]: Wrote 1024 new random bytes to /users/foner/.rnd 1900.01.00 00:00:00 LOG7[16181:0]: RAND_status claims sufficient entropy for the PRNG 1900.01.00 00:00:00 LOG6[16181:0]: PRNG seeded successfully 1900.01.00 00:00:00 LOG6[16181:0]: file ulimit = 60 (can be changed with 'ulimit -n') 1900.01.00 00:00:00 LOG6[16181:0]: poll() used - no FD_SETSIZE limit for file descriptors 1900.01.00 00:00:00 LOG5[16181:0]: 27 clients allowed 1900.01.00 00:00:00 LOG7[16181:0]: FD 3 in non-blocking mode 1900.01.00 00:00:00 LOG7[16181:0]: FD 4 in non-blocking mode 1900.01.00 00:00:00 LOG7[16181:0]: FD 5 in non-blocking mode 1900.01.00 00:00:00 LOG7[16181:0]: SO_REUSEADDR option set on accept socket 1900.01.00 00:00:00 LOG7[16181:0]: pop3s bound to 0.0.0.0:110 1900.01.00 00:00:00 LOG7[16181:0]: Created pid file /usr/local/var/stunnel/stunnel.pid 1900.01.00 00:00:00 LOG7[16181:0]: pop3s accepted FD=6 from 127.0.0.1:1614 1900.01.00 00:00:00 LOG7[16181:0]: FD 6 in non-blocking mode 1900.01.00 00:00:00 LOG7[16183:0]: pop3s started 1900.01.00 00:00:00 LOG5[16183:0]: pop3s connected from 127.0.0.1:1614 1900.01.00 00:00:00 LOG7[16183:0]: FD 5 in non-blocking mode 1900.01.00 00:00:00 LOG7[16183:0]: pop3s connecting 18.85.22.50:995 1900.01.00 00:00:00 LOG7[16183:0]: connect_wait: waiting 10 seconds 1900.01.00 00:00:00 LOG7[16183:0]: connect_wait: connected 1900.01.00 00:00:00 LOG7[16183:0]: Remote FD=5 initialized 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): before/connect initialization 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): SSLv3 write client hello A 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): SSLv3 read server hello A 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): SSLv3 read server certificate A 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): SSLv3 read server done A 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): SSLv3 write client key exchange A 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): SSLv3 write change cipher spec A 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): SSLv3 write finished A 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): SSLv3 flush data 1900.01.00 00:00:00 LOG7[16183:0]: SSL state (connect): SSLv3 read finished A 1900.01.00 00:00:00 LOG7[16183:0]: 1 items in the session cache 1900.01.00 00:00:00 LOG7[16183:0]: 1 client connects (SSL_connect()) 1900.01.00 00:00:00 LOG7[16183:0]: 1 client connects that finished 1900.01.00 00:00:00 LOG7[16183:0]: 0 client renegotiatations requested 1900.01.00 00:00:00 LOG7[16183:0]: 0 server connects (SSL_accept()) 1900.01.00 00:00:00 LOG7[16183:0]: 0 server connects that finished 1900.01.00 00:00:00 LOG7[16183:0]: 0 server renegotiatiations requested 1900.01.00 00:00:00 LOG7[16183:0]: 0 session cache hits 1900.01.00 00:00:00 LOG7[16183:0]: 0 session cache misses 1900.01.00 00:00:00 LOG7[16183:0]: 0 session cache timeouts 1900.01.00 00:00:00 LOG6[16183:0]: SSL connected: new session negotiated 1900.01.00 00:00:00 LOG6[16183:0]: Negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 1900.01.00 00:00:00 LOG7[16183:0]: SSL_read returned WANT_READ: retrying 1900.01.00 00:00:00 LOG7[16183:0]: SSL_read returned WANT_READ: retrying 1900.01.00 00:00:00 LOG7[16183:0]: SSL socket closed on SSL_read 1900.01.00 00:00:00 LOG7[16183:0]: Socket write shutdown 1900.01.00 00:00:00 LOG5[16183:0]: Connection closed: 55 bytes sent to SSL, 3410 bytes sent to socket 1900.01.00 00:00:00 LOG7[16183:0]: removing pid file /usr/local/var/stunnel/stunnel.pid
Pid 16181 was killed due to stack growth failure. Possible causes: insufficient memory or swap, or stack size exceeded maxssize. Segmentation fault (core dumped) #
This was caused by this client:
.../emacs-21.4/lib-src/movemail po:foner:localhost NEWMAIL [the-password]
I haven't (yet) attached a debugger, but my guess is that something decides to call itself recursively forever when the connection is closed, and instantly blows the stack. Presumably someone who's actually familar with the code will know immediately what might be going on. (I just tried running gdb on the corefile and gdb claimed "not in executable format: File format not recognized", which is interesting...)
On 2005-02-28, at 22:16, [email protected] wrote:
(I just tried running gdb on the corefile and gdb claimed "not in executable format: File format not recognized", which is interesting...)
Don't forget that core file is the *second* parameter to gdb. 8-)
Best regards, Mike
Date: Mon, 28 Feb 2005 22:23:53 +0100 From: Michal Trojnara [email protected]
On 2005-02-28, at 22:16, [email protected] wrote: > (I just tried running gdb on the corefile and gdb claimed > "not in executable format: File format not recognized", which is > interesting...)
Don't forget that core file is the *second* parameter to gdb. 8-)
Yeah, I know that :) I'm pretty sure that's what I typed, but I don't have that bit of history any more, so maybe I typoed it. Not that it really matters, since I've since discovered that gdb helpfully dumps core when I try to use it on the corefile---the first time, it of course dumped it -over- the existing corefile, so the next time I renamed the original first. But gdb still can't cope with it, and running stunnel directly inside gdb doesn't have anything left for "bt" to show me after the stack blows up.
I can continue to debug this if it's not immediately obvious why the stack is exploding on a closed connection, but at that point I'm going to have to start putting breakpoints in the code and generally put a bunch more time into it---if that's not wasted effort, I'll get started.
-
foner-stunnel＠media.mit.edu -
Michal Trojnara -
Michal Trojnara -
Peter Pentchev -
Senthil Prabu.S