On Thu, Apr 18, 2002 at 10:34:57AM -0400, Andrew C. Feren wrote:
> One of my local users discovered a weird bug. If a user saves their
> colorization preferences and restarts ethereal (or reloads the
> tracefile) desegmentation stops working correctly. (More specifically
> all desegmentation stops. The display looks as if desegmentation were
> disabled.)
To which display are you referring?
I.e., does this affect the packet summary display, or does it affect the
detail display when you click on a packet as well?
Colorization currently causes the summary display to be reconstructed;
it might be possible (and more efficient) to cause colorization of an
existing display merely to change the colors of the rows. I'll look
into that.
The reconstruction involves redissection of the packets (to construct
the protocol tree, so the color filter expression can be re-applied);
however, as no dissection preferences were changed, state information
built during the first dissection pass is *not* discarded.
On the first pass, when the initial summary display is built, the
fully-reassembled packet is available only when the *last* frame
containing data from that packet is dissected; all previous frames will
merely be dissected as an IPv4/IPv6/CLNP/whatever fragment, a chunk of
desegmented TCP, etc., and will show up as such in the summary display.
On subsequent passes, however, the information about the reassembly is
available on all frames, *and*, for some forms of reassembly, *all*
frames containing data from a packet are dissected as reassembled. This
means that, if the summary display is reconstructed, all
fragments/segments/etc. will, if they are being reassembled with those
forms of reassembly, be shown with the summary line for the reassembled
frame.
IPv4/IPv6/CLNP reassembly, and some other forms of reassembly, show all
frames in that fashion.
TCP segment reassembly, in recent releases, does *NOT*.
This means, for example, that if you colorize a display containing
fragmented ONC RPC-over-UDP (e.g., NFS-over-UDP) packets, *all*
fragments of those fragmented packets will get a summary line showing
them as being NFS requests or replies. However, if you colorize a
display containing segmentted XXX-over-TCP (SMB-over-TCP, NFS-over-TCP,
etc.) packets, only the last segment will get that summary line.
However, this should not affect what you see in the protocol tree window
for the packet when you actually click on the packet - and, although I
*have* seen the first of those behaviors (the change to the summary
lines) when colorizing a display, I have *not* seen the second of those
behaviors; I still see the same desegmentation/defragmentation that I
did on the uncolorized display.
> Even weirder is the fact that desegmentation breaks even if colorizing
> something that has nothing to do with the flow being desegmented. For
> example a colorization filter of "arp" breaks desegmentation. As arp
> isn't even IP (never mind TCP) this is clearly not part of the flow to
> be desegmented.
The explanation of what colorization does should explain this - the
*entire capture* is redissected and redisplayed.
> Where can I find some traces that will exercise desegmentation in one
> or more protocols supported by the Ethereal distribution? I'd like to
> verify that what I am observing happens with other protocols than
> mine.
Oh, wait, this is with a dissector, or with desegmentation code, that's
*not* part of the standard Ethereal release? Oh. That changes
things....
Unfortunately, I can't send you the traces I tested with, but if you go
back and look for the TLS-over-EAP desegmentation patches from Adam
Sulmicki, sent to ethereal-dev in the past month or so (or, at least,
wiithin the past few months), I think one or more of them may have a
segmented TLS-over-EAP capture as a sample.
> (Maybe I'm doing something foolish in my dissector code.)
>
> Any suggestions on where I might look for this bad interaction? I'm
> not sure where to begin my bug hunt.
Make sure your dissectors are, wherever possible, idempotent. They
should update state on the first pass, *and* leave behind enough
information so that reassembly can be done after the first pass, when a
packet is clicked on, *regardless of the order in which the user has
clicked on packets after the first pass was done*, and they should *NOT*
modify any state after the first pass is done (because, as indicated,
after the first pass is done, there is *NO* guarantee that packets will
be visited in any particular order).
The existing defragmentation/desegmentation code in protocols should
already be doing that, so if, for example, you're using the
"reassemble.c" routines, make sure you're using them the same way other
protocols are using them.
