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 [EMAIL PROTECTED] On Sat, Nov 29, 2008 at 3:36 AM, prashanth s <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >> [email protected] >> https://wireshark.org/mailman/listinfo/wireshark-dev >> > > > _______________________________________________ > Wireshark-dev mailing list > [email protected] > https://wireshark.org/mailman/listinfo/wireshark-dev > >
_______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
