> > Currently, the Ethereal TCP dissector analyzes individual frames as
> > independent entities, so there's no provision for handling higher-level
> > messages that take more than one TCP segment (and Ethereal's IP
> > dissector doesn't reassemble fragmented IP datagrams).
>
> Is there something that does this already?
The "Follow TCP Stream" code does reassemble TCP segments. However, the
result of the reassembly is unavailable to other dissectors.
There is nothing in Ethereal that does IP fragment reassembly, at
present.
> Would this require a Fragement Reassembler plugin perhaps?
There is no provision in Ethereal for plugins to reassemble fragments -
fragment reassembly would be done in the IP dissector, and there's no
place to plug anything into it.
Furthermore, doing it in a plugin would be an error - the ability to
reassemble IP fragments, when Ethereal acquires this capability (and I
believe the intent is that it's "when", not "if", but there's no
schedule for it), should be built into Ethereal, and should be
transparent to dissectors of protocols running atop IP.
The same should apply to TCP segment reassembly, when that capability is
added to TCP (at which point it should be possible to have the "Follow
TCP Stream" code use the results of that reassembly, rather than doing
that reassembly itself).
To do this - and to handle multiple messages in the same TCP segment -
will probably require a mechanism along the lines of the mechanism
Richard Sharpe has discussed, allowing dissectors to attach information
to a frame.
A given frame would have to have information attached to it so that, if
it's part of a fragmented IP datagram, those other frames in that
datagram that are in the capture can be found, so that the
boundaries between higher-level packets that are in that frame can be
found, and so that the other frames in those higher-level packets can be
found.
I.e., it's not as if this can be implemented by something as simple as a
plugin; it'll show up at some point, but I suspect it's not likely to
show up in the near future.
> > There *are* time stamps in the headers in capture files; those are what
> > are used to display the time in the time column in the packet list
> > display, and in the "frame" layer in the packet tree display for a
> > packet.
>
> Would a "generic mail message plugin" to give a "Content of the GMF-1
> message" be needed to get the interact between the "Contents of TCP stream".
On the initial pass through a capture, when it's being read in, the
frames would be dissected in the order in which they exist in the
capture file, which is presumably the order in which they show up on the
network.
In this pass, the TCP dissector would, in a scheme wherein it
reassembles the TCP stream, call dissectors for protocols running atop
it - including *but not limited to* any plugin you do for your protocols
- handing them to those dissectors in the order in which they appear in
the TCP stream, *not* in the order in which they appear on the network.
The higher-level dissectors would have to keep track of higher-level
packet boundaries, and attach to the frames information showing the
higher-level frame boundaries.
When the dissector is called on a frame when, for example, that frame is
clicked on, it would have to use the information attached to the frame
to find the earlier frames, if any, that are part of the first
higher-level packet in that frame, so it can dissect the entire
higher-level packet (unless the information attached to the frame is
sufficient to let it dissect the trailing part of any higher-level
packet whose tail appears at the beginning of that frame), and would
have to do the same for the later frames, if any, that are part of the
last higher-level packet in that frame.
