Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: [Ethereal-dev] RE: [Ethereal-users] Saving reassembled IP packets?

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

From: Biot Olivier <Olivier.Biot@xxxxxxxxxxx>
Date: Tue, 13 Apr 2004 17:49:22 +0200
|From: Tony Frank
|
|Hi there,
|
|On Tue, Apr 13, 2004 at 03:27:29PM +0200, Biot Olivier wrote:
|> 
|> [Ccing Ethereal-Dev as a FYI (ToDo list item :)]
|
|My comment at end has a more specific suggestion. :)

<snip snip>

|I actually came up with something surprisingly simple that did 
|the trick for me:
|
|1. Display with preference protocol IP reassemble off
|2. Apply display filter to match UDP (matches first frag with 
|UDP header)
|3. Mark all packets
|4. Display with preference protocol IP reassemble on
|5. Apply display filter to match UDP (matches reassembled, or 
|last frag)
|6. Mark all packets
|7. Save as, marked only, captured
|
|This works because in each of my cases there are only two fragments.
|One with 1480 bytes and one with 40 bytes (due to tunneling headers)
|First pass gets the first frag, second pass gets the last frag.
|Probably not useful for the generic case where there might be multiple 
|fragments, or fragmenting occurs in the actual UDP/TCP header etc.
|
|Currently with reassembly on, the displayed packets has the
|ip.fragments field which lists each frame that makes up the
|displayed frame.
|I guess if we do a mark on such a packet it would be ideal if
|ethereal can notice this field and subsequently mark each of the
|listed frames.

A more generic approach requires the following:
1. Ethereal *knows* that a protocol field belongs to a given protocol.
2. Ethereal *knows* all packets involved in the reassembly (which may occur
simultaneously on different levels, e.g., fragmented TCP segments over an IP
network with a small MTU).
3. Ethereal has the means to include the relevant "reassembled packets" if a
reassembled message matches a display filter expression.

For example, display filter "http" will only match packets for which either
no reassembly was required (only one packet) or reassembly was performed
before handing the packet which completed the reassembly to the next
subdissection and where in the end "http" was found. In the former case, the
matching packet is found. In the latter case however, we first need to see
whether TCP or UDP reassembly was used (the HTTP dissector is used for
dissecting a load of protocols that look like HTTP but that run on top of
either TCP or HTTP), and if so we need to select every reassembled
fragment... For all involved reassemblies (e.g., IP reassembly *and* TCP or
UDP reassembly).

Consider the following situation:
1. IP [[TCP segment 1 fragment 1/2: [HTTP SDU fragment 1/3]]
2. IP [[TCP segment 1 fragment 2/2: [HTTP SDU fragment 2/3]]
3. IP [[TCP segment 2:              [HTTP SDU fragment 3/3]]

Packet 2 will contain the reassembled IP data, which is TCP segment 1.
Packet 3 will contain the reassembled TCP data, which is HTTP.
Packet 3 is also the only one that will match "http". Ethereal now must look
at: is the data buffer from packet 3 reassembled from fragments? If so, add
all packets containing an HTTP fragment (packets 2 and 3) to the matching
list. Now the same question must be answered one level lower: Are the data
buffers from packets 2 and 3 reassembled from fragments? This is true for
packet 2, where we need to add packet 1 to the list.

This hierarchy walking is not available (yet).

And to complicate things even more, there will probably be packets that do
not participate in the reassembly as such (TCP ACK, TCP SYN, ...) but which
may contain important information for the dissection.

Regards,

Olivier