# who's reconfigged my LAN? [NOT solved]

## Gentree

Hi,

the desktop m/c is connected to WAN via a one port ADSL router supplied by my ISP. That is set to configure by dhcp

I also have a small embedded system linked to another NIC on the desktop, that is statically configured on each end. 

Three days ago I was able to view the http server running on the embedded system, all was as expected. 

Yesterday Firefox failed to connect to it. So I tried command line ping , no resp. 

So I checked ifconfig

```
eth_real: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 169.254.102.87  netmask 255.255.0.0  broadcast 169.254.255.255

```

[I have a udev rule that names it eth_real]

Since the other end is configured in 198.162.x.x space I'm not surprised I cannot reach it any more but where did this address come from ???

I should add that in this time frame I've been rebuilding kernel (2.6.32) a few times to remove the old ide_core and migrate to all SATA names. 

On the face of it this should not affect networking and I have not knowingly messed with anything net related in the kernel in that period. 

So I have several questions.

1. where is this IP coming from , I can't find it /etc/conf.d yet it remains on reboot.

2. who changed this setting in the last few days? If it was I, how?

There's some comments about  APIPA  net.example using this range but I don't see that being used anywhere.

 :Sad: 

TIA, Gentree.   :Cool: 

----------

## Jaglover

I believe this is the fallback address you get if your network connection cannot be established.

----------

## Gentree

There is no 'fallback' if I specify a fixed IP in /etc/conf.d/net 

That's what I don't get. I should be able to configure the NIC even if there's nothing plugged into it. 

what am I missing?

Thx   :Cool: 

----------

## NeddySeagoon

Gentree,

dhcpcd, or one of its friends, ran for the interface.

It could not contact a dhcp server, so it assigned itself a link-local IP

I guess your net file is in a mess ?

----------

## Gentree

Thanks Ned. 

/etc/conf.d/net has not changed since 12th Jan 2013 according to its datestamp.

Three days ago it worked. 

 :Confused: 

----------

## NeddySeagoon

Gentree,

Look in emerge.log to see what got updated in the last 3 or 4 days

----------

## Gentree

No emerge activity since June.   :Cool: 

----------

## aim nano

Perhaps their is an issue, then, with your DHCP server/modem/router.  I just had to replace a modem for a client that had a broken DHCP server (was assigning conflicting ips)...it can happen

----------

## Gentree

Thanks for suggestion but the problem is that this NIC should be  static with an IP I have written into conf.d/net

Also there is no dhcp server available to that interface, so if dhcpd does try to configure it , it will fail (and presumably attribute the IP I'm seeing as a fallback). 

So I have two problems. Firstly conf.d/net is not using the static IP config for this NIC and second that something , somewhere is trying to use dhcpd on the this interface. 

That has happened within the last 3 days. 

 :Confused: 

----------

## Gentree

just found this near the end of /var/log/messages

```

Oct 27 11:03:50 localhost init: Entering runlevel: 3

Oct 27 11:03:51 localhost dhcpcd[1773]: version 5.5.6 starting

Oct 27 11:03:51 localhost dhcpcd[1773]: all: not configured to accept IPv6 RAs

Oct 27 11:03:51 localhost kernel: [   14.896355] eth_real: link up, 100Mbps, full-duplex, lpa 0x41E1

Oct 27 11:03:51 localhost kernel: [   14.897660] eth_mobo: no link during initialization.

Oct 27 11:03:51 localhost dhcpcd[1773]: eth_real: checking for 169.254.102.87

Oct 27 11:03:51 localhost dhcpcd[1773]: eth_mobo: waiting for carrier

Oct 27 11:03:51 localhost dhcpcd[1773]: eth_real: carrier lost

Oct 27 11:03:51 localhost dhcpcd[1773]: eth_real: carrier acquired

Oct 27 11:03:51 localhost dhcpcd[1773]: eth_real: checking for 169.254.102.87

Oct 27 11:03:51 localhost dhcpcd[1773]: eth_mobo: carrier acquired

Oct 27 11:03:51 localhost dhcpcd[1773]: eth_mobo: carrier lost

Oct 27 11:03:51 localhost dhcpcd[1773]: eth_mobo: waiting for carrier

Oct 27 11:03:57 localhost dhcpcd[1773]: eth_real: using IPv4LL address 169.254.102.87

Oct 27 11:03:57 localhost dhcpcd[1773]: forked to background, child pid 1869

....

Oct 27 11:04:00 localhost dhcpcd[1869]: eth_real: broadcasting for a lease

```

question is : Why ?

what is triggering eth_real to use dhcpd and why is it not taking the static IP I define in /etc/conf.d/net ?

----------

## TomWij

For an explanation what the IP is, see http://wiki.wireshark.org/APIPA

Can we see /etc/conf.d/net?

----------

## Gentree

```

config_eth_real="192.168.212.3/8"

dhcpcd_wlan0=" -C resolv.conf"

dhcpcd_wlan1=" -C resolv.conf"

config_eth_mobo="dhcp"

dhcpcd_eth_mobo=" -C resolv.conf"

```

I've stripped out all the waffle and comments. This should be the essence of it. 

thx

 :Cool: 

PS , just in case it is relevant , I think I did activate  CONFIG_PATA_ACPI=y in the kernel while messing with the ide/sata changes. Should not affect this but I thought it should be mentioned since that is something that changed in the relevant period.

----------

## Hu

Although this is not the root of your problem, setting your address as a /8 when you are clearly using the standard reserved address range is wrong.  You probably want a /24.

----------

## TomWij

 *Gentree wrote:*   

> [I have a udev rule that names it eth_real]

 

Is this perhaps the source of the problem? If you don't have that udev rule and use the name it normally gives, can you still replicate the problem?

I think it has to do something with the timing of the udev rule kicking in and the moment the net scripts run.

If that's the case, you'll probably want to play around with dependencies between the init script.

Alternatively, you can opt to move the net scripts to a different run level to see if that helps.

----------

## Gentree

Yes, I don't know why I put that as the mask. 

However, when I supply that to ifconfig  I get my LAN back.

It remains a mystery why this line is apparently not being used and dhcp is instead being run on this interface. 

Some of the best minds on this forum seem unable to spot it. 

 :Confused: 

----------

## Gentree

 *Quote:*   

> I think it has to do something with the timing of the udev rule kicking in and the moment the net scripts run. 

 

Thanks, I'd thought that it may be some subtle difference in timing using a different driver for IDE disk, but booting the old ide enabled kernel also shows the same problem. 

Perhaps CONFIG_PATA_ACPI=y modified the timing. 

I'll look into it.

----------

## _______0

I've seen this before, the culprit here is the router that triggers dhcp in your  linux box.

Regardless of whether you've added static ip some mechanism in modern routers trigger dhcp.

----------

## TomWij

 *_______0 wrote:*   

> I've seen this before, the culprit here is the router that triggers dhcp in your  linux box.
> 
> Regardless of whether you've added static ip some mechanism in modern routers trigger dhcp.

 

Which mechanism does that? If there is one, there must be a RFC to cover it; I haven't heard of this mechanism yet, without the DHCP client configured to listen this simply can't happen.

----------

## Gentree

Still not any closer to solving this.

I tested removing the ACPI module to see if that was affecting timing with libata.noacpi=1  on kernel line. No change.

I tried removing my udev renaming to leave it as eth0, same result except that it is now using 169.254.138.129   :Confused: 

While ------O's suggestion seems improbable , there have been changes at the WLAN end in this period. A number of sites that were failing to respond recently, that I had to use a proxy to access, have been unblocked.

Also, if the router was not powered up at boot time, Gentoo used to get stuck during booting, waiting for dhcp to timeout on the router connection

That is no longer happening.

```

Oct 28 06:13:23 localhost init: Entering runlevel: 3

Oct 28 06:13:24 localhost dhcpcd[1769]: version 5.5.6 starting

Oct 28 06:13:24 localhost dhcpcd[1769]: all: not configured to accept IPv6 RAs

Oct 28 06:13:24 localhost kernel: [   14.890814] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1

Oct 28 06:13:24 localhost kernel: [   14.892140] eth_mobo: no link during initialization.

Oct 28 06:13:24 localhost dhcpcd[1769]: eth0: checking for 169.254.138.129
```

So dhcpcd is getting run on "all".  Why has the explicit rule that I put in conf.d/net suddenly started being ignored ?

----------

## _______0

 *TomWij wrote:*   

>  *_______0 wrote:*   I've seen this before, the culprit here is the router that triggers dhcp in your  linux box.
> 
> Regardless of whether you've added static ip some mechanism in modern routers trigger dhcp. 
> 
> Which mechanism does that? If there is one, there must be a RFC to cover it; I haven't heard of this mechanism yet, without the DHCP client configured to listen this simply can't happen.

 

Gentoo has had this problem for a while. It has to do with default dhcpcd configuration when you install it. dhcpcd doing wtf it wants to do.

However I highly doubt ATA and ACPI kernel config got anything to do with.

How new is your mobo? Perhaps some crazy UEFI settings is getting in the way.

----------

## Gentree

 *Quote:*   

> dhcpcd doing wtf it wants to do.

 

It would probable be helpful if you were more specific with these claims. What specifics can you provide that is at the level of a bug report , rather then wild unsubstantiated claims. I'm not saying you're wrong but it needs backing up.

The mobo is the same one I've been using for at least five years and I see no need to put everything into question now. Networking has never give me this problem before and I've been using this evolving Gentoo installation for about 10 years. 

It is not impossible that the router got a firmware update in the period in question (that I am never informed about). 

There have also been external changes in WLAN responses as I noted above.

----------

## Gentree

Something's definitely screwing with my head now. 

I have this line in /etc/udev/rules.d/10*rules

```
KERNEL=="eth*", ACTION=="add", DRIVERS=="8139too", NAME="eth_real"

```

It was what I had at the start of this thread, it gave me a device called eth_real as reported. 

To try TomWij's suggestion of leaving as eth0 , I put a single # in front to comment it out. It did not resolve IP issue so I took the hash mark out again.... reboot ... 

But now it still gives me eth0 device and not eth_real. 

```

Oct 28 18:37:24 localhost kernel: [    7.446998] 8139too Fast Ethernet driver 0.9.28

Oct 28 18:37:24 localhost kernel: [    7.447223] ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16

Oct 28 18:37:24 localhost kernel: [    7.447232] 8139too 0000:01:0a.0: PCI INT A -> Link[APC1] -> GSI 16 (level, high) -> IRQ 16

Oct 28 18:37:24 localhost kernel: [    7.447888] eth0: RealTek RTL8139 at 0xc400, 00:08:a1:73:74:e9, IRQ 16

Oct 28 18:37:24 localhost kernel: [    7.475102] usb usb2: configuration #1 chosen from 1 choice

```

forcedeth driver installs for eth1 and udev renames to eth_mobo as expected. 

That's now two config lines being ignored. What the hell is this?

 :Mad: 

----------

## Gentree

Just noticed, while scrutinising boot messages scrolling by:

 *Quote:*   

> populating /dev with existing devices through uevents

 

Is there some kind of caching mechanism screwing all this up?

----------

## Gentree

Ah-ha! 70-persistent-net.rules 

```

# PCI device 0x10ec:0x8139 (8139too)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:a1:73:74:e9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

```

I have a similar line that I've remmed out before. Though that was quite a while ago judging by the date of the backup I made before manual editing. 

7665 -rw-r--r-- 1 root root 2247 Oct 27 21:49 /etc/udev/rules.d/70-persistent-net.rules

7668 -rw-r--r-- 1 root root 2051 Nov 10  2009 /etc/udev/rules.d/70-persistent-net.rules.not

The file headers says:

 *Quote:*   

> # This file was automatically generated by the /lib/udev/write_net_rules
> 
> # program, run by the persistent-net-generator.rules rules file.
> 
> 

 

What triggered that file being written to two days ago?

Well that's got me back to eth_real on  169.254.102.87 , but I still need to find out why my settings for eth_real in conf.d/net is not being respected.

----------

## Gentree

Well, I seems to be discussing this with myself by this stage but just in case:

I inserted a  garbage line into /etc/conf.d/net and it produced no error. 

```
init 3 

```

messages:

```
Oct 29 11:19:36 localhost init: Entering runlevel: 3

Oct 29 11:19:37 localhost dhcpcd[1774]: version 5.5.6 starting

Oct 29 11:19:37 localhost dhcpcd[1774]: all: not configured to accept IPv6 RAs

Oct 29 11:19:37 localhost kernel: [   14.064341] eth_real: link up, 100Mbps, full-duplex, lpa 0x41E1

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier lost

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier acquired

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier lost

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier acquired

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: acknowledged 192.168.0.10 from 192.168.0.254

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: checking for 192.168.0.10

Oct 29 11:19:42 localhost dhcpcd[1774]: eth_real: using IPv4LL address 169.254.102.87

Oct 29 11:19:42 localhost dhcpcd[1774]: forked to background, child pid 1824

Oct 29 11:19:42 localhost dhcpcd[1824]: eth_mobo: leased 192.168.0.10 for 864000 seconds

```

At this stage it's looking like /etc/conf.d/net is not even being read !

 :Confused: 

PS Indeed. Removing conf.d/net altogether makes no difference whatsoever. 

What has perverted the normal network setup proceedure in the last few days?

----------

## Gentree

Resume so far:

Jaglover; I believe this is the fallback address you get if your network connection cannot be established.

I'd already mentioned APAPI, the question is why is this interface not using the fixed IP provided.

NeddySeagoon: I guess your net file is in a mess ?

Good guess but , no.

NeddySeagoon:Look in emerge.log to see what got updated in the last 3 or 4 days

Not neither.

aim nano : Perhaps their is an issue, then, with your DHCP server/modem/router... broken DHCP server 

DHCP seems to work, what you are suggesting is broken client.  Where is evidence of this being a known issue?

Hu: Although this is not the root of your problem, setting your address as a /8 when you are clearly using the standard reserved address range is wrong. You probably want a /24.

right , so that's another thing that is NOT the cause of this problem. 

Tom Wij: If you don't have that udev rule and use the name it normally gives, can you still replicate the problem? 

Yes, so it's not that either.

---------o : Regardless of whether you've added static ip some mechanism in modern routers trigger dhcp.

Sounds rather nonsensical since it is the dhcp CLIENT that runs on gentoo. It is the client that "triggers" dhcp , not the server. 

After that, five posts by me with no reply from anyone. 

Guess we're out of ideas of a possible explanation then.   :Sad: 

----------

## NeddySeagoon

Gentree,

dhcp is the default for any interface not listed in the net file.

your interface starts out with a ethX assigned by the kernel

It may get a udev permanent name before your own rule renames it again

Maybe dhcpcd runs when the interface has one of its transient names and it is therefore not listed in the net file.

dmesg may help.

----------

## Gentree

Thanks Neddy. 

As previously posted output shows, the udev renaming happens during boot phase. dhcpd seems to be the first thing to happeni in runlevel 3 by which time I have the renamed interfaces. As the experiment of removing renaming showed this is not a factor and some critical time oddity is not the cause. 

If I add net.eth_real to default , it gets configured from conf.d/net but dhcpd no longer fires and I don't get WLAN. 

I have added both net.eth_real and net.eth_real (the outward pointing NIC) to default and get network configured in an equivalent state to before but cannot guarantee this is the same way I had it before. 

One think is sure, I did not use rc-update to remove them nor explicitly touch network config in any way to provoke this change. 

Exactly what broke the LAN config remains a mystery.

----------

## NeddySeagoon

Gentree, 

How does dhcpcd get run?

Is it in your default runlevel or called by the network startup script?

----------

## Gentree

No, dhcpcd is not explicitly in any runlevel.

hotplug is in runlevel 3 but I don't see anything in logs explicitly stating it as starting

current log (with both net.eth scripts explicitly in default) looks that same as before:

```
Oct 29 22:27:19 localhost init: Entering runlevel: 3

Oct 29 22:27:20 localhost dhcpcd[1892]: version 5.5.6 starting

Oct 29 22:27:20 localhost dhcpcd[1892]: all: not configured to accept IPv6 RAs

Oct 29 22:27:20 localhost dhcpcd[1892]: eth_mobo: rebinding lease of 192.168.0.10

```

conf.d/net specifies it to use dhcp but as noted above it was still doing this even when that file was not present. 

conf.d/net seems to get called when a net.eth* is explicitly started. If none are in rc-update -s it is not read.

 *Quote:*   

> dhcp is the default for any interface not listed in the net file. 

 

Default for what? What needs a default ? Knowing what process is triggering all this may help in understanding how it is configured and why it is or is not running. 

I get the impression you know and you are just pointing me to asking the right question. 

If you have an idea what is running what it may speed things to up a bit to say so. I'm going to have quit for tonight very shortly.

thanks.

----------

## TomWij

It really sounds like /etc/conf.d/net isn't read at all somehow.

$ md5sum /etc/init.d/net.lo

be4d4227cd5c7647493edae9131f1798  /etc/init.d/net.lo

1. Please verify that you get the same result as above; if not, remove it and merge net-misc/netifrc again.

2. Remove any other /etc/init.d/net.* entries.

3. Symlink the entries again.

4. Use `rc-update add net.* default` for each entry you want to start by default.

5. Ensure /etc/conf.d/net has what you want it to do.

6. Reboot.

I think this should ensure /etc/conf.d/net is read; if not, you are suggested to file a bug at https://bugs.gentoo.org such that the maintainers can look further into what happened and how to fix it.

----------

## Aiken

 *TomWij wrote:*   

> 
> 
> $ md5sum /etc/init.d/net.lo
> 
> be4d4227cd5c7647493edae9131f1798  /etc/init.d/net.lo
> ...

 

That looks like you are running unstable. My system is running stable and the md5 of my /etc/init.d/net.lo is 564bc20feda1883b3f7001cdbb3cfa04 and it comes from openrc.

----------

## TomWij

Err, sorry, I thought that change happened to stable yet, I was wrong and haven't checked that; though given that the hash is different, maybe it is interesting to try the unstable version?

Regardless, thank you for posting the stable hash such that he can check against that instead.

----------

## ChrisJumper

Hi Gentree!

If you have still your /etc/conf.d/net like that:

```
config_eth_real="192.168.212.3/8"

dhcpcd_wlan0=" -C resolv.conf"

dhcpcd_wlan1=" -C resolv.conf"

config_eth_mobo="dhcp"

dhcpcd_eth_mobo=" -C resolv.conf"

```

Your issue should be that your udev-Rule named your device eth0 and your rules aim at a device named eth_real.

Try 192.168.212.3 with a slash 24 netmask:

```
config_eth0="192.168.212.3 netmask 255.255.255.0 brd 192.168.2.255"
```

Or if you really use a slash 8 netmask:

```
config_eth0="192.168.212.3 netmask 255.0.0.0 brd 192.168.2.255"
```

 *Gentree wrote:*   

> 
> 
> Well, I seems to be discussing this with myself by this stage but just in case:
> 
> I inserted a  garbage line into /etc/conf.d/net and it produced no error. 
> ...

 

Wow with your init 3, your system switching to Init Lvl 3 :)

I think your issue is that the Network-Device names have changed. Your udev-Rule:

```
# PCI device 0x10ec:0x8139 (8139too)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:a1:73:74:e9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" 
```

Will declare your Network-Device as eth0.

What Names use ifconfig you have after your System boot?

And are you sure that your cleaning lady or cleaner did not unplug your Lan cable and put the plug back in the wrong Networkcard? But i suppose that you got the update of udev which rename your device-names if you have no rule as described before.

----------

## Chiitoo

Heya.  ö/

Just a bit of a side-question from the sidelines!

 *TomWij wrote:*   

> I think this should ensure /etc/conf.d/net is read; if not, you are suggested to file a bug at https://bugs.gentoo.org such that the maintainers can look further into what happened and how to fix it.

 

Would that really be prudent, considering for one, they are using dhcpcd-5.5.6 (which, I think, was removed from Portage nearly 10 months ago)?

Just wondering.  ^^;

As for the issue, I doubt I could come up with any better ideas.  It does certainly seem like a very interesting one, especially since there has been “no emerge activity since June”.  If no configuration files have been modified either, first thing that comes to my mind are external changes (router box, cables, and so on and so forth).

I wouldn't probably get /too/ paranoid just yet.  Just.

Best of luck on your journey towards closure on this!

----------

## TomWij

Well spotted, interesting, can you (Gentree) check why the dhcpcd is like that? The latest stable seems to be different; so, maybe upgrading the system might yield a difference...

----------

## Gentree

TomWij, this system is badly out of date. Part of my aim in looking at this is to decide whether it is worth updating (which will be problematic) or install a fresh system (which will be a PITA to get all the tweaks and configs just the way I want it like the current system). Either way I have a significant time investment that I'm not looking forward to. 

Before considering introducing even more problems by changing package versions I need to know this box is in a stable state and essentials like networking are in a know running state. Until last week that had bee the case for a very long time. 

something happened that broke networking and I still have little idea what caused that change. That, I do not like.

----------

## NeddySeagoon

Gentree

```
# PCI device 0x10ec:0x8139 (8139too)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:a1:73:74:e9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
```

What version of udev do you have?

udev-17? approx was the last version that supported renaming to kernel names

Hot plugging starts all detected interfaces.  They need not be listed in the default runlevel.

See the comments in /etc/rc.conf

Try listing your transient interface names in the

```
rc_hotplug="!net...."
```

entry

----------

## eyoung100

See last post: Wireless adapter always going to 169.254.xxx.xxx?

I believe you are experiencing a hardware failure in your Ethernet Adapter, eth_real

----------

## NeddySeagoon

eyoung100,

... but dhcpcd shold never be run for the interface.

It should get the statically assigned IP, or no IP at all

----------

## eyoung100

What's the default behavior of the *.net scripts, if manually assigning an IP Address Fails  :Question:    Following Logic:

Manual Assignment Fails for eth_real   :Arrow:  Other Scripts Require net to be up   :Arrow:  Fallback to DHCP Assignment for eth_mobo  :Arrow:  Manual Assignment tried again for eth_real, and Fails due to Hardware Failure.  Evidence is in log:

```
Oct 29 11:19:36 localhost init: Entering runlevel: 3 

Oct 29 11:19:37 localhost dhcpcd[1774]: version 5.5.6 starting 

Oct 29 11:19:37 localhost dhcpcd[1774]: all: not configured to accept IPv6 RAs 

Oct 29 11:19:37 localhost kernel: [   14.064341] eth_real: link up, 100Mbps, full-duplex, lpa 0x41E1 

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87 <-- Previous Address Failure Released

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10 

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier lost <--Address Assignment Fails

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier acquired <--Address Assignment Retries and fails again

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87 <--Static Attempt Fails

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier lost 

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier acquired 

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10 

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: acknowledged 192.168.0.10 from 192.168.0.254 

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: checking for 192.168.0.10 

Oct 29 11:19:42 localhost dhcpcd[1774]: eth_real: using IPv4LL address 169.254.102.87 

Oct 29 11:19:42 localhost dhcpcd[1774]: forked to background, child pid 1824 <--Failing Card forked to background, because comms failed at DHCP Server Whiile Repeating Above Arrowed Steps

Oct 29 11:19:42 localhost dhcpcd[1824]: eth_mobo: leased 192.168.0.10 for 864000 seconds 
```

the DHCP Server is irrelevant here, but the Carrier Signal still needs to communicate with the router to tell the router, "Hey, I'm taking this address<static address> don't give it to anyone else," and that communication is failing when the process is forked.  The process is forked because the self-assigned IP address cannot be released.

Hunch: Does this failure also occur on Windows, if machine has Windows  :Question: 

----------

## TomWij

dhcpcd shouldn't be working on that interface if it were configured as static; so, those lines shouldn't appear in the log at all. Dunno about a hardware failure, it appears that dmesg doesn't report it; so, it would be a silent hardware failure if it is. I stay by the thought that /etc/conf.d/net isn't getting read for one or another reason.

Given that the system has became outdated, this might be some bug with something that has since already been resolved; the interesting thing though, is that this just so suddenly happened which makes me think back about the timing bug mentioned near the start of the thread. Another option is that dhcpcd is somehow ran independent from the net scripts; but well, I suppose that would be known if that were the case.

I'd say a try to update or a reinstall is adviced to ensure a recent system; because well, at this point one would have to use more low level debugging techniques (changing the openrc shell scripts, firing up tcpdump or wireshark and look what goes wrong with the protocol, etc...) which might take longer than to just upgrade or reinstall the entire system instead.Last edited by TomWij on Wed Oct 30, 2013 10:37 pm; edited 3 times in total

----------

## eyoung100

Humor me, and replace the card.  If it doesn't fix it, everyone here is welcome to say I Told You So!  

----------

## Gentree

 *Quote:*   

> I stay by the thought that /etc/conf.d/net isn't getting read for one or another reason. 

 

That is the case unless I add net.eth_mobo and net.eth_real to default.

It seems that without that, hotplug is running dhcpcd automatically and  /etc/conf.d/net is not read at all. I confirmed that above by adding a deliberate syntax error and finally removing it altogether. 

@ Neddy

dmesg | grep udev

[    6.514642] udev: starting version 151

[    7.002365] udev: renamed network interface eth0 to eth_real

[    7.255754] udev: renamed network interface eth0 to eth_mobo

udev 151, last one to recognise /dev/hd* device names. 

Removing that limitation was what started the kernel changes. All drives are now on /dev/sd* but I have not changed udev or any other packages because I want to know what broke networking in the few days I was making ata/sata change over.

----------

## _______0

Could this be related to the newnet USE flag in udev or openrc? I remember that was a headache.

What about some other program starting dhcp? Are you running a full blown DE by any chance?

----------

## UberLord

```
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real

Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo
```

So the same instance of dhcpcd (as they have the same PID is working on two interfaces).

This means that dhcpcd is being started by /etc/init.d/dhcpcd (check for runlevels for it's presence).

As such it will ignore any conf.d/net rules you have inplace.

This is generally a good thing btw and how dhcpcd is designed to work since dhcpcd-5 especially on a multi homed system such as a laptop with wired and wireless potentially on the same subnet.

Also, you need dhcpcd-6.1.x to work well with udev device renaming OR have dhcpcd depend on udev-settle or similar if in the same runlevel or using something like systemd.

----------

## Gentree

thanks for the details, your uberness. 

```
This means that dhcpcd is being started by /etc/init.d/dhcpcd (check for runlevels for it's presence).

As such it will ignore any conf.d/net rules you have inplace. 
```

That would explain net rules being ignored, thanks. However, dhpdcd is not in any run level. 

I'm still unclear of the precise trigger for dhcpcd being the first thing to post output on runlevel 3 starting. 

There were two clear changes in behaviour when this started. Firstly eth_real was getting dhcp APIPA fallback IP instead of the hard coded net rules static. 

Secondly, during startup when router was not powered up I would have to wait for dhcp time-outs on eth_mobo, this was no longer after the change (or perhaps it was not visible once X11 came up, whereas I normally noticed it since I see boot messages scrolling).

These observations lead me to conclude that eth_real and eth_mobo were is default RL as they are again now and net setup seems to behave as before the problem. 

All I was working on last w/e was changing ata/sata in kernel. I don't see any way this could have affected network settings.

I have a vague recollection of reviewing rc content many months ago. Is there any mechanism which could have cached the static IP on eth_real since then if I had removed it from the runlevel configuration at that time and that could have been cleared by the kernel rebuild last week?

----------

## UberLord

 *Gentree wrote:*   

> That would explain net rules being ignored, thanks. However, dhpdcd is not in any run level.

 

Then maybe something is depending on it OR something is starting it with either 0 or >1 interface names.

I've not used Gentoo in ages, but iirc the rc-status command should show all services running in the runlevel.

If dhcpcd is running AND dhcpcd is listed then  the former is true.

If dhcpcd is running AND dhcpcd is not listed then the latter is true. This is more tricky to find, but would either be the Gentoo net scripts or something like NetworkManager.

 *Quote:*   

> 
> 
> Secondly, during startup when router was not powered up I would have to wait for dhcp time-outs on eth_mobo, this was no longer after the change (or perhaps it was not visible once X11 came up, whereas I normally noticed it since I see boot messages scrolling).
> 
> 

 

Could be that one of your dhcpcd config settings is turning off carrier detection OR the carrier detection on eth_mobo is faulty.

If the router isn't powered then the carrier should be down, assuming a direct connection. If via a hub/switch then ofc carrier would be up and you're SOL.

 *Quote:*   

> 
> 
> I have a vague recollection of reviewing rc content many months ago. Is there any mechanism which could have cached the static IP on eth_real since then if I had removed it from the runlevel configuration at that time and that could have been cleared by the kernel rebuild last week?

 

Very doubtful.

dhcpcd and dhclient do cache the last assigned address and try to re-use it, but this shouldn't affect any static config you may have.

----------

## Gentree

Thanks again,

in default run level to most likely things to cause dhpcd to start are netmount and udev-postmount.

Since, without the devices being explicitly started via net.eth* there will be nothing up, that is not worrying that something is triggering it. 

My underlying mystery in all this is that something changed last week and I did not do it. 

Clearly eth_mobo ( the DHCP configure net did use to be run in the boot run level since it used to hold up the boot process if the router was off. 

The static device did used to get configured until the change last week. This would seem to imply that eth_real was being started explicitly before that time. 

Since it seems high-fliers like Neddy and Uberlord can't see how my kernel change could have done this and considerable discussion has not shown anything that could account for the static rules being read without having eth_real started explicitly somewhere, I'm left with a problem to explain what changed my network config. 

That is a worry.

----------

## UberLord

To be fair, I'm just talking about dhcpcd here.

I've not used Gentoo directly for years.

But still, the most likely candidates for the change with be udev, openrc, netcfg scripts (i believe they have been slit from openrc now).

I really don't think that the kernel is at fault, nor is dhcpcd directly as it's just doing what it's told to.

----------

## _______0

here /etc/init.d/sshd start starts dhcpcd. I have to manually kill it afterwards.

check that.

----------

## artbody

hy 

what says 

```
 ifconfig -a
```

with the new udev it looks something like this

```

enp0s20: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.2.8  netmask 255.255.255.0  broadcast 192.168.2.255

        inet6 fe80::217:31ff:fe80:9118  prefixlen 64  scopeid 0x20<link>

        ether 00:17:31:80:91:18  txqueuelen 1000  (Ethernet)

        RX packets 296334  bytes 412210614 (393.1 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 166116  bytes 19979937 (19.0 MiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 0  (Local Loopback)

        RX packets 5264  bytes 6631565 (6.3 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 5264  bytes 6631565 (6.3 MiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

```

```
rc-update del net.ethX
```

then the old link net.ethX should be renamed - in my case to net.enp0s20

```
rc-update add net.enp0s20 default
```

the name enp0s20 is given by new udev-version

----------

