#94 Wrong header length on truncated packets

[Sly Technologies]

The native scanner comes up with wrong header length for a certain truncated packet:

JPacket.State#279758057: pkt_wirelen=60
JPacket.State#279758057 : [ Protocol(ID/Flag) | Start | Prefix | Header | Gap | Payload | Postfix ]
JPacket.State#279758057[0]: [ ETHERNET( 1/0800) | 0 | 0 | 14 | 0 | 46 | 0 ]
JPacket.State#279758057[1]: [ IP4( 2/0800) | 14 | 0 | 20 | 0 | 20 | 0 ]
JPacket.State#279758057[2]: [ TCP( 4/0800) | 34 | 0 | 6 | 0 | 20 | 0 ]
JPacket.State#279758057[3]: [ PAYLOAD( 0/0800) | 40 | 0 | 20 | 0 | 0 | 0 ]

Note: under the TCP header length column, the header length is calculated to be 6 bytes (impossible number) while there is still 20 bytes of payload (most likely the remainder of the TCP header). Flags are also wrong, as they do not set the header FRAGMENTed flag on the TCP header.

This occurs extremely infrequently, but none the less is does come up. The user is trying to capture the next invalid packet and provide a hexdump of it for analysis.

[Sly Technologies]

Found a problem in native "validate_sip" function which would erroneously modify the previous header's length. The problem has been fixed and waiting verification from user.

[Sly Technologies]

The issue has been fixed and will be released in the next major or maintenance release. The bug was found and confirmed. Appropriate jUnit test cases have been created to verify that this issue is resolved and will not be broken again by future changes.