Summary: | sys-apps/openrc-0.11.1: [oldnet] some interfaces inaccurately handle carrier detection | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Juergen Rose <rose> |
Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aidanamarks, gentoo, heltem+gentoo, iivanich, kfm, mattsch, mrbscreen, taviscaron, tsabi-gentoo, xuefer |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=439038 | ||
Whiteboard: | openrc:oldnet | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 439098 | ||
Attachments: | no-cd.patch |
Description
Juergen Rose
2012-10-19 18:31:54 UTC
The problems seems to occur at all my computers, which are configured to work with a bridged network interface. I see the following boot messages: ... * Starting D-BUS system messagebus ... * Bringing up interface eth0 * Waiting for carrier (5 seconds) .. [ ok ] * Waiting for IPv6 addresses ... [ ok ] * Bringing up interface vbox0 * Creating Tun/Tap interface vbox0 ... [ ok ] * Waiting for carrier (5 seconds) ..... [ !! ] * no carrier * ERROR: net.vbox0 failed to start * ERROR: cannot start net.br0 as net.vbox0 would not start * ERROR: cannot start ntp-client as net.vbox0 would not start * Starting rpcbind ... [ ok ] ... * Starting automounter ... [ ok ] * ERROR: cannot start netmount as net.vbox0 would not start ... If I later try to start /etc/init.d/net.vbox I get the message from the last posting (octl(TUNSETIFF): Device or resource busy). A lot of network services autofs, netmount etc does not start. The only workaround I found so far is to switch to a nonbridged network interface. Adding carrier_timeout_vbox0="0" in /etc/conf.d/net seems to help. *** Bug 439038 has been marked as a duplicate of this bug. *** I have changed the script so that 0 is the default setting for carrier_timeout_iface. this is in commit 8d17c63. (In reply to comment #4) > I have changed the script so that 0 is the default setting for > carrier_timeout_iface. this is in commit 8d17c63. Ok, this isn't right either. I updated my laptop per my usual dogfooding, and then networking failed to come up again. My wireless card needs at LEAST carrier_timeout_wlan0="4" to work. Created attachment 327226 [details, diff]
no-cd.patch
@robbat2:
This patch would take carrier detection back to the way it was in
0.10.x. If you apply it do things work again?
(In reply to comment #6) > Created attachment 327226 [details, diff] [details, diff] > no-cd.patch > > @robbat2: > This patch would take carrier detection back to the way it was in > 0.10.x. If you apply it do things work again? patch doesn't works for me, I still get this: dhcpcd[9306]: version 5.2.12 starting dhcpcd[9306]: tap0: broadcasting for a lease dhcpcd[9306]: tap0: carrier lost dhcpcd[9306]: timed out dhcpcd[9306]: allowing 8 seconds for IPv4LL timeout dhcpcd[9306]: timed out here is my config: config_eth0="null" bridge_br0="eth0 tap0 tap1 tap2" brctl_br0="setfd 0 sethello 0 stp on" rc_net_br0_need="net.eth0 net.tap1 net.tap0 net.tap2" config_tap0="dhcp" tuntap_tap0="tap" tunctl_tap0="-g virt_users" mac_tap0="0A:F8:1E:71:23:90" config_tap1="dhcp" tuntap_tap1="tap" mac_tap1="0A:F8:1E:71:23:91" config_tap2="dhcp" tuntap_tap2="tap" tunctl_tap2="-u mythtv" mac_tap2="0A:F8:1E:71:23:92" (In reply to comment #7) > (In reply to comment #6) > > Created attachment 327226 [details, diff] [details, diff] [details, diff] > > no-cd.patch > > > > @robbat2: > > This patch would take carrier detection back to the way it was in > > 0.10.x. If you apply it do things work again? > > patch doesn't works for me, I still get this: > dhcpcd[9306]: version 5.2.12 starting > dhcpcd[9306]: tap0: broadcasting for a lease > dhcpcd[9306]: tap0: carrier lost > dhcpcd[9306]: timed out > dhcpcd[9306]: allowing 8 seconds for IPv4LL timeout > dhcpcd[9306]: timed out > > here is my config: > config_eth0="null" > > bridge_br0="eth0 tap0 tap1 tap2" > brctl_br0="setfd 0 > sethello 0 > stp on" > rc_net_br0_need="net.eth0 net.tap1 net.tap0 net.tap2" > > config_tap0="dhcp" > tuntap_tap0="tap" > tunctl_tap0="-g virt_users" > mac_tap0="0A:F8:1E:71:23:90" > > config_tap1="dhcp" > tuntap_tap1="tap" > mac_tap1="0A:F8:1E:71:23:91" > > config_tap2="dhcp" > tuntap_tap2="tap" > tunctl_tap2="-u mythtv" > mac_tap2="0A:F8:1E:71:23:92" The first thing I suggest is upgrading your dhcpcd to the latest. Then, if you still have this issue, please open another bug since this is not the same issue we are discussing on this bug. In the future, please read the bug before you post and say you are having the same issue. Thanks, William I have the same error, tap interface didn't started after upgrade of openrc. As suggested writing the carrier_timeout line solved: config_tap0="192.168.10.1 netmask 255.255.255.0" tuntap_tap0="tap" tunctl_tap0="-u virtppp" mac_tap0="52:54:00:12:34:57" carrier_timeout_tap0="0" *** Bug 439596 has been marked as a duplicate of this bug. *** as reporter of bug #439596 that is merged to this, i'd ask if this bug is confirmed yet. what else info needed to reproduce it in dev side? ran into this (ioctl(TUNSETIFF): Device or resource busy) on two boxes with bridging. both broke with openrc 0.11.x. Tried the carrier_timeout_tap0="0" or "5" and restarting the tap interface but didn't work on the first machine I tried. Had to revert to 0.10.5 to get back up and running. My tap interfaces weren't coming up either with openrc-0.11.2 until I added the timeout 0 line: tuntap_tap0="tap" config_tap0="192.168.100.1/24" tunctl_tap0="-u mschultz" carrier_timeout_tap0="0" Just to note, I don't use bridging since it's unnecessary for running vms. So is the carrier_timeout_tapX line required now to bring up tap interfaces or is this really a bug? The default in openrc-0.11.4 is to not wait for a carrier unless you set carrier_timeout_$IFACE to some value, so this should no longer be an issue. (In reply to comment #14) > The default in openrc-0.11.4 is to not wait for a carrier unless you set > carrier_timeout_$IFACE to some value, so this should no longer be an > issue. Tap interfaces can come up now without carrier_timeout_$IFACE in openrc-0.11.4. Thanks for the fix William. |