# problem bringing up eth0 at boot time -- SOLVED!

## Moriah

I am having trouble getting eth0 to initialize on boot-up.  I get:

```

* Starting eth0

*    Bringing up eth0

*      xx.xx.xx.xx

*      xx.xx.xx.xx already taken on eth0

```

This box used to work, but had not been booted in many months, although it had been kept pretty current as far as updates go.  When it was booted recently, this problem starting eth0 appeared.  I can manually configure eth0 with ifconfig and set a default route with route, and that all works, and the box will communicate, but something is messed up that keeps it from working automatically at boot.

I see where the message is coming from -- in /etc/init.d/net.eth0 it reads:

```

  if ! is_loopback "${iface}" ; then

     if [[ " ${MODULES[@]} " == *" arping "* ]] ; then

       if arping_address_exists "${iface}" "${conf[0]}" ; then

         eerror "${conf[0]%%/*} already taken on ${iface}"

```

So my problem is that I cannot find the definition of arping_address_exists so I can dig into it and try to determine what exactly is going wrong.

Does anybody see what is keeping my eth0 from coming up?

----------

## alunduil

Usually, that indicates that the address you are setting (I assume a static IP) is taken by another host on the network. Bring that box down and use another box to ping the address in question. Then determine if you have overlap with a DHCP range, or just a conflict of addresses.

Regards,

Alunduil

----------

## phajdan.jr

 *Moriah wrote:*   

> 
> 
> So my problem is that I cannot find the definition of arping_address_exists so I can dig into it and try to determine what exactly is going wrong.

 

Its definition is in file /lib/rcscripts/net/arping.sh, as grep arping_address_exists -r /lib revealed.

----------

## Moriah

Having found the definition in question, and the call it makes to arping to check for duplicate ip addresses, I manualy invoked the command to see what it was returning.  It looks as if my ip address is duplicated on the local ethernet network segment.  I had the local NOC administrator where this box is co-loc-ed duplicate the test, and he ran it from a solaris box and was unable to duplicate my results.

So I ran the test in a loop over a range of addresses.  My box, where the test was run, is the .16 address.  I then did an ifconfig to show that arping for my address is not showing my MAC address.  The MAC address it shows is also shown for many of the other ip addresses:

```

for x in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ; do arping -c 2 -w 3 -D -f -I eth0 xxx.yyy.zzz.17 ; done

ARPING xxx.yyy.zzz.1 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.1 [00:02:A5:0A:54:28] for xxx.yyy.zzz.1 [00:02:A5:0A:54:28] 1.729ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.2 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.2 [00:02:A5:0A:54:28] for xxx.yyy.zzz.2 [00:02:A5:0A:54:28] 0.664ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.3 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.3 [00:02:A5:0A:54:28] for xxx.yyy.zzz.3 [00:02:A5:0A:54:28] 1.731ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.4 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.4 [00:02:A5:0A:54:28] for xxx.yyy.zzz.4 [00:02:A5:0A:54:28] 0.666ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.5 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.5 [00:02:A5:0A:54:28] for xxx.yyy.zzz.5 [00:02:A5:0A:54:28] 1.720ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.6 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.6 [00:02:A5:0A:54:28] for xxx.yyy.zzz.6 [00:02:A5:0A:54:28] 0.674ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.7 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.7 [00:0A:5E:06:E3:47] for xxx.yyy.zzz.7 [00:0A:5E:06:E3:47] 0.687ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.8 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.8 [00:02:A5:0A:54:28] for xxx.yyy.zzz.8 [00:02:A5:0A:54:28] 0.664ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.9 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.9 [00:02:A5:0A:54:28] for xxx.yyy.zzz.9 [00:02:A5:0A:54:28] 0.668ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.10 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.10 [00:01:02:71:E8:D9] for xxx.yyy.zzz.10 [00:01:02:71:E8:D9] 0.677ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.11 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.11 [00:02:A5:0A:54:28] for xxx.yyy.zzz.11 [00:02:A5:0A:54:28] 0.666ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.12 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.12 [00:0A:95:E5:4D:F8] for xxx.yyy.zzz.12 [00:0A:95:E5:4D:F8] 0.680ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.13 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.13 [00:02:A5:0A:54:28] for xxx.yyy.zzz.13 [00:02:A5:0A:54:28] 0.665ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.14 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.14 [00:02:A5:0A:54:28] for xxx.yyy.zzz.14 [00:02:A5:0A:54:28] 1.720ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.15 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.15 [00:02:A5:0A:54:28] for xxx.yyy.zzz.15 [00:02:A5:0A:54:28] 0.666ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.16 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.16 [00:02:A5:0A:54:28] for xxx.yyy.zzz.16 [00:02:A5:0A:54:28] 1.719ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ARPING xxx.yyy.zzz.17 from 0.0.0.0 eth0

Unicast reply from xxx.yyy.zzz.17 [00:02:A5:0A:54:28] for xxx.yyy.zzz.17 [00:02:A5:0A:54:28] 0.667ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

ifconfig

eth0      Link encap:Ethernet  HWaddr 00:0C:F1:AA:09:6E

          inet addr:xxx.yyy.zzz.16  Bcast:xxx.yyy.zzz.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:1231360 errors:0 dropped:0 overruns:0 frame:0

          TX packets:910758 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:103449174 (98.6 Mb)  TX bytes:57562447 (54.8 Mb)

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

```

Observe that the displayed MAC addresses for the .7, .10, and .12 ip addresses is different from the others, which are all the same.  These 3 addresses are also unique among the displayed output.

So can anybody who is more familiar than I explain the output the test above produced?    :Shocked: 

Here is an ICMP ping of the same address range:

```

for x in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ; do ping -n -c 2 -I eth0 -r -w 3 -q xxx.yyy.zzz.$x ; done

PING xxx.yyy.zzz.1 (xxx.yyy.zzz.1) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.1 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.652/0.880/1.108/0.228 ms

PING xxx.yyy.zzz.2 (xxx.yyy.zzz.2) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.2 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 1.713/1.728/1.744/0.044 ms

PING xxx.yyy.zzz.3 (xxx.yyy.zzz.3) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.3 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1000ms

rtt min/avg/max/mdev = 1.449/1.903/2.358/0.456 ms

PING xxx.yyy.zzz.4 (xxx.yyy.zzz.4) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.4 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 1.409/1.412/1.415/0.003 ms

PING xxx.yyy.zzz.5 (xxx.yyy.zzz.5) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.5 ping statistics ---

3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2008ms

, pipe 3

PING xxx.yyy.zzz.6 (xxx.yyy.zzz.6) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.6 ping statistics ---

3 packets transmitted, 0 received, <100% packet loss, time 2009ms

PING xxx.yyy.zzz.7 (xxx.yyy.zzz.7) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.7 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 2009ms

PING xxx.yyy.zzz.8 (xxx.yyy.zzz.8) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.8 ping statistics ---

3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2009ms

, pipe 3

PING xxx.yyy.zzz.9 (xxx.yyy.zzz.9) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.9 ping statistics ---

3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2009ms

, pipe 3

PING xxx.yyy.zzz.10 (xxx.yyy.zzz.10) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.10 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.195/0.213/0.232/0.023 ms

PING xxx.yyy.zzz.11 (xxx.yyy.zzz.11) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.11 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 2008ms

PING xxx.yyy.zzz.12 (xxx.yyy.zzz.12) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.12 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.179/0.195/0.212/0.021 ms

PING xxx.yyy.zzz.13 (xxx.yyy.zzz.13) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.13 ping statistics ---

3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2008ms

, pipe 3

PING xxx.yyy.zzz.14 (xxx.yyy.zzz.14) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.14 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1001ms

rtt min/avg/max/mdev = 0.348/1.180/2.013/0.833 ms

PING xxx.yyy.zzz.15 (xxx.yyy.zzz.15) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.15 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.252/0.257/0.263/0.016 ms

PING xxx.yyy.zzz.16 (xxx.yyy.zzz.16) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.16 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.063/0.068/0.073/0.005 ms

PING xxx.yyy.zzz.17 (xxx.yyy.zzz.17) from xxx.yyy.zzz.16 eth0: 56(84) bytes of data.

--- xxx.yyy.zzz.17 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.199/0.211/0.224/0.019 ms

```

Notice that these addresses are not responding:  .5  .6  .7  .8  .9  .11  .13  And also remember that .7, .10, and .12 were responding with unique MAC addresses to arping.

This has me totally baffled.  It must be something wrong with arping, but I do not know what.

Please remember that when I set up eth0 manually with ifconfig, and establish a default gateway manually with route, that the network behaves in a reasonable manner.  It is just that the /etc/init.d/net.eth0 script, which is symlinked to net.lo, calls arping to check for duplicate ip addresses and fails that test, keeping eth0 from starting automatically.

I really need to understand this because it is keeping an important machine offline.

Thanks!    :Very Happy: 

----------

## Moriah

After working with the NOC admin at the ISP, he re-ran my tests from a solaris box, and was unable to duplicate the results.

Since I had already manually configured the interface and its gateway and it worked, I went into the arping_address_exists script and edited it to always return OK for the case where it was calling arping and getting the wrong result.  I know this is a crock, but it solves the problem for my particular case.    :Confused: 

Kids, don't try this at home!    :Shocked: 

----------

## Hu

The NOC administrator may be unable to locate the rogue box due to the conflict you have induced.  That check is present to avoid putting two machines on the same IP address.  The kernel has no objection to this, which is why you can force it by hand.  However, by doing this, you now have two machines that both answer to x.y.z.16.  This can cause a variety of frustrating and generally hard to trace problems, including TCP connections mysteriously dying and failure to connect to a service that is listening.  If a machine which does not know the MAC address of x.y.z.16 sends an ARP request to find the MAC address, both your system and the rogue machine will answer.  Only one of you can have the address, so only one of you will receive the subsequent IP datagrams.  If the wrong one of you gets it, the peer will perceive a system he was not expecting.  If he has an open connection to your box, he may start sending datagrams to the rogue box, which will promptly reset his connection.

You should remove that address from your interface until the NOC administrator takes the rogue machine off the network.  You may have some semblance of functionality, but unless you are extremely lucky with how ARP responses are handled, you will likely have subtle IP problems as long as both boxes use the same IP address.

----------

## Moriah

Hu, you missed the point.  There is no other box with my assigned address, as determined by having my box powered down when he pings that network segment.  He assigned me that address.  When my box is down, that address is not there.

And yes, I am aware of all the things that can happen if 2 boxes have the same ip address at the same time, and none of those things are happening either.

----------

## Hu

 *Moriah wrote:*   

> Hu, you missed the point.  There is no other box with my assigned address, as determined by having my box powered down when he pings that network segment.  He assigned me that address.  When my box is down, that address is not there.
> 
> And yes, I am aware of all the things that can happen if 2 boxes have the same ip address at the same time, and none of those things are happening either.

 

You said only that he could not duplicate the results.  You did not say that he did not get a response to ping.  Even so, that is not a particularly conclusive test.  I always configure my systems to DROP all ICMP echo requests from untrusted hosts.  I usually, but do not always, allow ICMP echo requests when I believe I am on a safe network.  It is entirely possible that the rogue system is ignoring ICMP echo requests, so its failure to respond does not prove that no such system exists.  If an arping does not return a response from the rogue box, then I will believe that there is no rogue box.

----------

## Moriah

Sorry to be vague.  Neither ping nor arping returned a response when run from the solaris box.  (I am not sure the solaris box calls the command "arping", but the functionality is the same.  The NOC operator understood what I was seeing, and he knew what he was testing for.)  I have no idea why the arping command on my linux box was behaving the way it was, but only having that one box colocated at that isp, I have to trust the NOC operator, as I have no other way to test it.  I guess I could run tcpdump when I arping-ed and capture the output to a file so I could look at it.  I did not do that, however.

----------

## Moriah

Problem SOLVED !!!

I got a call from the NOC engineer at my ISP yetserday, and another customer had called yesterday morning with the same problem I was having.  This made the NOC engineer take another look, and he found that the arping command he had been using used the address assigned to that machine when it pinged, but the arping I was using under Gentoo used an address of all zeros.  When he invoked his arping with some extra options to force it to also use all zeros, he was able to duplicate my results -- and the results of the other customer that called in.

It turns out that the erroneous respose was being generated by a customer running Fedora using proxy arp with a load balancing setup that acted like a bridging firewall.  Rather than actually get to the bottom of the situation, and to quickly eliminate the problem, that customerr reconfigured his firewall to be a router instead of a bridge, and then the problematic proxy arp was no longer needed.

Once this fix had been applied, I un-crocked my ethernet start-up script to restore it to its original condition, and everything worked properly.    :Smile: 

----------

## mimosinnet

Although the issue is unrelated, it has some connection with the topic and I have not seen many topics in the forums dealing with these issues. I am having an issue with arping and I would appreciate any hints on how to follow. I have a laptop with two interfaces (eth0 and ath0). On my home network, I want those interfaces to be given a certain IP. Arping can be used to assign a certain IP depending on the network. My router gives me three MAC addresses:

```
Router: 00:14:BF:86:F0:FC

Local Network: 00:14:BF:86:F0:FB

Wireless: 00:14:BF:86:F0:FD
```

With both interfaces, I ONLY get an answer from the MAC address 00:14:BF:86:F0:FB.

```
# arping2 -t 00:14:BF:86:F0:FB -i eth0 -c 3 192.168.1.1

ARPING 192.168.1.1

60 bytes from 00:14:bf:86:f0:fb (192.168.1.1): index=0 time=407.000 usec

60 bytes from 00:14:bf:86:f0:fb (192.168.1.1): index=1 time=378.000 usec

60 bytes from 00:14:bf:86:f0:fb (192.168.1.1): index=2 time=367.000 usec
```

These are my interfaces:

```
# ifconfig

ath0      Link encap:Ethernet  HWaddr 00:16:44:1B:18:83

          inet addr:192.168.1.106  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:47752 errors:0 dropped:0 overruns:0 frame:0

          TX packets:42351 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:7177548 (6.8 Mb)  TX bytes:53258343 (50.7 Mb)

eth0      Link encap:Ethernet  HWaddr 00:A0:D1:CB:64:4E

          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:782 errors:0 dropped:0 overruns:0 frame:0

          TX packets:642 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:379354 (370.4 Kb)  TX bytes:101529 (99.1 Kb)

          Interrupt:22 Base address:0xdead
```

I do not know if this is related, but I cannot ping eth0 IP with ath0 (and the other way around). 

```
# ping -I ath0 -c 3 192.168.1.100

PING 192.168.1.100 (192.168.1.100) from 192.168.1.106 ath0: 56(84) bytes of data.

From 192.168.1.106 icmp_seq=1 Destination Host Unreachable

From 192.168.1.106 icmp_seq=2 Destination Host Unreachable

From 192.168.1.106 icmp_seq=3 Destination Host Unreachable

--- 192.168.1.100 ping statistics ---

3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms

, pipe 3
```

To be able to give the interfaces a certain IP, I have this /etc/conf.d/net

```
# cat /etc/conf.d/net

hotplug_eth0="yes"

#http://gentoo-wiki.com/HARDWARE_Intel_G33,_Q35,_and_Q33_Chipsets#Network_Settings

ifplugd_eth0="--poll-time=15"

## modules_eth0=( "ifplugd" )

#modules_eth0=( "plug" )

# Configura eth0 en funció del lloc

config_eth0=( "arping" )

#arping_sleep=30

#arping_sleep_lan=30

#arping_wait=30

#arping_wait_lan=30

# En cas de que el gateway sigui 192.168.1.1 (casa) li donem 192.168.1.105

gateways_eth0="192.168.1.1,00:14:BF:86:F0:FB"

config_192168001001_0014BF86F0FB=( "192.168.1.105/24" )

routes_192168001001_0014BF86F0FB=( "default via 192.168.1.1" )

# dns_servers_192168001001_0014BF86F0FC=( "192.168.1.1" )

# En cas contrari, dhcp

fallback_eth0=( "dhcp" )

# ath0

modules_ath0=( "wpa_supplicant" )

wpa_supplicant_ath0="-Dmadwifi -c /etc/wpa_supplicant/wpa_supplicant.conf"

wpa_timeout_ath0=60

# Prevent ifplugd from managing wlan0 (prova)

## modules_ath0=( "!plug" )

# Enable arping mode

config_ath0=( "arping" )

# if your interface needs to be "upped" before it can be configured

# iwconfig_ath0=( "txpower on" )

# Define the gateways you want to configure

# You can consider each gateway as a profile

gateways_ath0="192.168.1.1,00:14:BF:86:F0:FB"

# Define the IP and netmask,default route and DNS server when using gateway 192.168.1.1

# Quan esta a casa li donem la IP 192.168.1.106

config_192168001001_0014BF86F0FB=( "192.168.1.106 netmask 255.255.255.0" )

routes_192168001001_0014BF86F0FB=( "default via 192.168.1.1" )

# dns_servers_192168001001=( "192.168.1.1" )

# If any of the above profiles fail use DHCP

fallback_ath0=( "dhcp" )

iwconfig_ath0="mode managed"
```

The problem is that I must give the same gateway to eth0 and ath0 (192.168.1.1,00:14:BF:86:F0:FB) and, therefore, I cannot assign two different IPs: the firsts interface that gets up gets the address  192.168.1.106. Do you have any suggestions?

----------

