On Mon, Apr 14, 2003 at 03:03:38PM +0200, Michael Tuexen wrote:
> So I think it IS intentional that the information from SCTP and M3UA
> remains in the Info Column when ISUP appends also something. It is only
> a bug that M3UA puts in DATA and that ISUP dissects it.
So there might be a case where, for example:
dissector A calls dissector B;
dissector B calls dissector C:
stuff that dissector A puts into the Info column should be left
intact by dissector B and dissectors it calls;
stuff that dissector B puts into the Info column should, if
dissector C is called, be replaced by whatever dissector C puts
into the Info column.
For example, if I correctly understand what you're saying, at least some
stuff the SCTP dissector puts into the Info column should not be
overwritten by stuff that subdissectors put into the Info column, but if
the M3UA dissector puts "DATA" into the Info column and then calls the
ISUP dissector, whatever the ISUP dissector puts into the Info column
should replace the "DATA" that the M3UA dissector put there.
If so, then one way to handle this might be to have a col_ call to put a
"wall" into the column at the end of the data currently in that column
(when the columns are initialized, the wall is at the beginning, so the
call really moves the wall), have any dissector that wants its stuff
left unchanged by subdissectors make that call, have "col_clear()" clear
all data past the wall but no data before the wall, have the "col_add_"
calls append stuff after the wall rather than putting it at the
beginning, have "col_set_str()" append stuff after the wall if it's not
at the beginning, and have all dissectors do "col_clear()" at the before
doing anything that might throw an execption unless they do a "col_add_"
call before doing anything that might throw an exception.
The SCTP dissector, for example, would put a "wall" after anything it
wants subdissectors to preserve.
(This idea was inspired by noticing that the TCP dissector puts into the
Info column notes about any anomalies seen by the sequence number
analysis; it turned out that it does so by prepending that information
after the subdissector returns (which means that the information won't
get prependent if the subdissector throws an exception), not by putting
a wall after that information, but it led me to think of such a wall -
and if we implement that, the TCP dissector should probably be change to
put the sequence number analysis in before calling the subdissector, and
walling off that information so the subdissector doesn't overwrite it.)