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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
