Ethereal-dev: [ethereal-dev] Packet defragmentation thoughts

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Gilbert Ramirez <gram@xxxxxxxxxx>
Date: Wed, 8 Sep 1999 09:52:13 -0500
I've been thinking about how to best approach packet defragmentation.
We need to be able to defragment ("unfragment"?) packets from multiple
protocols at the same time. I'd like to re-assemble fragmented IP packets,
as well as TCP transmissions, and send those reassembled packets back
through the protocol decoders.

Say we have this trace:

packet 1:  IPX packet
packet 2:  IP frag #0
packet 3:  IP frag #1
packet 4:  IPX packet
packet 5:  IP frag #2 (final)

Upon defragmenting at the IP level, I'd like to see:

packet 1:  IPX packet
packet 4:  IPX packet
packet 5:  UDP (a combination of IP frags #0, #1, and #2).

One way to approach this is to add some fields to the frame_data
struct. When defragmented, we could flag packets #2 and #4 as being
"non-readable" so that they are not added to the CList of packets.
Packet #5 would be flagged as being "defragmented"; the data for that
reassembled packet would exist in some temporary file that we created,
not in the original trace file.

However, without some more magic, all the protocol decoders would have
to take this into account.

Another approach is just to dump the entire trace file, with defragmented
packets and normal packets, to a new trace file.  We still need to flag
the defragmented packets somehow, because the IP header (and esp. the
TCP header) of defragmented packets is going to be non-standard. I imagine
that we'd have to remove some fields from the headers (TCP sequence numbers,
e.g.).

For those people that like to examine really large packet traces, we
could even make our new temporary trace file compressed, and use Ashok's
zlib routines when reading the temporary, defragmented, trace file.

Are there some other thoughts?

--gilbert