FS#11761 - [patch] dhcpcd times out when using bridge

Attached to Project: Arch Linux
Opened by Jonathan Liu (net147) - Thursday, 16 October 2008, 06:12 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 10 May 2009, 05:55 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Dale Blount (dale)
Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Ronald van Haren (pressh)
Roman Kyrylych (Romashka)
Dan McGee (toofishes)
Architecture All
Severity Medium
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:
When /etc/rc.d/network is started during bootup, the DHCP client times out because it takes too for the bridge to switch from learning state to forwarding state. The forwarding delay is usually around 15 seconds by default.

Additional info:
* kernel26 2.6.27-2
* initscripts 2008.09-2

Steps to reproduce:
1. Add following to /etc/rc.conf:
eth0="eth0 0.0.0.0 promisc"
INTERFACES=(eth0 br0)
br0="dhcp"
bridge_br0=(eth0)
BRIDGE_INTERFACES=(br0)
2. Restart network
/etc/rc.d/network restart

This can be fixed by reducing the forwarding delay for the bridge in the network script.
   network.patch (0.3 KiB)
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Sunday, 10 May 2009, 05:55 GMT
Reason for closing:  Fixed
Comment by Glenn Matthys (RedShift) - Thursday, 16 October 2008, 10:39 GMT
That's not really a clean solution. And it might even have more impact than you can think of.
Comment by Dale Blount (dale) - Wednesday, 03 December 2008, 16:38 GMT
I increased dhcp timeout in /etc/conf.d/dhcpcd to fix this on mine.
Comment by Ronald van Haren (pressh) - Thursday, 04 December 2008, 12:10 GMT
Dale, the preferred method for changing the timeout would be /etc/dhcpcd.conf. The only reason /etc/conf.d/dhcpcd is still there is because /etc/dhcpcd.conf does not yet support all command line options (for example the quiet uption).

Besides that, as I don't use a bridged network, you are saying this is just a configuration issue and can be closed?
Comment by Dale Blount (dale) - Thursday, 04 December 2008, 13:15 GMT
I'm just saying I needed to increase the dhcp timeout on one of my boxes using a bridge. They all didn't require this so I don't really know why some did and some didn't.
Comment by Glenn Matthys (RedShift) - Thursday, 04 December 2008, 13:21 GMT
That's because the DHCP request/offer wasn't handled as fast as the others. Since it can take up to 30 seconds for the bridge to start forwarding traffic, there's a very very limited time dhcpcd can do its work. Sometimes it's just enough, other times it isn't.
Comment by Jonathan Liu (net147) - Thursday, 04 December 2008, 22:31 GMT
I only noticed this after upgrading some packages.
DHCP used to work fine in combination with a bridge with the default settings but after the upgrade the DHCP takes a long while and times out.
It seems the bridge takes longer to switch to forwarding state after the upgrade.

Would it be a good idea to make the forwarding delay a config option that can be set in rc.conf?
Comment by Kenni Lund (Kenni) - Friday, 23 January 2009, 18:15 GMT
I also get DHCP timeouts on my bridge after upgrading.
echo "timeout 60" >> /etc/dhcpcd.conf
solved the issue.
Comment by Jonathan Liu (net147) - Saturday, 24 January 2009, 00:28 GMT
DHCP when using a bridge takes longer than it did previously. Booting up with DHCP using a bridge used to be fast but now it is slow, hence the need to increase the timeout. I preferred to reduce the forwarding delay instead of increasing the DHCP timeout so that bootup is still fast like it used to be.
Comment by Greg (dolby) - Monday, 02 February 2009, 01:43 GMT
 FS#10616  should similar if not the same.
As well as  FS#9239 
Comment by Ronald van Haren (pressh) - Thursday, 07 May 2009, 07:57 GMT
Roy said this in another bug report about dhcpcd5. If I understand correctly this bug should be fixed with the dhcpcd5 releases I will upload shortly.
Please someone test it and report.

1) default dhcpcd timeout is shorter than default bridge learning time
dhcpcd-5 is now a full daemon that handles DHCP for all interfaces instead of one instance per interface.
This effectively removes any timeout. There's still a timeout -> IPv4LL, but 60 seconds later DHCP is attempted again. Eventually it will come up on slow bridges.
Comment by Tobias Powalowski (tpowa) - Saturday, 09 May 2009, 11:04 GMT
status on dhcdp5?
Comment by Kenni Lund (Kenni) - Saturday, 09 May 2009, 19:51 GMT
Yep, I can confirm that dhcpcd5 fixes the issue.

--
1st reboot before upgrade
--
br0: dhcpcd 4.0.12 starting
br0: broadcasting for a lease
br0: offered 10.10.10.60 from 10.10.10.1
br0: acknowledged 10.10.10.60 from 10.10.10.1
br0: checking 10.10.10.60 is available on attached networks
br0: timed out

--
2nd reboot before upgrade
--
br0: dhcpcd 4.0.12 starting
br0: broadcasting for a lease
br0: offered 10.10.10.60 from 10.10.10.1
br0: acknowledged 10.10.10.60 from 10.10.10.1
br0: checking 10.10.10.60 is available on attached networks
br0: timed out

--
1st reboot after upgrade (old conf file)
--
dhcpcd: version 5.0.1 starting
dhcpcd: br0: rebinding lease of 10.10.10.60
dhcpcd: br0: broadcasting for a lease
dhcpcd: br0: offered 10.10.10.60 from 10.10.10.1
dhcpcd: br0: acknowledged 10.10.10.60 from 10.10.10.1
dhcpcd: br0: checking for 10.10.10.60
dhcpcd: br0: leased 10.10.10.60 for 86400 seconds
dhcpcd: forking to background

--
2nd reboot after upgrade (with clean dhcpcd5 config file; mv /etc/dhcpcd.conf{.pacnew,})
--
dhcpcd: version 5.0.1 starting
dhcpcd: br0: rebinding lease of 10.10.10.60
dhcpcd: br0: broadcasting for a lease
dhcpcd: br0: offered 10.10.10.60 from 10.10.10.1
dhcpcd: br0: acknowledged 10.10.10.60 from 10.10.10.1
dhcpcd: br0: checking for 10.10.10.60
dhcpcd: br0: leased 10.10.10.60 for 86400 seconds
dhcpcd: forking to background

Loading...