I have checked in a fix to stop dissection of the packet when this condition
is detected.
Basically, the IP layer said the fragment is only 16 bytes large.
Thus you would need to enable IP layer reassembly to see the full tcp header
which is minimum 20 bytes.
The change to ethereal i implemented was to just stop dissecting the packet
in the tcp layer if the condition that
either the packet contained <20 bytes of tcp layer data or if not the full
tcp header was seen in the framgent.
Also a simple text message was added to the tree pane to indicate that
someone was either broken or playing
fragmentation games.
tcp packets should never be fragmented since tcp prefers to do this itself
instead of letting the ip layer do it.
I guess the only times this would happen in real life would be:
* fingerprinting by sending unusual packets (nmap which was the case here)
* a completely broken tcp layer which allows ip fragmentation of tcp
segments
* someone playing silly buggers with the tcp header like fragment offset:8
bytes and changing
the tcp flags fields in overlapping subsequent ip fragments to fool
firewalls that are broken to not
deliberately violate rfc1812/5.2.6. I belive that all firewall product
deliberatly violates this
paragraph since the alternative would be bad.
----- Original Message -----
From: "Yaniv Kaul"
Sent: Tuesday, May 20, 2003 1:25 AM
Subject: [Ethereal-dev] Wrong tcp packet dissection?
> Attached please find a single packet from an nmap scan. The packet is
> dissected incorrectly.
> In particular, it seems that the next sequence number is wrong, as well
> as the length.
> I suspect it may be due to the fact the packet's seq=0xffffffff.
>
----------------------------------------------------------------------------
----
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>