[Sake Blok <sake@xxxxxxxxxx>]

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


On Mon, Dec 01, 2008 at 11:16:35AM +1100, Martin Visser wrote:
>    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
> 
>      _______________________________________________
>      Wireshark-dev mailing list
>      Wireshark-dev@xxxxxxxxxxxxx
>      https://wireshark.org/mailman/listinfo/wireshark-dev

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