> Presumably, TCP and UDP would register their hash table with "tcp.port"
> and "udp.port", respectively, rather than with both "tcp.srcport" and
> "tcp.dstport", and with both "udp.srcport" and "udp.dstport",
> respectively.
That scheme is all very well and good for TCP and UDP, where there's
only one protocol that has a TCP or UDP port number as its subprotocol
selector.
However, it falls down for protocols that use an Ethernet type field, as
there's no single field for that - there's "eth.type" for Ethernet,
"llc.type" for 802.2 LLC (atop FDDI, Token Ring, 802.3, etc.).
"null.type" thanks to the bogus way in which the loopback device is
handled on Linux with the current version of libpcap (it'll be fixed in
a future release, but...), and "vlan.etype" for packets on an 802.1Q
VLAN.
One way to handle this might be to have, for each protocol that calls
subprotocols, one or more specific APIs subprotocols can use to register
with that protocol.
Advantages:
1) handles this case;
2) lets a subprotocol register based on the values of multiple
fields, e.g. an ATM subprotocol could specify particular VPI
and VCI values;
3) could let a subprotocol specify a protocol name, so that the
parent protocol could use that name when it dissects the
field in question;
4) the protocol could initialize its hash table, or whatever,
when it sees the first register call, which would solve the
problem of a subprotocol trying to register itself in its
register routine before the parent protocol's register
routine has been called.
Disadvantages:
1) glops up the API, which is even more of a nuisance on
platforms where dynamically-loaded code can't call functions
in the main program unless it's been handed a pointer to them
(although I may try seeing whether exporting stuff from the
main program makes that work on Win32; I'm not sure what
other platforms have that problem, although I seem to
remember SunOS 4.x having it);
2) one could argue that the lack of such a common field for
Ethernet types is a pain for filters as it requires one to know
what type of packets you're filtering if you want to filter
on (and in an Ethernet trace there could conceivably be both
DIX and 802.3 Ethernet packets, so some of them might use
"eth.type" and some of them might use "llc.type" - and there
could also be 802.1Q packets making the problem even worse).
Advantage 2) is currently not an issue, and I don't know how many such
ATM subprotocols there are (as opposed to protocols where the VPI/VCI
values are negotiated, so that it's not always on the same VPI/VCI).
Advantage 3) could perhaps be handled by looking up the subprotocol
(which would be supplied as part of the "register by field name" call),
and advantage 4) is probably also fixable by other means.
