Carolin Latze <[email protected]> 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 _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
