On Nov 30, 2008, at 11:56 PM, Sake Blok wrote:
Well, as the IP length field is 0 instead of the proper length of
the IP
datagram, I think the whole dissection of the IP payload is not done.
This makes the whole TCP segment look like a ethernet trailer,
including
a FCS. Which of course will be incorrect...
Yes, that's what's happening.
I fixed the IP dissector so that it only sets the tvbuff length for
the IP datagram tvbuff after it's determined that the IP total length
isn't obviously bogus (where "obviously bogus" means that it's less
than the IP header length). Doing that means that we don't dissect
the data at the end of the packet as a trailer and FCS.
So the question is: Why is the IP length field set to 0?
Probably either TCP Segmentation Offload or Large Receive Offload -
the network adapter on which the packet was captured probably supports
TSO and/or LRO, and the adapter and/or driver indicate that a sent
packet will be segmented by the adapter and/or that a received packet
has been reassembled by the adapter by providing an IP total length of
0 and a IP header checksum of 0 - I think TSO/LRO on a number of
systems do that.
There's an IP preference "Support packet-capture from IP TSO-enabled
hardware"; if you turn that option on, the IP dissector will assume
that an IP total length of 0 indicates a TSO or LRO packet, and will
set the length to the actual length of the packet data. Doing that
causes the IP payload to be dissected as TCP; if the HTTP reassembly
options are also turned off, the TCP payload is dissected as HTTP.
