[sr #107929] gnutls_record_get_direction() can return the wrong direction after an interrupted gnutls_record_send()
anonymous
INVALID.NOREPLY at gnu.org
Fri Jan 6 19:49:30 CET 2012
URL:
<http://savannah.gnu.org/support/?107929>
Summary: gnutls_record_get_direction() can return the wrong
direction after an interrupted gnutls_record_send()
Project: GnuTLS
Submitted by: None
Submitted on: Fri 06 Jan 2012 06:49:29 PM UTC
Category: Core library
Priority: 5 - Normal
Severity: 4 - Important
Status: None
Privacy: Public
Assigned to: None
Originator Email: philip.allison at smoothwall.net
Open/Closed: Open
Discussion Lock: Any
Operating System: GNU/Linux
_______________________________________________________
Details:
I have noticed some odd behaviour when moving an application from GnuTLS 2.10
to 3.0. Specifically, when using non-blocking sockets,
gnutls_record_get_direction() can return 0 (i.e. read) after an interrupted
call to gnutls_record_send(), in cases where the peer isn't trying to send any
data.
Unless I change our server application code to ignore the return from
gnutls_record_get_direction() except during handshakes, and assume the
direction will always be 0 after an interrupted recv and 1 after an
interrupted send, data transfer between the client and server can hang with
both peers waiting for input. The client is a web browser, Firefox, and so is
unlikely to be the culprit.
A very quick glance at the current HEAD of master (git grep
internals.direction) turns up no code where the direction is ever set to 1!
The last code looking like "internals.direction = 1" was removed by commit
a209eced7ce4fc698d27d16e3403441b452d9c0e.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/support/?107929>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
More information about the Gnutls-devel
mailing list