ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] RT-Net plugin bug fix

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 18 Aug 2003 10:45:00 -0700

On Saturday, August 16, 2003, at 9:07 PM, Erwin Rol wrote:

Perhaps, instead, the RT-Net dissector should register a dissector table to be used with RTNET_TYPE_ values, and the IP and ARP dissectors should
register themselves in that table.


Isn't that the wrong way around, cause IP/ARP don't know they are
encapsulated in RTNET (or what ever ) ? Or am i miss understanding
something here.

IP and ARP don't necessarily "know" that they're encapsulated in Ethernet packets, or ARCNet packets, or PPP packets, or..., either, but they register themselves with the Ethernet, ARCNet, etc. dissectors.

If it were the responsibility of the low-level dissector to register upper-level dissectors, that'd require you to change the Ethernet dissector, for example, whenever a new protocol running atop Ethernet were added; doing the registration in the dissector being added means the dissector(s) for the protocol(s) atop which it runs don't have to be modified.

Perhaps the *best* solution is to have all dissectors register themselves by name (which, for at least some protocols running atop TCP, for example, means there are two dissectors registered, as the over-TCP dissector is different from the other dissector) and have a text file that specifies dissector registration.

If there were only a global text file, installed as part of Ethereal, then if that file were edited by a user - which would be a nice way to, for example, change the set of UDP or TCP or SCTP ports used by some protocol - either

	1) their changes would be lost in an upgrade or re-install

or

2) we'd have to merge the two files, so that user changes weren't lost *AND* new registrations in a new release weren't lost.

If we also have a per-user file, then we'd have to figure out how to make that file override the system file *WITHOUT* losing any new port bindings you get in a new release.