Problem in wireshark pcap

[prashanth s]

Hi,
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). Destination reads like "Sonicwal_**:**:** "
And HTTP POST is actually seen under the tree node "Trailer" under the
subtree "Ethernet II "
It should actually be decoding as TCP and under TCP it should be HTTP.
Instead I am seeing IP.

However this has been happening after I installed windows. Earlier I used to
have linux. I never faced any such problems in captured file.
What may be the problem behind this?
If any of you could you assist me with your answers it would be great for
me.

Regards,
Prashanth

[Martin Visser]

Prasanth,

Are you sure you are capturing the full packets (or at least enough for it
to be dissected as HTTP) - check the Capture Options. Also in
Analyze:Enabled Protocols, TCP and HTTP enabled?

Regards, Martin

Post by prashanth s
Hi,
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). Destination reads like "Sonicwal_**:**:** "
And HTTP POST is actually seen under the tree node "Trailer" under the
subtree "Ethernet II "
It should actually be decoding as TCP and under TCP it should be HTTP.
Instead I am seeing IP.
However this has been happening after I installed windows. Earlier I used
to have linux. I never faced any such problems in captured file.
What may be the problem behind this?
If any of you could you assist me with your answers it would be great for
me.
Regards,
Prashanth
_______________________________________________
Wireshark-dev mailing list
https://wireshark.org/mailman/listinfo/wireshark-dev

[Guy Harris]

Post by prashanth s
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?

Post by prashanth s
Destination reads like "Sonicwal_**:**:** "

That's presumably the link-layer destination, which is presumably some
device from SonicWALL:

http://www.sonicwall.com/

Post by prashanth s
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.

Post by prashanth s
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.

[prashanth s]

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

Post by Guy Harris

Post by prashanth s
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?

Post by prashanth s
Destination reads like "Sonicwal_**:**:** "

That's presumably the link-layer destination, which is presumably some
http://www.sonicwall.com/

Post by prashanth s
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.

Post by prashanth s
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
https://wireshark.org/mailman/listinfo/wireshark-dev

[Martin Visser]

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

Post by prashanth s
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

Post by Guy Harris

Post by prashanth s
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?

Post by prashanth s
Destination reads like "Sonicwal_**:**:** "

That's presumably the link-layer destination, which is presumably some
http://www.sonicwall.com/

Post by prashanth s
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.

Post by prashanth s
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
https://wireshark.org/mailman/listinfo/wireshark-dev

_______________________________________________
Wireshark-dev mailing list
https://wireshark.org/mailman/listinfo/wireshark-dev

[Sake Blok]

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...

So the question is: Why is the IP length field set to 0?

Cheers,
Sake

Post by Martin Visser
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
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

Post by prashanth s
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?

Post by prashanth s
Destination reads like "Sonicwal_**:**:** "

That's presumably the link-layer destination, which is presumably some
http://www.sonicwall.com/

Post by prashanth s
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.

Post by prashanth s
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
https://wireshark.org/mailman/listinfo/wireshark-dev
_______________________________________________
Wireshark-dev mailing list
https://wireshark.org/mailman/listinfo/wireshark-dev
_______________________________________________
Wireshark-dev mailing list
https://wireshark.org/mailman/listinfo/wireshark-dev

[Guy Harris]

Post by Sake Blok
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.

Post by Sake Blok
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.