Error, some other host already uses address xxx.xxx,xxx,xxx
 

I saw this posted in here already, but no answers that help me.

I have newly installed Fedora Core 6. Everything seems to work fine except for that when I try to specify the IP address of the server manually I get the error: Error, some other host already uses address [whatever I try to set it to].

No matter what IP address I try setting it to I get that error. DHCP works great.

I found this in /etc/sysconfig/network-scripts/ifup-eth:

-----
if ! arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${IPADDR} ; then
echo $"Error, some other host already uses address ${IPADDR}."
exit 1
fi
------

I have no freakin clue what that does .. only that it's preventing me from being sane.

Any help would be greatly appreciated ..

This is interesting (probably not what you wanted to hear). The arping command sends out arp packets which request that anybody on the network with the specified address identify themself. The command that you listed sounds like a reasonable sanity check to see if that address is already in use on the network.

So the question is why somebody is replying, or why does that command think somebody is replying. And the only thing I know to advise is to use a packet sniffer such as tcpdump to see what is really happening on your network. As root, give the command

tcpdump -nni eth0

before you try manually setting the address, and see what packets are reported on the network as a result of trying to set the address. You might want to look at tcpdump's man page. If you are swamped with a lot of other packets, you might need to add some qualifiers to the command.

One additional thought occured to me ...

You didn't say exactly what you did such that you are executing that script. I hope that script is getting executed as root. If it is executed as a regular user, arping will return an error which will be interpreted the same way as if another computer had the address being queried. However, in that case I would expect "Operation not permitted" to be printed as well.

Also make sure that the arping command is installed and that the path to is is in root's PATH.

blah ....
 

When I execute the same arping command as root (leaving out the -q of course) I get the following:

[root@undertow network-scripts]# arping -c 2 -w 3 -D -I eth0 192.168.0.4
ARPING 192.168.0.4 from 0.0.0.0 eth0
Sent 4 probes (4 broadcast(s))
Received 0 response(s)

When I execute the command on an IP (like my workstation) that I know is being used, I get this:

[root@undertow network-scripts]# arping -c 2 -w 3 -D -I eth0 192.168.0.106
ARPING 192.168.0.106 from 0.0.0.0 eth0
Unicast reply from 192.168.0.106 [00:04:4B:05:22:34] 0.588ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

So .. everything there makes sense. Nothing is using 192.168.0.4 right before I try setting it. Initially .. I tried running the tcpdump -nni eth0 command in one terminal while stopping and starting the network service in another, but stopping the network service kills tcpdump. So I tried setting the IP address using ifconfig eth0 192.168.0.4 up. Nothing came across on my tcpdump terminal, and while the interface seemed to take the IP .. I wasn't able to ping anything (firewall is off) or get to any other machine on the local network.

This is a very simple network with 3 windows machines, a few printers all on DHCP, and this fedora box. Just seems insane that setting an IP statically would be this difficult.

The "script" .. which I assume is something that does the same thing as '/sbin/service network start' , or '/etc/init.d/network start' is of course run when the machine starts up. So .. I'm assuming it's running them as root.

When I run those commands manually, I am most definitely logged in as root.

Yeah, the arping command is installed in /sbin, which is in roots path.

I'm not sure if I'm reading this correctly, but it seems that the arping command is being run after the interface is set. Given that, it's always going to tell you that the IP address is being used...because it is.

Do you get any errors when you manually set the IP with ifconfig?

-Kristijan

What router are you using?

There was a problem with arp being done via shorthand (think winmodems) by one of the major router manufacturers. It would work for windows boxes but linux boxes acted screwy (maybe macs too). I think it was either Dlink or Netgear.

arping seems to be smart enough not respond to its own address. Or perhaps that's just the way the arp protocol works. In any case, when I tested it, it did not respond to its own address.

In the following, 192.168.2.102 is the local host, 192.168.2.118 is another computer on the network and 192.168.2.119 is unused. Commands in bold and blank lines have been added for readability:

@ryan462,

I think you can bring eth0 up, but w/o an IP address, using ifconfig. That should allow you to start tcpdump. If the script doesn't object to the interface already being up, then you can try setting the ipaddress in the manner that uses the script and see what happens. (I hope!)

If you are sure there is no conflict, you could just edit this sanity check out of your script. I am not familiar with the update process in Fedora, so I don't know whether there is a risk of this script get unceremoniously updated to something that causes problems again. Unless you are quite confident in what you are doing, I would make a backup copy of the scirpt before editing.

Linksys WRT54GS w/ Firmware Version: v1.50.6

I was able to do that and saw nothing come across tcpdump when I tried to use the script to bind the IP. Even with my Linksys Router & Netgear Switch unplugged the '/etc/init.d/network start' did not work. I am able to bind the IP manually with ifconfig and it works just fine.

I tried commenting out the part in the script that does that arping check altogether, but it still didn't work. I guess I'll have to look further into the scripts and see what does what.

You should have at least seen the arp requests going out from your own machine (unless you gave tcpdump options to suppress them).

Yeah, if nothing is plugged into your ethernet connector and you still get the error then the problem must be internal to your box. I don't know if it helps, but just for reference, I just checked and that arp sanity check goes back to at least RH 8.0.

Good luck with debugging.

ha ha ha Simply ARP Cache Poisoning !

read the link

http://www.linuxpakistan.net/forum/viewtopic.php?t=7126

I don't think so. The cache poisoning you refer to is a malicious act to get one or more machines to route to the wrong ethernet address. The network in question, described by the OP in post #5, is a very simple network under the OP's control. And remember that a few post back the OP described the problem persisting even with the network switch disconected. And keep in mind that ARP caches time out fairly quickly. (Use tcpdump on a normally operating network and notice how often an arp request is sent.)