Re: [fetchmail-devel] timeout not working for TLS

[Matthias A. <mat...@gm...>]

Am 28.04.2011 09:38, schrieb Thomas Jarosch:
> Hello Matthias,
> 
> On Thursday, 5. August 2010 00:18:30 Matthias Andree wrote:
>> The attached patch sets the timeout for the getauth() stage (which
>> entails STARTTLS-like negotiation). Please try that too and see if you
>> get timeout reports while fetchmail tries to negotiate TLS. It should.
>>
>> Thanks for the report and offered help in debugging. Would be good if you
>> could report back in a month or so :-)
> 
> I just had another case of this issue on a different box,
> this time running fetchmail 6.3.18.
> 
> Here's all the info I was able to collect:
> 
> Log from fetchmail:
> fetchmail: POP3< +OK Capability list follows
> fetchmail: POP3< TOP
> fetchmail: POP3< USER
> fetchmail: POP3< UIDL
> fetchmail: POP3< STLS
> fetchmail: POP3< SASL PLAIN
> fetchmail: POP3< IMPLEMENTATION trinity
> fetchmail: POP3< .
> fetchmail: POP3> STLS
> fetchmail: POP3< +OK Begin TLS negotiation

Looks like GMX.

> fetchmail was stuck at that line since 21.04.2011.
> 
> [root@intranator log]# strace -p 1505
> Process 1505 attached - interrupt to quit
> read(3,
> 
> (gdb) bt
> #0  0x00c17424 in __kernel_vsyscall ()
> #1  0x00867ef3 in __read_nocancel () at ../sysdeps/unix/syscall-
> template.S:82
> #2  0x0033771e in sock_read () from /usr/lib/libcrypto.so.8
> #3  0x00000003 in ?? ()
> #4  0x09e7cafe in ?? ()
> #5  0x000006bf in ?? ()
> #6  0x89f4e239 in ?? ()
> #7  0x6ce90be1 in ?? ()
> #8  0xa8a2f11c in ?? ()
> #9  0x60917bce in ?? ()
> #10 0x003c8c28 in ?? () from /usr/lib/libcrypto.so.8
> #11 0x09e762f8 in ?? ()
> #12 0x00000000 in ?? ()
> 
> 
> Even though I installed the -debuginfo packages,
> I wasn't able to get a meaningful backtrace.
> 
> So the stall happens before the authentication state?

Hi Thomas,

what OS and version (distribution) does this happen on?  Do the
-debuginfo packages match the actual RPMs?  Could you try building
6.3.19 from source and use that to somehow reproduce the hang?

I wonder if the SSL stuff somehow masks the timeout alarm we're using,
that could possibly explain things, but I don't have an idea how to
figure that out yet.

Sorry - a backtrace could possibly help a bit because I could try
reading the OpenSSL code paths in the OpenSSL sources.

Best regards
Matthias