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.
