Error, some other host already uses address xxx.xxx,xxx,xxx
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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.
Quote:
Originally Posted by blackhole54
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.
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.
Quote:
Originally Posted by blackhole54
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.
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?
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.
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.
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:
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!)
Quote:
Originally Posted by ryan462
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.
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.
Last edited by blackhole54; 05-22-2007 at 12:49 AM.
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.
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.
Quote:
Originally Posted by blackhole54
@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.
I was able to do that and saw nothing come across tcpdump when I tried to use the script to bind the IP.
You should have at least seen the arp requests going out from your own machine (unless you gave tcpdump options to suppress them).
Quote:
Even with my Linksys Router & Netgear Switch unplugged the '/etc/init.d/network start' did not work.
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.
Last edited by blackhole54; 05-23-2007 at 01:52 AM.
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.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.