Wireshark-dev: Re: [Wireshark-dev] Problem in wireshark pcap
From: Guy Harris <[email protected]>
Date: Wed, 26 Nov 2008 16:43:06 -0800
On Nov 26, 2008, at 1:11 PM, prashanth s wrote:

I am capturing the HTTP traffice on wireshark. However for HTTP POST messages I get in the Protocol Column of wireshark display, IP as the protocol name. And Info column of wireshark reads as "Bogus IP length (0, less than header length 20).
That looks as if the packet data is somehow corrupted.  The IP header  
has a "total length" field, giving the length of the IP datagram (not  
including any link-layer headers); in the packet in the capture file,  
that field has a value of 0, which is not valid - the length includes  
the length of the IP header, so it must be >= the length of the IP  
header, and the header length appears to be the default minimum length  
of 20 bytes.
Could you extract one of those packets into a capture file and send it  
to us, so we can try to figure out what might have happened?
Destination reads like "Sonicwal_**:**:** "
That's presumably the link-layer destination, which is presumably some  
device from SonicWALL:
	http://www.sonicwall.com/

And HTTP POST is actually seen under the tree node "Trailer" under the subtree "Ethernet II "
Ethernet frames have a minimum length of 60 bytes (64 bytes if you  
include the FCS at the end of the frame).  This means that a short  
packet might have to be padded out to that minimum length.
The Ethernet dissector tries to figure out what part of an Ethernet  
packet is data and what part is the padding; the padding is called a  
"trailer".  It can only determine that if the protocol running on top  
of Ethernet has a length field of some sort; IPv4 has such a length  
field.
Unfortunately, in your packet, the length field has a bogus value, so  
the Ethernet dissector thinks the entire IP packet is just padding.
It should actually be decoding as TCP and under TCP it should be HTTP.
That would happen only if there were a valid length field, so that  
Wireshark knows how much of the data after the Ethernet header is the  
IP packet and how much is padding.  That isn't the case, so the IP  
dissector just gives up and doesn't call the TCP dissector, and the  
TCP dissector then can't call the HTTP dissector.