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/