Michael Tuexen wrote:
> Richard,
>
> regarding the COL_INFO stuff I would like to say that protocols
> running over SCTP have to deal with the fact that multiple
> upper layer protocol data can be part of one SCTP packet. Since the
> dissector and most of the upper layers are written by myself it
> was easy to only use append instead of set for the COL_INFO stuff.
>
> But it would be helpful is this could be handled 'automatically'.
> Maybe a protocol can set the COL_INFO stuff in a state: ONLY_APPEND
> where even set calls are modified to APPEND, or DONT_MODIFY where
> append and set calls are simply ignored.
In my experience with writing dissectors over SCTP, I've had both this
problem (sub-dissectors should never clear COL_INFO) and the opposite:
I've got a sub-dissector that wants to clear what the (direct) parent
dissector put in COL_INFO but only for this particular SCTP Data chunk.
E.g., SCCP dissector puts the messageType in COL_INFO. SCCP-Management
appends its messageType but I would really like it to overwrite the SCCP
messageType. SCCP-Management can't clear the whole column, though,
because there may have been other SCTP data chunks in this IP packet...
The best thing to do in this case is to modify the SCCP dissector to not
put anything in COL_INFO if a sub-dissector is called but that involves
either passing the messageType way down the stack or using a global
variable--something I haven't gotten around to yet.
So far this approach has worked pretty well for protocols above SCTP:
don't ever clear COL_INFO and don't put anything there if you called (or
are going to call;)) a sub-dissector. You just have to remember that
when writing your dissector ;-).
Of course that would all change if somebody started doing some other
protocols (existing dissectors) over SCTP...
Anyway, I just thought I'd throw this out as related...
Regards,
-Jeff
> On Tuesday, Oct 1, 2002, at 23:39 Europe/Berlin, Richard Sharpe wrote:
>
>> There are more and more places where we are starting to need dissector
>> routines in one dissector for a structure that is known about in another
>> dissector. For example, in the Windows world, they seem to place a
lot of
>> their existing structures on the wire as blobs. Security descriptors
seem
>> to turn up all over the place.
>>
>> Do we need a[nother] mechanism for registering and retrieving such
>> dissectors?
>>
>> Also, we might need some new coding guidelines because there are cases
>> where some dissectors could almost be called from other dissectors,
>> except
>> that they should avoid modifying the COL_INFO column, for example.
>>
>> Regards
>> -----
>> Richard Sharpe, rsharpe@xxxxxxxxxx, rsharpe@xxxxxxxxx,
>> sharpe@xxxxxxxxxxxx
>>
>> _______________________________________________
>> Ethereal-dev mailing list
>> Ethereal-dev@xxxxxxxxxxxx
>> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
--
Jeff Morriss
Senior Support Engineer
Ulticom, Inc.
Helpdesk: +1-856-787-2765
Fax: +1-856-222-9947