hom@sjsumcs.UUCP (Hom Bahmanyar) (07/08/88)
We have an ethernet in our Math & Computer Science Department that has a
Sequent Balance, a Convergent Technologies Miniframe, and more than 50
PC compatibles on it. The Sequent and the PC's work perfectly on the
network (for example with PC-NFS); however, the Convergent machine has
some problems with the network: Commands such as telnet and ftp to or
from the Convergent machine always fail but other commands such as rwho
and ruptime from the Sequent show the Convergent host as being on the
network. Also the Convergent host never responds to pings from the
Sequent or the PC's. After we checked all the network setup files and
couldn't find anything wrong, I wrote a simple ethernet monitor program
for one of the PC's that receives all the packets directly from the PC's
3c501 ethernet controller and displays them on the screen. To my surprise,
I saw that the Convergent host was sending an ARP request about every 5
seconds to itself to resolve its own IP address. That is, in the ARP
packet there were:
sender's physical addr: Convergent host's ethernet addr
sender's IP addr: Convergent host's IP addr
target's physical addr: 0 0 0 0 0 0
target's IP addr: Convergent host's IP addr
But why would the Convergent host want to resolve its own address when
it already knows its ethernet address?
Any help you can give me on this will be greatly appreciated.
----
Hom Bahmanyar (408) 924-5107
San Jose State University, Math & Computer Science Department
San Jose, CA 95192-0103
...!{sun,ames,pyramid,hplabs}!sjsumcs!homslevy@UC.MSC.UMN.EDU ("Stuart Levy") (07/09/88)
It's probably trying to tell the world that it itself (its own IP address) is at its own Ethernet address... just in case they forgot or otherwise got confused. It could also be checking for impostors on the same net, claiming to be the same IP address as its own. ARP request packets don't just list the requested IP address; they also include the requestor's IP and link-layer (e.g. Ethernet) address. A feature of the algorithm in RFC 826 is that, on receiving an ARP request, you check whether the -sender's- IP address is in the local ARP table. If so, update the table to associate [sender-IP-address, sender-link-layer-address]. (And, of course, also check whether to respond to the ARP request, but that's another matter.) This makes it possible to change a host's link-layer address and notify the world of the fact just by broadcasting any ARP request. Anyone who thought they knew what the address was will automatically update their tables. (Of course it also makes it possible for any bozo who can generate a bogus ARP packet to cut you off from the world. This might be a rationale for sending ARPs periodically, though 5 second intervals seem pretty extreme.) Further, ARPing for your own IP address should bring a response from anyone who thinks they're at that address too. BSD systems print "duplicate IP address!!" messages when they detect this situation. Stuart Levy
leres@ace.ee.lbl.gov (Craig Leres) (07/11/88)
Stuart Levy writes: > It's probably trying to tell the world that it itself (its own IP address) > is at its own Ethernet address... just in case they forgot or otherwise > got confused. It could also be checking for impostors on the same net, > claiming to be the same IP address as its own. I think the best reason for gratuitously broadcasting an arp reply for yourself is to force hosts you were talking to (say, before you shutdown, swapped your ethernet interface, and rebooted) to learn your new hardware ethernet address. Craig