[Winpcap-users] Reassemble fragmented packets

Guy Harris guy at alum.mit.edu
Sun May 25 21:20:22 GMT 2008


Richard Horton wrote:

> I'm currently developing an offline pcap reader to decode some TCP
> traces (the packet payload is a bespoke routing information packet
> used by some of our radios at work) - some of the traces may or may
> not be fragmented. Currently I've got two problems:
> 
> 1. Is there a library function that will do reasembly for me,

Not in libpcap/WinPcap.

However, there is a library that can be used to do reassemble; it's 
called "libwireshark".

No prizes for guessing from the name what application the library is 
part of. :-)

(I.e., the easiest thing to do might be to add your own dissector to 
Wireshark/TShark.)

> 2. A number of trace files I've got containing fragments (including
> some captured HTTP sessions) do not have the MF flag set in the IPv4
> header - without this how am I supposed to know what is/is not
> fragmented?

Fragmentation can occur at many layers.

An IP datagram can be fragmented if it's sent (either by the source host 
or by a router) on a network whose MTU is smaller than the size of the 
datagram.  If so, then all fragments other than the last fragment have 
the MF (More Fragments) bit set, indicating that there are more 
fragments after that fragment.  The last fragment has a non-zero 
fragment offset (because it's not the first fragment) but doesn't have 
the MF bit set (because there are no more fragments after that fragment).

An un-fragmented IP datagram has a fragment offset of 0 (because it's at 
the beginning of the packet, given that it *is* the packet) and doesn't 
have the MF bit set (because there are no fragments after it).

(NOTE: there is no guarantee that the fragments of a fragmented IP 
datagram are in order in a packet trace; you could, for example, have 
the last fragment first in the trace - I think Linux sends packets in 
that order, so that, if the receiver allocates a buffer for the 
reassembled packet as soon as it sees how big the reassembled packet 
will, i.e. when it sees the last fragment, it can allocate the buffer at 
the beginning and not have to expand it as more fragments arrive.)

Fragmentation at the IP layer is most commonly seen with UDP; it's 
rarey, if ever, seen for TCP (TCP implementations attempt to set the TCP 
maximum segment size for a connection so that it's <= the smallest MTU 
on the path between the two endpoints; see "path MTU discovery").

In addition, a packet for a protocol running on top of TCP might be 
fragmented across multiple TCP segments; the service TCP offers is a 
byte stream, so there's no guarantee that higher-level packet boundaries 
correspond to TCP segment boundaries.

Wireshark includes code to handle IPv4/IPv6 fragment reassembly *and* 
reassembly of packets split across TCP segment boundaries.


More information about the Winpcap-users mailing list