On Wed, Jul 12, 2000 at 01:26:18PM -0400, John Hawkinson wrote:

> Have you ever seen this happen? I presume you're referring to "tried
> to overwrite arp info" messages? Those only happen if an arp message
> is received on the wrong interface, at least as far as I can
> tell.

The RFC makes it seem like arp table entries are set without regard to
the source of a particular packet. It's slow going, though... If I can
feel confident that this interface-based relevancy check is definitely
there, I wouldn't feel the need to nail down entries, and I'd be happy
to drop the idea of using /etc/ethers with arp(8). If this behaviour is
*not* there, then I'll have to maintain that more central administration
is still better.  I'd rather this sort of check exist, of course, as it
would make the default behaviour safer.

Hm... Actually, that's a thought. If there are loopholes, maybe the
better solution would be to plug them, rather than work around them
with arp(8).

I still need to learn more, either way.

> If you have "rogue" ARP data in your arp cache, when the legitimate
> host comes back, you should get an ARP reply from it in response to
> your ARP query and, and it should function just fine.

This makes sense as an interface-by-interface thing for outbound packets,
assuming the machine chooses the correct interface and doesn't just
broadcast to all interfaces, which I expect is likely the case. I still
want to know more about the behaviour of inbound packets.

-- 
Mason Loring Bliss             (( "In the drowsy dark cave of the mind dreams
mason@acheron.middleboro.ma.us  )) build  their nest  with fragments  dropped
http://acheron.ne.mediaone.net ((  from day's caravan." - Rabindranath Tagore