On Wed, Jul 12, 2000 at 10:42:18AM -0400, John Hawkinson wrote:

> I saw no such post, could you please provide an explicit
> citation? The closest I saw was greywolf's
> <Pine.NEB.4.21.0007092024550.4248-100000@mage.starwolf.com>

That's the one.

> In the absence of a mechanism for populating /etc/ethers with reliable
> information, I would not think adding this option would be a good plan.

If you're loading random data into /etc/ethers and then using arp -F
without first reading the man page, then I suppose there could be problems.
If you're loading data into /etc/ethers and then using arp -F because you
know what the behaviour is and you want it, then the chance of randomness
creeping in is fairly minimal.

> Another observation is that /etc/ethers is used to translate MAC addreses
> into names. Those names do not necessarily have to match up with DNS
> names, nor with IP addresses, and frequently are concocted so they
> are visibly convenient for tcpdump output.

That would seem to be an extremely bad idea to me. While the ethers(5)
man page doesn't specify that you're not supposed to make up random,
bogus hostnames, it does refer folks to ethers(3), which at the least
*suggests* that the hostnames should be valid, since it talks about
generating them.


> They do not necessarily map to IP addresses in /etc/hosts or the DNS.

I would call this an error condition that should be corrected, rather
than a possibility that could be encountered in a correctly configured
system.


> My understanding is that the -f flag is intended for people who have
> multiple static arp entries required in their environment (typically
> published arp entries, but perhaps not always), and would like to
> avoid having to run 'arp' multiple times. Typically, this would be a
> much smaller set of entries then one might find in a typical populated
> /etc/ethers file.

I'm not suggesting that people be forced to use /etc/ethers to populate
their arp tables, and I'm not suggesting that the ability to use "arp -f"
be changed or removed. In some cases, however, using /etc/ethers for this
will be exactly the right thing to do. For those cases, a trivial option
added to arp(8) seems like a perfectly reasonable idea.

If you want, I'd be happy to include a bit in the arp(8) man page stating
why this might be a bad idea for some folks, or why caution must be taken.
I simply want the functionality.

> Really? You have a non-hypothetical case where this is useful? Is it
> the one you cited of a gateway machine that does not trust ARP (I find
> this implausible)? Or do you have a different scenario?

No, that's the scenario. I've seen messages pass by my console in the
past indicating errors where non-local (well, non-inside) hosts have
been unable to add in entries because they're trying to replace addresses
already extant.  Now, some of my boxes INSIDE my network don't send out
lots of traffic, and occasionally they disappear from the arp tables as
a consequence. I do not wish to have "rogue" entries added during these
periods. In addition to this, I netboot several boxes.

I *have to* maintain /etc/ethers, and I *have to* nail down some arp
entries. Having to maintain two files with identical data doesn't interest
me when there's a clean, good solution available that lets me use a
single, already defined and populated file.  This is free functionality,
essentially, and it solves a real-world problem for me. I expect that
there are at least some other folks using NetBSD on MediaOne or similar
services that do essentially what I do, that could benefit from this
change if they wanted.

If you have compelling reasons why this is a bad idea under some
circumstances, I'd prefer to document that and add the functionality,
rather than not adding the functionality and forcing folks to use kludges.

-- 
   Mason Loring Bliss   mason@acheron.middleboro.ma.us             E w i g e
awake ? sleep : dream;  http://acheron.ne.mediaone.net  Meerschweinchenkraft