gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data

[Nikos Mavrogiannopoulos]

On 04/09/2012 10:40 AM, Wilmer van der Gaast wrote:

>> Since you received eagain, I think that the promise is kept, there was
>> no blocking. However, this scenario should be improbable in normal TLS.
> Okay, so I did add one interpretation here, which makes sense for normal
> Unix sockets but possibly not for TLS: I'm assuming that EAGAIN here
> means that the operation would've blocked if I didn't make the socket
> non-blocking. (IIRC EWOULDBLOCK is an alias for EAGAIN so it seems like
> a reasonable assumption to me?)

Hello Wilmer,
 By checking your log I believe you are right. I see that you receive
a complete record packet split in many tcp segments and
gnutls_record_check_pending() deceives you by including the incomplete
packets to pending data. Would the attached patch solve the issue you
notice? If it works for you it will be included in the next version.

> So it looks like GnuTLS is indeed trying to read more data from the
> socket even though we still have something buffered?

Indeed this is not correct. The buffered data are not enough to form a
complete record and thus it tries to read. The incomplete data shouldn't
have been included there.

regards,
Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gnutls_record_check_pending-functionality-was-divide.patch
Type: text/x-patch
Size: 3785 bytes
Desc: not available
URL: </pipermail/attachments/20120409/34e24303/attachment.bin>