[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: supplemental data handshake message
From: |
Simon Josefsson |
Subject: |
Re: supplemental data handshake message |
Date: |
Mon, 03 May 2010 17:45:35 +0200 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) |
Carolin Latze <address@hidden> writes:
> Hi again,
>
> it seems there is a mismatched between the length the sender assumes
> to send (which is the correct length) and the length the receiver is
> able to retrieve out of the buffer. The debug output on the sender
> says the following:
>
> --debug--
> server.log screenshot
> --end debug--
>
> (sorry didn't have time to capture that properly)
>
> The data is indeed 10 bytes long, which results in 14 bytes to be sent
> due to the 2 byte length and type. So, the server.log make sense to
> me. However the client does something strange:
>
> --debug--
> REC[0x954f378]: Received Packet[1] Handshake(22) with length: 14
> REC[0x954f378]: Decrypted Packet[1] Handshake(22) with length: 14
> HSK[0x954f378]: SUPPLEMENTAL was received [14 bytes]
> EXT[0x954f378]: Got supplemental type=01 length=3
> --end debug--
>
> I set the type to 1, so that makes sense as well. However... why does
> it read out a length of 3? It receives the correct packet length of 14
> bytes. It is gnutls_supplemental.c that generates the packet and
> parses it... so I would expect that it would parse it correctly. Any
> ideas or hints?
It is difficult to tell from just description of the problem... Try
printing the entire buffer that is sent by _gnutls_gen_supplement and
the buffer received by _gnutls_parse_supplemental and hand-check that
they are correct and match. Maybe you could push a git branch with your
work somewhere, so we can more easily reproduce the problem?
I suspect it is just a encoding/decoding bug somewhere.
/Simon