Bug 847783

Summary: Bridge does not add ethX interfaces when they're marked "on cable connection" and offline during system start
Product: [openSUSE] openSUSE 12.3 Reporter: Laurenz Pruessner <spoil>
Component: YaST2Assignee: Michal Filka <mfilka>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Major    
Priority: P5 - None CC: mt, spoil
Version: Final   
Target Milestone: ---   
Hardware: HP   
OS: openSUSE 12.2   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Laurenz Pruessner 2013-10-26 20:42:29 UTC
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0

1. Go to YAST2 - Network Devices.
2. Configure a couple of eth-interfaces (in my case: eth1, eth2, eth3, eth4 on an Intel igb board, eth5 on a Realtek-add-on-card, eth6 as an on-board-Broadcom)
3. Mark them as active "on cable connection" in YAST2
4. Add a bridge (in my case br0)
5. Mark that bridge as brought up "on boot".
6. Add the nethwork interfaces (see no. 2) as bridged devices.
7. Save.
8. Configure the dhcpd to serve br0, Save, reboot.

Expected behaviour:
The bridge should be permanent, while the eth-interfaces may be switched off for power saving.
The eth-devices should become active as they detect a cable connection and start communicating with br0.

Found behaviour:
Those eth-devices that were plugged in during boot do work as expected.
All others are not added to the bridge.
When the formerly inactive eth-devices receive a cable, they do come up as expected, but they do not get added to the bridge and thus do not receive dhcp addresses. The remain connected but dead.

Analysis:
"brctl show" shows that only those devices that were plugged in during boot up get added to the bridge. Those that were offline during boot, never appear on the bridge, regardless of whether they're connected to a cable or not.

Workaround:
Add interfaces manually ("brctl addif ethX") somewhen after boot.
I actually added a cron-job that waits for a minute after reboot and then adds all the required interfaces.

Finding:
The config scripts seem to handle this scenario very misleadingly.

Reproducible: Always

Steps to Reproduce:
1. Go to YAST2 - Network Devices.
2. Configure a couple of eth-interfaces (in my case: eth1, eth2, eth3, eth4 on an Intel igb board, eth5 on a Realtek-add-on-card, eth6 as an on-board-Broadcom)
3. Mark them as active "on cable connection" in YAST2
4. Add a bridge (in my case br0)
5. Mark that bridge as brought up "on boot".
6. Add the nethwork interfaces (see no. 2) as bridged devices.
7. Save.
8. Configure the dhcpd to serve br0, Save, reboot.

Actual Results:  
Those eth-devices that were plugged in during boot do work as expected.
All others are not added to the bridge.
When the formerly inactive eth-devices receive a cable, they do come up as expected, but they do not get added to the bridge and thus do not receive dhcp addresses. The remain connected but dead.

Expected Results:  
The bridge should be permanent, while the eth-interfaces may be switched off for power saving.
The eth-devices should become active as they detect a cable connection and start communicating with br0.
Comment 2 Lukas Ocilka 2013-10-30 07:50:52 UTC
Michal, please, check whether the network isn't configured incorrectly
or whether there is a bug in network scripts.
Comment 3 Michal Filka 2013-10-30 08:51:58 UTC
I've checked that in 13.1 RC1. Config files created by yast seems good to me. 

# brctl show br0

shows only currently active interface as reported.

Problem is that inactive device cannot be added into a bridge (brctl addif). So, it seems as an issue in backend (I assume that netconfig is being used).

@Marius,
What is your opinion? Is it expected / supported to use such start mode for bridge slaves?
Comment 4 Marius Tomaschewski 2013-10-30 09:39:14 UTC
ifplug mode configured interfaces are invalid/unsupported as bridge ports.
Comment 5 Michal Filka 2013-10-30 11:48:53 UTC
I'll disable adding such ports in yast then.

@Laurentz:
According Comment#4 this scenario is unsupported.

@Marius:
Thanks.
Comment 6 Michal Filka 2013-10-30 21:58:30 UTC
Fixed in yast2-network 3.1.4 - ifplugd device cannot be selected as bridge port.
Comment 7 Laurenz Pruessner 2013-10-31 06:23:42 UTC
(In reply to comment #4)
> ifplug mode configured interfaces are invalid/unsupported as bridge ports.

Actually, does that statement refer to YAST2 or to brctl?

What drives the opinion that ifplugd-mode-devices should be invalid?
Actually, I can add them manually (brctl addif ethX), and when I do, the system performs as expected. It's just YAST's scripts that handle the scenario incorrectly.

I believe it'd be better to repair the network scripts rather than just disabling the YAST-option.
Comment 8 Michal Filka 2013-11-01 20:18:34 UTC
When do you brctl addif the device? When it is inactive (unplugged) or after plugging the cable?
Comment 9 Michal Filka 2013-11-04 10:13:31 UTC
@Marius,

this is a little bit out of YaST scope ... Could you provide some detailed info?

Thanks.
Comment 10 Laurenz Pruessner 2013-11-04 11:25:10 UTC
Hello Michal,
I added a couple of lines in the crontab that look like this:

...
@reboot brctl addif br0 ethX
...

This actually solves the weakness.
When I add those lines, everything starts working as expected (at least I haven't seen any misbehaviour anymore in any of the three test-systems since I added the cronjobs about a week ago).

Marius, in a PM to me, expressed his preference to -in YAST- disable adding ifplugd-controlled devices to a bridge, because the net scripts seem to not support the use-case fully, and he also pointed to a man page that supports his understanding. That is a convincing point, though it limits the use-case, which I need to utilize due to a difficulty I observe with a set of Intel i340-NICs.

That, in consequence, means that I'm going to have to permanently bypass the problem by adding the lines mentioned above to the crontab.
For me, that is acceptable, though irritating.

When I do so, the functionality works as expected, despite the weakness of the net scripts. I'll leave it up to you to decide whether you choose to improve the net scripts or disable the mechanism in YAST (and have the user manually implement it through a cron-job or a similar functionality).