#50 Interpreting fragmented packets gives incorrect result

[Rune Jacobsen]

Hi there,

I am reading a pcap that contains an IPv4 packet where the payload was larger than the MTU, so that the packet was fragmented into two packets. I have attached a pcap that I am using as I debug this.

The thing is - when an IP packet is fragmentet, only the FIRST fragment contains a UDP or TCP header. The rest do not, even if they are marked as UDP or TCP in the Protocol field of the IP packet. The transport header isn't there - the IP packet is pure payload to be attached onto the last packet.

Frames 1 and 2 in the attached file are the first and last fragments of my "test packet". If you open this in Wireshark, it handles it correctly.

However, in SharpPcap, we get into a bit of a situation, because it tries to interpret packet 2 as a Udp packet. The 8 bytes that SharpPcap tries to read as a header is part of the payload, not an actual UDP header.

Not a big deal, right? Well, it seems that SharpPcap makes a change to the packet when it interprets it. Since SharpPcap insists on interpreting it, packet.PayloadData is null, and I have to get at packet.PayloadPacket.Bytes instead - but these are not the same as in the original pcap (at least when I compare to Wireshark). From my point of view, it seems like SharpPcap overwrites what whould have been the "Length" field of the UDP header, leading to corrupted data.

These two bytes originally contained 0x3a20 (a colon and a space in ASCII, this is SIP messages I am working on so pretty simple text), but that has been replaced by 0x01F1 (01 dec and 241 dec, junk characters in ASCII) once I read packet.PayloadPacket.Bytes with SharpPcap.

The way I see it, there are two ways to do it:

1. When an IP packet (this goes for IPv4, not sure about IPv6) has a non-zero "Fragmentation offset" value, do not interpret it as a UDP or TCP packet. Just leave the payload as it is.

2. If not interpreting is not an option, make it possible to read the original, unmodified packet bytes from the IP packet.

I don't know if this is easy or doable, but the problem makes it hard to handle IP fragmentation with SharpPcap unfortunately.

Thanks for any efforts to solve this!

[Rune Jacobsen]

I acknowledge that I might have registered this on the wrong project - Packet.Net is probably where this happens.

After looking at it for a bit, my guess would be in IPPacket.ParseEncapsulatedBytes() - but I really don't know the projects well enough to say that for sure.

Do you want me to move this to the other project?

[Rune Jacobsen]

I also forgot to add that 0x01F1 - the bytes overwritten into the packet mentioned above - translates into 497, the actual length of the payload of the IP packet.

So I believe that is the reason for my data corruption in this case. :)