FS#16625 - [initscripts] net: support more bridge device

Attached to Project: Arch Linux
Opened by Dwight Schauer (dschauer) - Tuesday, 13 October 2009, 20:01 GMT
Last edited by Tom Gundersen (tomegun) - Monday, 13 June 2011, 11:52 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 10
Private No

Details

Description:
When working with bridge devices it is often needed to set the forwarding delay to 0 to avoid dhcp and other network timeouts.

Additional info:
/etc/rc.d/network
/etc/conf.d/bridges
/etc/rc.conf

When one uses the stock example and br0="dhcp" in /etc/rc.conf, it can have problems and dhcpcd may always time out.

Steps to reproduce:
Set up:
/etc/conf.d/bridges:
bridge_br0="eth0"
BRIDGE_INTERFACES=(br0)
/etc/rc.conf:
eth0="eth0 0.0.0.0 up" # eth0="eth0 up" rarely works
br0="dhcp"
INTERFACES=(eth0 br0)

Then: /etc/rc.d/network restart
On some setups it will be sometimes work, on other setups it will never work.

Working solution I'm using:
Add the following to /etc/conf.d/bridges:
config_br0="brctl setfd br0 0"

And apply the following patch to /etc/rc.d/network (Is also attached)
---< start patch >---
--- network.0 2009-10-13 13:05:40.924603683 -0500
+++ network 2009-10-13 13:18:59.534523717 -0500
@@ -172,6 +172,15 @@
/usr/sbin/brctl addif $br $brif || error=1
fi
done
+ eval brconfig="\$config_${br}"
+ if [ -n "${brconfig}" ]; then
+ if ${brconfig}; then
+ true
+ else
+ echo config_${br}=\"${brconfig}\" \<-- invalid configuration statement
+ error=1
+ fi
+ fi
fi
done
}
---< end patch >---

At a mininum, it would be nice if a setting for the forwarding delay was made available.
   network.das-patch (0.4 KiB)
This task depends upon

Closed by  Tom Gundersen (tomegun)
Monday, 13 June 2011, 11:52 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Please reopen against netcfg.
Comment by Dwight Schauer (dschauer) - Tuesday, 13 October 2009, 20:07 GMT
In config_br0="brctl setfd br0 0" the "brctl" could be removed and put in /etc/rc.d/network. Of course, it would be nice if multiple brctl settings were allowed per configured bridge device.
Comment by Dwight Schauer (dschauer) - Sunday, 18 October 2009, 04:14 GMT
I have gone ahead and changed my setup to use the auto brctl so that /etc/conf.d/bridges is as follows:

bridge_br0="eth0"
control_br0="setfd br0 0"
BRIDGE_INTERFACES=(br0)

I've updated the patch for /etc/rc.d/network accordingly (attached).
---< start patch #2 >---
--- network.0 2009-10-16 09:27:11.481558619 -0500
+++ network 2009-10-17 23:13:41.831411877 -0500
@@ -172,6 +172,15 @@
/usr/sbin/brctl addif $br $brif || error=1
fi
done
+ eval brcontrol="\$control_${br}"
+ if [ -n "${brcontrol}" ]; then
+ if brctl ${brcontrol}; then
+ true
+ else
+ echo brctl control_${br}=\"${brcontrol}\" \<-- invalid control statement
+ error=1
+ fi
+ fi
fi
done
}
---< end patch #2 >--
   network.das-2-patch (0.4 KiB)
Comment by Tom Gundersen (tomegun) - Wednesday, 27 April 2011, 10:19 GMT
We are considering limiting the scope of the network initscript to not include this usecase. Is there any reason you cannot use netcfg instead?
Comment by Dwight Schauer (dschauer) - Thursday, 28 April 2011, 13:30 GMT
My basic premise with this bug report is that available network configuration for bridged network devices using what is supplied for netwwork device configuration in Arch Linux, results in deficient bridge devices (that are not immediately available when they are to be used). While other tools such as netcfg could be used, what is provided for network configuration should result is properly working network devices. Network devices that only work after a timeout I don't consider properly configured. The network initscript allows configuration of bridge devices, that is true, but not ones that are immediately available to use.
Comment by Tom Gundersen (tomegun) - Thursday, 28 April 2011, 14:01 GMT
We are currently looking at deprecating our bridge support. This means that whatever works now will continue to work (for the foreseeable future), but we will not add any new features and only fix regressions.

I believe this is ok as all the relevant use cases are also covered by other packages in core/extra (netcfg, wicd or networkmanager). So if this feature is already in netcfg I suggest we close this as "won't implement".
Comment by Thomas Bächler (brain0) - Thursday, 28 April 2011, 14:56 GMT
Bridge support in netcfg is rudimentary, it lacks all bridge options - but it works. For this deprecation to work, we must make sure the bridge support in netcfg is complete enough.
Comment by Bruce Bertrand (brucebertrand) - Sunday, 15 May 2011, 23:07 GMT
I would very much like to see this implemented.

I've been dealing with this on my virtualization servers, and it's a real pain when I do a remote reboot and the machine is left inaccessible because the bridge device never gets a dhcp address! :(

Whether or not the deprecation happens, consider this a +1 from someone who (happily) uses Arch for virtualization in a production environment and really requires good bridge support.
Comment by Rémy Oudompheng (remyoudompheng) - Monday, 13 June 2011, 11:15 GMT
I have starting adding support for bridge options in netcfg. They are available in the Git repository. If you are not going to implement this in initscripts, please close this bug. If features are missing in netcfg, please open a dedicated report. It is difficult to have an overview of netcfg feature requests if they are flagged as "initscripts".

Loading...