mainGnuTLS - Support: sr #107929, gnutls_record_get_direction() can...

 
 

sr #107929: gnutls_record_get_direction() can return the wrong direction after an interrupted gnutls_record_send()

Submitter:  None
Submitted:  Fri 06 Jan 2012 06:49:29 PM UTC
   
 
Category:  Core library Priority:  5 - Normal
Severity:  4 - Important Status:  Done
Privacy:  Public Assigned to:  nmav
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 06 Jan 2012 08:46:39 PM UTC, comment #3: 

Thanks for testing. It uses the same method as gnutls 2.10.x to report the direction so I don't think it would have any issue. I've released 3.0.11 including this patch.

Nikos Mavrogiannopoulos <nmav>
Group administrator
Fri 06 Jan 2012 08:37:19 PM UTC, comment #2: 

Yes, this seems to help a lot.  :)

I added a new debug statement to the server, printed whenever record_get_direction returned 0 after an interrupted write, or 1 after an interrupted read.  The statement was printed every time the session hung, and it was always after an interrupted write.

With this patch, things seem to work well again :)  It's hard to be 100% sure, since I couldn't always reproduce the issue, but I haven't yet managed to trigger a failure since applying the patch.

Anonymous
Fri 06 Jan 2012 07:05:49 PM UTC, comment #1: 

Nice catch thank you. Does the following patch fixes the issue you notice?

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=92c407a6981318948e68f731d3201c51fb35d013

Nikos Mavrogiannopoulos <nmav>
Group administrator
Fri 06 Jan 2012 06:49:29 PM UTC, original submission:  

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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-01-06 nmav StatusIn Progress Done
        Open/ClosedOpen Closed
    2012-01-06 nmav StatusNone In Progress
        Assigned toNone nmav

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code