Ethereal-dev: Re: [Ethereal-dev] resolving of well-known mac-addresses

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

From: Hannes Gredler <hannes@xxxxxxxxxxx>
Date: Wed, 28 Aug 2002 12:46:41 +0200
On Wed, Aug 28, 2002 at 02:50:57AM -0700, Guy Harris wrote:
| On Wed, Aug 28, 2002 at 11:41:25AM +0200, Hannes Gredler wrote:
| > IMHO it does make sense that these _protocol-specific_ [thats the important
| > keyword here] MAC-addresses are registered by the dissector;
| 
| We also ship, and install, a bunch of XML files used by the Diameter
| dissector, supplying protocol-specific information; there is *some*
| Diameter dictionary information hard-coded into the dissector, but
| that's just a fallback if your Ethereal isn't built with the XML
| library.
| 
| As such, it doesn't bother me to put protocol-specific information, such
| as multicast MAC addresses for particular protocols, into a
| configuration file rather than hard-coding them into a dissector.
| 
| The configuration-file scheme also seems to me to be more extensible -
| you don't have to keep tweaking dissectors to add new well-known MAC
| addresses, you just add to the configuration file.
| 
| >   sure we could start messing up with files, however
| >   these well-known MACs are specified in ISO10589 [10 years old spec]
| >   and it is unlikely that they do change in the near future;
| 
| Yes, but that doesn't mean that there aren't other well-known MAC
| addresses that we've missed - and it'd be nice if non-programmers, or
| people with binary-only installations, could add the ones we've
| forgotten (and send us patches to update the list).

what i am saying does not contradict do what you are saying :-);
  i like the fallback idea ....
non-programmers can do it that way ... no problem with that, however if
a programmer wants to register his MAC addresses in the code we should permit
that freedom of choice .... given that the patch is absolute trivial
and the routines already exist [recall add_eth_byname() is just a wrapper to
  add_eth_name] this should be no problem ...

/hannes