Network card fails to be raised

[Crispin Flowerday]

Since upgrading from Hoary to Breezy, my network card has not been raised on
bootup. I have had to manually work around this by adding an init script
"rcS.d/S42raise-network" with the single line "ifup eth0".

I have no idea what init script is supposed to raise the network, any pointers
about how to debug would be great!

I'll attach my lspci output, and the interfaces file (I have 2 network cards,
eth0 is mapped to the via rhine card)

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

Created an attachment (id=3301)
lspci output

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

Created an attachment (id=3302)
interfaces

[Matt Zimmerman (mdz)]

hotplug (0.0.20040329-22ubuntu6) breezy; urgency=low

  * Add a new /etc/hotplug/net.rc that cold-plugs any network devices
    that have already been installed.
  * Run net.rc during normal startup (in S40hotplug), the actual ifup parts
    will wait until after S41hotplug-net have been run. This saves some
    code duplication and isn't that less efficient.
  * Don't remove net.rc during upgrades.

 -- Scott James Remnant <email address hidden> Mon, 15 Aug 2005 19:09:57 +0100

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

This doesn't seem to work for me, I have hotplug 0.0.20040329-22ubuntu8 and my
network card is still not started on boot correctly.

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

More investigation shows a couple of problems:

- the main one is that net.agent reckons that both my network cards are mapped
to eth1. If I turn on debuging (DEBUG=1 in /etc/default/hotplug) then I see:

invoke ifrename for eth0
iface eth0 is remapped to eth1
invoke ifrename for eth1
iface eth1 is remapped to eth1

This obviously causes "ifup eth1=hotplug" to be invoked twice, while my network
card is actually eth0

my /etc/iftab contains:

eth0 mac 00:80:c8:e0:0c:a6
eth1 mac 00:50:8d:4c:40:30

I think the problem is that ifrename is invoked as:

ifrename -t -i eth0 (which maps eth0 to eth1)

and then as

ifrename -t -i eth1 (perhaps this picks up the newly mapped eth1 rather than the
eth1 that needs mapping to eth0)

- The other problem is that there is a huge race condition on bringing up the
interfaces. The net.rc script sleeps waiting for a file to be removed, but by
the time it has reacted, some other init scripts may have been called that
needed the network to be up.

[Thomas Hood (jdthood)]

(In reply to comment #5)
> there is a huge race condition on bringing up the
> interfaces. The net.rc script sleeps waiting for a file to be removed, but by
> the time it has reacted, some other init scripts may have been called that
> needed the network to be up.

It is instances of the _net.ifup_ script, started by net.agent, which sleep
waiting for a flag file (net.agent) to be _created_.

The reason for the wait loop is that the networking subsystem is initialized
by the carefully crafted sequence of boot scripts leading up to and
including S40networking; hotplug cannot bring up any interfaces before that;
however, net.agent can get run earlier in the boot sequence; so it has to
spawn children that wait.

There is no race between net.ifup and boot scripts. If there is a problem
with boot scripts then it is their failing to observe this rule: Services
must not make assumptions about when hot plugged network interfaces will
become available.

If one has a hot plugged network interface and there are things that should
happen when the interface is created then those things should be executed
by hotplug or udev hooks, not by boot scripts.

It looks as if there is a race between multiple instances of net.ifup.
This is only a race because ifrename is being used in a way that makes
it vulnerable; that is, it is used to assign names to interfaces that
lie in the namespace used by the kernel. The race is then:

   eth0 created... ...eth0 renamed to 'eth1' (fails)
                  eth1 created... ...eth1 renamed to
'eth0' (fails)

If a separate namespace is used then no race occurs:

   eth0 created... ...eth0 renamed to ethfoo (succeeds)
                  eth1 created... ...eth1 renamed to
'ethbar' (succeeds)

This bug has been marked as a duplicate of bug 7050.

[Thomas Hood (jdthood)]

> It looks as if there is a race between multiple instances of net.ifup.

I should have said "between multiple instances of net.agent". ifrename is
called from net.agent.

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

No, the race I am talking about is totally different (I got a few of the
technicalities slightly wrong before):

- The hotplug init script calls net.agent, and calls net.ifup
- net.ifup sleeps until a file is created
- While net.ifup is sleeping, another init script is started that needs networking
- net.ifup hasn't raised the network yet
- The init script that needs networking fails 'cause the network isn't up yet
- the interface is finally raised by net.ifup