On Wed, Feb 20, 2002 at 04:09:44PM -0500, packet steve wrote:
> Assume an hypothetical protocol that uses two UDP ports. The protocol used
> on the two ports is quite similar, but the dissector needs to print a
> port-dependent identification string. Without peeking into the private
> structure, one could define two dissectors:
> dissector_add("udp.port", PORT1, handle1);
> dissector_add("udp.port", PORT2, handle2);
> the two dissectors are basically wrappers would call a common dissector
> carrying along an extra argument ", int udpportnum)". This isn't very
> elegant.
Whether it's considered elegant or not is purely a matter of taste, and
tastes differ.
If they're truly different protocols with similar presentation syntax,
then I'd consider the correct, and most elegant, way to do it to be to
have two protocols (both registered with "proto_register_protocol()"),
so that you can filter for protocol A or protocol B (without having to
remember the port numbers for protocols A and B and using a "udp.port ==
X" filter), have two separate dissectors, and have them call common
code, passing that code the "proto_xxx" and "ett_xxx" values for the
protocol in question.
If you want to do it the other way, though, the correct way to get the
port number is to use the "match_port" field in the "packet_info"
structure (that indicates which port matched when the dissector did a
hash table lookup on the port number; unless the protocol in question is
unidirectional, you can't just check the source port or check the
destination port - you could check both, but checking "match_port" is
easier and cleaner).