It definitely looks a little crazy. What is interesting as well, is that the captured frame has an incorrect frame check sequence - "Frame check sequence: 0x0d0a0d0a [incorrect, should be 0xde70a86f]". I don't know whether this is coincidence, but the given FCS value 0x0d0a0d0a can be represented in ASCII as CR LF CR LF. This maybe just a fluke but it is curious, and It would steer to thinking you have some corruption. Is this traffic passing through some HTTP application proxy before you capture it by any chance?
Regards, Martin
MartinVisser99@xxxxxxxxx
On Sat, Nov 29, 2008 at 3:36 AM, prashanth s
<prbanglore@xxxxxxxxx> wrote:
Hi Harris,
thanks for the reply.
I am attaching here a packet that has the bogus IP as the field.
It has the HTTP POST within the bogus IP field.
If you could you tell me what problem is there it would be very helpful for me.
Regards,
Prashanth
On Thu, Nov 27, 2008 at 6:13 AM, Guy Harris
<guy@xxxxxxxxxxxx> wrote:
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.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-dev