Guy Harris <guy@xxxxxxxxxx> writes:
> 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?
I see exactly what I would expect if I had not enabled desegmentation.
In other words I don't see the "Frame"/"Desegmentation" tabs. Every
TCP packet is interpreted (for better or worse) as a single higher
layer PDU.
What is confusing me is that desegmentation is enabled. The only
thing that changes is I add colorization and the desegmentation stops
working.
> 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.
This explains why I need to reload the capture before I see the bug.
[...]
> Oh, wait, this is with a dissector, or with desegmentation code, that's
> *not* part of the standard Ethereal release? Oh. That changes
> things....
Sorry I probably should have mentioned that earlier in my email. For
what it is worth I have a protocol running over TCP that I am
attempting to desegment.
> 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.
OK, I found it. I'm not seeing the same problem when I add
colorization, but TLS-over-EAP is over UDP and not TCP so I am not
sure what this proves.
> > (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).
I think I am OK here.
> 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.
I only use reassemble.c indirectly through TCP. I did look at the
first dissector to support reassembly (SMB I think) when reassembly
was first added. Perhaps there have been some subtle changes that I
overlooked. I'll examine the current dissectors and verify that I am
not doing anything differently.
Thanks.
--
-Andrew Feren
Cetacean Networks, Inc.
Portsmouth, NH
