On Sep 15, 2012, at 10:33 AM, Christopher Maynard <Christopher.Maynard@xxxxxxxxx> 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.
