> > If one answers to ARPs and
> > the other doesn't, no one else on the network will ever
> pick up the MAC
> > address of the machine that doesn't respond to ARPs, so
> even though it is
> > configured with a duplicate IP, it doesn't have any effect. Someone
> correct
> > me if I am wrong here.
>
>
> I think you're wrong here. (:-) If the quiet machine
> communicates with any
> other, (call it "X".) Then it will update X's ARP chache with the MAC
> address of the quiet machine. Any comms going from X to the
> duplicated IP
> address will now go to the quiet machine, until the ARP cache
> times out, and
> then it will go to the other. Yeuch.
I wondered about that. I have seen two types of behavior. One is what you
describe above, where a recipient implicitly updates its ARP table upon
receipt of a packet with a new MAC. The other is where a host will only
update its ARP table if it receives an actual ARP reply from a request that
the host itself made. I have never seen a host pick up ARP replies from
requests made by other hosts (although this could be classified as the same
as the first type of behavior).
In the implicit-update case, a device intended to detect duplicate IP
addresses would have to maintain a stateful ARP table, as you describe
below. The packets would not have to be kept; only the table would need to
be maintained.
> On the original subject. It is not just ARP packets that have
> the MAC and
> the IP address in. Every IP packet can be scanned for unique
> address pairs.
> It sounds like a job for tethereal and perl, to me.
The problem with tethereal and perl is that one would only be able to sample
the wire from time to time, parse the sample, update the table, and then
capture again. The table could not be maintained in real time, at least not
using tethereal or ethereal. Another application could be written that does
this using libpcap, though (and there is a Perl module for this, as someone
so wisely pointed out in a previous thread).
--J
