Arthur de Jong wrote:

On Wed, 2010-10-13 at 14:17 -0700, Howard Chu wrote:

...

It seems you can workaround this by changing tls_g.c's invocation of gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, that strikes me as fundamentally wrong, since libldap is clearly closing both directions when it gets here. I think the bug is in gnutls_bye(), it shouldn't be waiting indefinitely when it tries to read the peer's Close alert. I'm not sure it should even be trying to read that at all; some peers may never send it.

I can't comment on the GnuTLS API because I haven't used it before. Can you file a bugreport with GnuTLS? Do you need any more input from my end?

What is the GnuTLS version number? Seems like you should be submitting this to their tracker anyway, as the original reporter.

https://savannah.gnu.org/support/?group=gnutls

...

Note that because you're breaking the connection without warning, TCP doesn't know that the connection is gone, so there will be no error detected when gnutls attempts to send its own Close alert. In this case, it will probably block for 2*MSL before getting any further.

In my tests I haven't waited that long (I think). Do you know if there are any problems with using setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on the socket?

I have no idea whether GnuTLS handles asynch I/O properly or not. If you're only setting these options immediately before closing, I don't see why it should cause any problems. But GnuTLS has enough flaws in general that I wouldn't claim it ever does anything right or as expected.