# eth0 not connected but still receiving an address

## BrummieJim

Hi,

Something's screwing up my network settings trying to start eth0 when no cable is connected and I use wireless (eth1). This means that I need a restart or a /etc/init.d/net.eth1 restart to get networking up. After booting my system looks like this;

Hawaiian ja # /sbin/route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

169.254.0.0     *               255.255.0.0     U     0      0        0 eth0

loopback        *               255.0.0.0       U     0      0        0 lo

Hawaiian ja # ifconfig

eth0      Link encap:Ethernet  HWaddr 00:C0:9F:78:85:61  

          inet addr:169.254.140.178  Bcast:169.254.255.255  Mask:255.255.0.0

          UP BROADCAST MULTICAST  MTU:1500  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:1000 

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

          Interrupt:6 

eth1      Link encap:Ethernet  HWaddr 00:0E:35:82:F5:EB  

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

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

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

          collisions:0 txqueuelen:1000 

          RX bytes:3762 (3.6 Kb)  TX bytes:7944 (7.7 Kb)

          Interrupt:10 Base address:0xe000 Memory:d0214000-d0214fff 

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)

Does anyone have any ideas why this might be happening? If you need any more information, just ask!

Cheers

----------

## desultory

It is because there is no DHCP service available on that link, the interface is assigned an address from a reserved pool to allow basic network functionality to be preserved in such an environment.

----------

## BrummieJim

This never used to happen and seems to be screwing up my wireless. How can I stop it doing this?

----------

## Dagger

edit /etc/conf.d/net

and set it as

```

config_eth0=( "null" )

```

----------

## BrummieJim

I presume this will stop eth0 working completely, unless I re-enable it. All I want is to go back to how it was before recent updates. If eth0 isn't there, it leaves it alone and brings up my wireless, else it uses eth0.

----------

## Ehnvis

i would suggest you to emerge netplug, and your problem should go away. Netplug will take care of your eth0 and if there is a cable it will bring it up otherwise it will keep it down.

----------

## BrummieJim

I've installed it, and I'll see how it goes, but why has this change happened and is there a place I should be looking for these changes?

----------

## BrummieJim

Seems to  be working better but I still needed to run dhcpcd -d eth1 to get my wireless network on-line. Any ideas why this isn't running automatically?

----------

## serial_penguin

I had similar problems with dhcpcd 3.1.5. The 169.254.xxx.xxx ip address could be removed by passing the -L option to dhcpcd in /etc/conf.d/net. However, if I connected via my wired interface then subsequent wireless connections would be messed up. ifconfig would indicate two connections, one to the wired interface (which now wasn't connected) and one to the wireless interface. I would have to manually take down the wired interfaced so the wireless one would function. I could find no option to turn this off! I have downgraded to dhcpcd 3.0.16-r1 and things are back to normal. Also, I have never been able to get netplugd to play well with both my wired and wireless interfaces.

----------

## BrummieJim

Fantastic, I'll give that a go!

----------

## BrummieJim

No, downgrading dhcpcd hasn't worked either. Any ideas

----------

## serial_penguin

 *BrummieJim wrote:*   

> No, downgrading dhcpcd hasn't worked either. Any ideas

 

Have you unemerged netplugd? If not try that. I don't have netplugd installed.

----------

## BrummieJim

Hi,

Yes, I uninstalled netplug, but after downgrading it seems that the wireless is much more stable. From looking at the logs it looks as if dhcpcd just isn't starting on eth1 even though it starts on eth0, until I do it manually.

----------

## Corona688

You can prevent dhcpcd from giving itself that obnoxious useless 169.x.y.z address with

```
dhcpcd_eth0="-L"
```

 I updated dhcpcd from 2.x to 3.x on a remote server and, instead of going to it's preprogrammed failover address when it couldn't contact a DHCP server, dhcpcd went to a zeroconf address!  Had to drive 150KM to go fix it on site.

Another gotcha is that, if it thinks it still has an old unexpired lease, it'll just use that on failure instead of properly timing out.  Putting this in your /etc/conf.d/net will delete that obnoxious lease file for you when you restart the interface.

```
# Remove cache for interface!  arrrggh!!!!

preup() {

        # Change 'wan' to eth0 or whatever

        if [[ "${IFACE}" == "wan" ]]

        then

                # Destroy cache so it can't use it!

                if [[ -f "/var/run/dhcpcd-${IFACE}.pid" ]]

                then

                        einfo "Clearing dhcpcd cache for ${IFACE} ..."

                        dhcpcd -k ${IFACE} 2> /dev/null > /dev/null

                        eend

                fi

                if [[ -f "/var/lib/dhcpcd/dhcpcd-${IFACE}.info" ]]

                then

                        einfo "Burning dhcpcd cache for ${IFACE} ..."

                        rm -f /var/lib/dhcpcd/dhcpcd-${IFACE}.info

                        eend

                fi

        fi

}
```

----------

## serial_penguin

Well, it's nice to know I wasn't the only one bitten by this dhcpcd upgrade. I don't know if Corona688's script fixed BrummieJim's issues, but it fixed mine with the exception that now dhcpcd complains at boot about there being no cache info on the offending interface. Now perhaps the real issue is whether one should really have to go to these efforts to have a functioning ethernet interface after an upgrade? Hopefully, a developer will have some insight here.

----------

## ahocevar

* Messages for package net-misc/dhcpcd-3.1.6-r1:

 * You have installed dhcpcd with DUID support.

 * Some DHCP server implementations require a MAC address only in the

 * ClientID field. These DHCP servers should be updated to be RFC

 * conformant. If you cannot do this, you can revert to the old

 * behaviour by using the -I '' option OR building dhcpcd with the

 * vram USE flag enabled.

For me, it worked to add

```
dhcpcd_eth0="-I ''"
```

 to /etc/conf.d/net.

----------

