[6.8.0-RC5] No IP resolved after disabling bonding

The eth0 (br0) interfaces doesn't detect a connected cable.

Are you sure you connected to eth0 after disabling bonding?

 

eth0 is binding to the 10G NIC which has no cable connected because that port is tricky and temporary disables itself if the cable is jiggled. I have the cable plugged into the 1G NIC which unraid is binding to eth1.

 

Shouldn't it bind eth0 to the one with the cable connected to it if the system has more than one NIC and not all have cables? You know other people are going to do the same thing, thinking "Why should I have bonding enabled if I'm only using one of the NICs?" and then lose access because they have their LAN cable plugged into the secondary NIC.

 

I tried switching which Mac ID was tied to which port in the "Interface Rules" selection and that seemed to work. The 1G port was being assigned to eth0. However, when I disabled bonding, eth0 simply went away. The 10G switch's LED for that cable turned off and then solid orange a few seconds later. ifconfig showed no eth0. Looking at the syslog, it seemed that unsetting the bond was not successful. I've attached the diagnostics from after that happened.

 

vm1-diagnostics-20191107-2043.zip

What you describe is expected behavior.

Interfaces do not automatically change assignment depending on cable connection.

"Interface Rules" defines the interface assignments and these need to be adjusted accordingly.

 

Note: it is not recommended to bond interfaces with different speeds, in general this doesn't work reliably.

 

1 minute ago, bonienl said:

Note: it is not recommended to bond interfaces with different speeds, in general this doesn't work reliably.

I kinda don't gotta choice. The motherboard has two NICs and they're different speeds.

 

But back to the original issue. I removed the network cfg files and disabled the 10G NIC via the BIOS. On boot, the 1G NIC was assigned to eth0, no sign of eth1. All's looking good, right? Bonding is still enabled. I disable bonding, hit apply, and I lose network connectivity though this time the 1G port doesn't go solid orange. The GUI says it's acquiring an IP but doesn't.

vm1-diagnostics-20191108-0030.zip

It looks like something hardware related. The interface isn't active.

Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: Unknown!
	Duplex: Unknown! (255)
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: on (auto)
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: no

 

I have this bug for longtime too, if bonding setting change from Y to N. I also apply static MAC IP.

 

But solution also simple, just reboot it.

Edited November 8, 2019 by Benson

8 hours ago, bonienl said:

It looks like something hardware related. The interface isn't active.

I disabled it in the BIOS.

18 minutes ago, jbartlett said:

I disabled it in the BIOS.

The above is the 1G interface. Didn't you disable the 10G interface?

15 minutes ago, bonienl said:

The above is the 1G interface. Didn't you disable the 10G interface?

Sorry, I missed that. I did disable the 10G interface, there wasn't an option in the BIOS to disable the 1G. The 1G is indeed active and accessible as eth0 prior to changing bonding from Y to N. The diagnostics is after I made the change.

 

Understanding the potential confusion there, I created two diagnostics, one prior, one after, changing the bonding from Y to N. I gave it roughly 15 minutes after hitting the Apply button before taking the diagnostics for due diligence. The last comment in the syslog was deleting the interface for br0 and then nothing for the 15 minutes I waited.

 

I issued a reboot via the command line without removing the network cfg files and the system booted with an IP and with bonding disabled. So it seems the settings is valid but switching between the two live isn't working.

 

Before settings change:

vm1-diagnostics-20191108-1005.zip

After settings change:

vm1-diagnostics-20191108-1020.zip

After reboot:

vm1-diagnostics-20191108-1023.zip

 

Spoke too soon. Pulled up the Dashboard after rebooting and I see this.

 

<br />
<b>Warning</b>:  file_get_contents(/sys/class/net/bond0/statistics/rx_bytes): failed to open stream: No such file or directory in <b>/usr/local/emhttp/plugins/dynamix/include/DashUpdate.php</b> on line <b>338</b><br />
<br />
<b>Warning</b>:  file_get_contents(/sys/class/net/bond0/statistics/tx_bytes): failed to open stream: No such file or directory in <b>/usr/local/emhttp/plugins/dynamix/include/DashUpdate.php</b> on line <b>339</b><br />
0.0 bps

47 minutes ago, jbartlett said:

Spoke too soon. Pulled up the Dashboard after rebooting and I see this.

That's a cosmetic bug. Change the interface to monitor to "eth0"

It was already set to eth0.

 

Changing it to "lo" and then back to "eth0" corrected it. It worked properly again after a reboot. I'm assuming that there's a persistent setting that gets updated when the interface to monitor is changed but when changing the bonding from Y to N, that setting isn't updated to something other than "bond0".

Now here's something interesting. Switching bond from N to Y worked. Immediately changing it from Y to N also worked. Repeated successfully several times. Rebooted, was able to still change it successfully.

vm1-diagnostics-20191108-1140.zip

 

Removed the two network cfg files and rebooted. I was once again not able to change bonding from Y to N as above. Rebooted and was able to repeat the issues above - after rebooting, I was able to switch between bonding & non-bonding dynamically at-will with no issues.

 

So I looked into what's different between the two. I took a snapshot of /boot/config, /usr/local/emhttp, and /var/local/emhttp and compared them before & after.

 

Rebooting after removing the network*.cfg files caused things to default. network.cfg did not exist after booting, probably because no changes were made yet. The notable differences that I could see before & after was with network.ini with bonding enabled again.

 

 

I don't think there is anything wrong with your code. I suspect the issue is in the defaults applied if no network.cfg file exists.

 

Edited November 8, 2019 by jbartlett