On Sep 15, 2012, at 10:33 AM, Christopher Maynard
<[email protected]> wrote:
> My understanding of dissectors registering to port 0 was simply a method for
> allowing "Decode As" to work.
The right way for a dissector to say "I run atop {TCP,UDP,...} but I don't have
a standard port number, so use "Decode As..."" is to call dissector_add() with
a dissector handle and a dissector table name.
> Maintaining a linked list seems like a good idea to me and a lot easier than
> adding de-registration routines to 1000+ dissectors. Until all dissectors are
> fully converted to new-style ones, maybe they could all be "forcibly"
> converted
> by simply having them return the number of bytes in the tvb that are handed to
> them? Then slowly they could really be converted to actually perform
> heuristics
> and return the actual number of bytes dissected.
...as long as they can't validly return 0 (there's a case where a dissector can
succeed in dissecting an empty packet - I *think* it was a request/response
protocol wherein some replies could just say "succeeded" without returning any
data, and the success/failure status was carried by the protocol atop which the
request/response protocol was transported, so the dissection of the empty
response would just say "this is a response to an XXX request, which was in
frame YYY").
Jakub Zawadski suggested returning -1, rather than 0, as a "not my packet"
return value. If we were to support 2^32-byte PDUs, that might be a problem,
but I don't know whether that's likely in the near future.
The right way to process a list of dissectors in a dissector table entry would
be to try them in sequence, skipping disabled dissectors, and stopping as soon
as either
1) a "new-style" dissector returns a match
or
2) an "old-style" dissector is called.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe