On Apr 29, 2014, at 11:56 AM, Todd Kleinsasser <Todd.Kleinsasser@xxxxxxxx> wrote:
> Second problem is, Wireshark does not know the packets were sliced.
Then it somehow needs to be told. See my earlier emails.
> All of the TCP analysis is off because wireshark is calculating the packet size wrong. It appears wireshark is calculating the TCP payload length by taking the packet size it saw on the wire (which has been sliced) – Ethernet header – IP header – TCP header. Doesn’t appear to be using the IP packet length in the calculation.
The IP code will, if the IP total length is *less* than the amount of data handed to it by whatever dissector calls it (Ethernet, 802.11, PPP, etc.), set the length of the buffer it processes to the IP total length (which allows the Ethernet dissector to know how much of the packet *isn't* part of the IP datagram and is thus a trailer).
If it's *greater*, however, it doesn't do anything with it.
I'd argue that it should report that as an error, because in *normal* circumstances, that's exactly what it is; an IP datagram with a bogus length that's greater than the actual amount of data in the packet. It should also not set the buffer length, even if it bothers to hand off the payload of the IP datagram to sub-dissectors.
That would, of course, mean that a sliced-by-a-Gigasmart-card packet would be shown as an error, but that's the right thing to do here, as it would've turned up this problem sooner and made it clearer that there needs to be a way to tell Wireshark that the packet was sliced and by how much!
