Ethereal-dev: Re: [Ethereal-dev] thoughts on reassembly...
> I wanted to add TCP stream reassembly/defragmenting to ethereal,
"Defragmenting"?
Note that TCP itself has no clue about packet reassembly; all it knows
about is byte streams. The protocols running *above* TCP are what put
packet boundaries into the byte stream; I suspect that doing that (as
opposed to byte-stream reassembly) is harder than you might think.
TCP can do *stream* reassembly, which means it could provide TCP
segments to higher-level protocols, in sequence, with no duplicates or
gaps ("no gaps" means that some TCP segments might not *ever* be handed
to higher-level protocols, if the segments that fill the gap aren't in
the capture).
Even that, however, could complicate the workings of Ethereal, as it
would mean that frames would no longer be dissected all at once; a TCP
segment might be "held" until TCP segments earlier in the data stream
are seen. This makes life difficult for
1) Tethereal - unlike Ethereal, it currently doesn't store
frames away for later display, it prints them as they arrive
or as they're read from the capture file;
2) Ethereal with the current GtkClist widget - it has to put an
entry in the packet list, *complete with the Protocol and
Info column strings*, when it first sees the packet, and it'd
have to go back and fix that entry up when the TCP payload
for the packet is dissected;
3) Ethereal when doing an "Update list of packets in real-time"
capture - again, it'd have to go back and update the display
as more of the frame is dissected.
