[PATCH] new interface is already up but udev must call ifup anyway

[PATCH] new interface is already up but udev must call ifup anyway

[Stanislav Brabec]

Few weeks ago yet another change happened in the dark, and network did
not start to work automatically after inserting my WLAN card.

Debugging this problem, I found that interface is already up but not
configured when /etc/udev/scripts/network.sh is called. This script
thinks, that card is already configured and quits. This behavior is
intentional and was introduced three years ago (and working).

The fix actually reverts following change:
Author: Matthias Hentges <oe@hentges.net>
Date:   Thu Apr 20 16:01:09 2006 +0000
    udev: network.sh: Do not ifup an already configured network device again.

That is why I am asking:

Is anybody aware of change, that made new interfaces up without
configuring them? Was it an intention or not?

Matthias, do you remember, which problem it addressed?

My card is prism2 based wlan card. Firmware is upgraded into card RAM.

diff --git a/packages/udev/files/network.sh b/packages/udev/files/network.sh
index 182c26d..c97f9f0 100644
--- a/packages/udev/files/network.sh
+++ b/packages/udev/files/network.sh
@@ -47,7 +47,7 @@ fi
 if grep -q "iface \+$INTERFACE" /etc/network/interfaces; then
   case $ACTION in
     add)
-    	ifconfig | grep -q "^$INTERFACE" || ifup $INTERFACE
+    	ifup $INTERFACE
     	;;
     remove)
     	ifdown $INTERFACE


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [PATCH] new interface is already up but udev must call ifup anyway

[Nicola Mfb]

2009/3/6 Stanislav Brabec <utx@penguin.cz>

> Few weeks ago yet another change happened in the dark, and network did
> not start to work automatically after inserting my WLAN card.
>
> Debugging this problem, I found that interface is already up but not
> configured when /etc/udev/scripts/network.sh is called. This script
> thinks, that card is already configured and quits. This behavior is
> intentional and was introduced three years ago (and working).
>
> The fix actually reverts following change:
> Author: Matthias Hentges <oe@hentges.net>
> Date:   Thu Apr 20 16:01:09 2006 +0000
>    udev: network.sh: Do not ifup an already configured network device
> again.
>
> That is why I am asking:
>
> Is anybody aware of change, that made new interfaces up without
> configuring them? Was it an intention or not?
>

I had the same problem with bnep bluetooth networking, and another issue
when spawing dhcp, take a look at:
http://lists.openmoko.org/pipermail/devel/2009-February/004895.html

       Nicola

Re: [PATCH] new interface is already up but udev must call ifup anyway

[Stanislav Brabec]

Nicola Mfb wrote in Fri 03/06 2009 at 23:31 +0100: 
> 2009/3/6 Stanislav Brabec <utx@penguin.cz>
> 
> > Few weeks ago yet another change happened in the dark, and network did
> > not start to work automatically after inserting my WLAN card.
> >
> > Debugging this problem, I found that interface is already up but not
> > configured when /etc/udev/scripts/network.sh is called. This script
> > thinks, that card is already configured and quits. This behavior is
> > intentional and was introduced three years ago (and working).
> >
> > The fix actually reverts following change:
> > Author: Matthias Hentges <oe@hentges.net>
> > Date:   Thu Apr 20 16:01:09 2006 +0000
> >    udev: network.sh: Do not ifup an already configured network device
> > again.
> >
> > That is why I am asking:
> >
> > Is anybody aware of change, that made new interfaces up without
> > configuring them? Was it an intention or not?
> >
> 
> I had the same problem with bnep bluetooth networking, and another issue
> when spawing dhcp, take a look at:
> http://lists.openmoko.org/pipermail/devel/2009-February/004895.html

I researched this problem a bit. It seems, that it's caused by
wpa_supplicant. New wpa_supplicant quickly responds to the device
addition. It turns the device up and sets up the wireless link, but not
network.

It causes several problems:
- link is up -> no ifup

After applying mentioned patch:
- AP lookup takes about 20 seconds. Too much for dhcp client =>
  it fails. Surprisingly avahi succeeds.

Proposed solution:
Either:
wpa_wupplicant should perform (or trigger somehow) wlan network hotplug
completely (i. e. call ifup after network association instead of udev
device addition)
or:
Revert previous behavior - "passive" wpa_supplicant.
or:
Apply mentioned patch. Ugly, it fixes only symptom, not the cause.

________________________________________________________________________

Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [PATCH] new interface is already up but udev must call ifup anyway

[Koen Kooi]

On 20-04-09 11:33, Stanislav Brabec wrote:
> Nicola Mfb wrote in Fri 03/06 2009 at 23:31 +0100:
>> 2009/3/6 Stanislav Brabec<utx@penguin.cz>
>>
>>> Few weeks ago yet another change happened in the dark, and network did
>>> not start to work automatically after inserting my WLAN card.
>>>
>>> Debugging this problem, I found that interface is already up but not
>>> configured when /etc/udev/scripts/network.sh is called. This script
>>> thinks, that card is already configured and quits. This behavior is
>>> intentional and was introduced three years ago (and working).
>>>
>>> The fix actually reverts following change:
>>> Author: Matthias Hentges<oe@hentges.net>
>>> Date:   Thu Apr 20 16:01:09 2006 +0000
>>>     udev: network.sh: Do not ifup an already configured network device
>>> again.
>>>
>>> That is why I am asking:
>>>
>>> Is anybody aware of change, that made new interfaces up without
>>> configuring them? Was it an intention or not?
>>>
>>
>> I had the same problem with bnep bluetooth networking, and another issue
>> when spawing dhcp, take a look at:
>> http://lists.openmoko.org/pipermail/devel/2009-February/004895.html
>
> I researched this problem a bit. It seems, that it's caused by
> wpa_supplicant. New wpa_supplicant quickly responds to the device
> addition. It turns the device up and sets up the wireless link, but not
> network.
>
> It causes several problems:
> - link is up ->  no ifup
>
> After applying mentioned patch:
> - AP lookup takes about 20 seconds. Too much for dhcp client =>
>    it fails. Surprisingly avahi succeeds.
>
> Proposed solution:
> Either:
> wpa_wupplicant should perform (or trigger somehow) wlan network hotplug
> completely (i. e. call ifup after network association instead of udev
> device addition)
> or:
> Revert previous behavior - "passive" wpa_supplicant.
> or:
> Apply mentioned patch. Ugly, it fixes only symptom, not the cause.

With my distro hat on: shouldn't something like connman take care of 
wireless? Which would probably mean going back to a passive wpa_supplicant.

regards,

Koen

Re: [PATCH] new interface is already up but udev must call ifup anyway

[Stanislav Brabec]

Koen Kooi wrote:

> > Proposed solution:
> > Either:
> > wpa_wupplicant should perform (or trigger somehow) wlan network hotplug
> > completely (i. e. call ifup after network association instead of udev
> > device addition)
> > or:
> > Revert previous behavior - "passive" wpa_supplicant.
> > or:
> > Apply mentioned patch. Ugly, it fixes only symptom, not the cause.
> 
> With my distro hat on: shouldn't something like connman take care of 
> wireless? Which would probably mean going back to a passive wpa_supplicant.

Yes, at least on distro build conf level (but probably also on runtime
or package selection level) there should a way to select networking
concept:

- ifup/ifdown with /etc/network/interfaces, udev hotplugging and
  wpa_supplicant handling lost association

- connman handling everything

- NetworkManager handling everything

OT: I have no experience with connman. Does it have the same "one
network active at a time" constraint like NetworkManager has? And does
connman automatically handle "association lost" case for wireless?

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [PATCH] new interface is already up but udev must call ifup anyway

[Koen Kooi]

On 20-04-09 13:33, Stanislav Brabec wrote:
> Koen Kooi wrote:
>
>>> Proposed solution:
>>> Either:
>>> wpa_wupplicant should perform (or trigger somehow) wlan network hotplug
>>> completely (i. e. call ifup after network association instead of udev
>>> device addition)
>>> or:
>>> Revert previous behavior - "passive" wpa_supplicant.
>>> or:
>>> Apply mentioned patch. Ugly, it fixes only symptom, not the cause.
>>
>> With my distro hat on: shouldn't something like connman take care of
>> wireless? Which would probably mean going back to a passive wpa_supplicant.
>
> Yes, at least on distro build conf level (but probably also on runtime
> or package selection level) there should a way to select networking
> concept:
>
> - ifup/ifdown with /etc/network/interfaces, udev hotplugging and
>    wpa_supplicant handling lost association
>
> - connman handling everything
>
> - NetworkManager handling everything

There's a fourth option:

  - connman handling everything that isn't in /etc/network/interfaces, 
which is the option I like best :)

> OT: I have no experience with connman. Does it have the same "one
> network active at a time" constraint like NetworkManager has?

Nope :)

> And does connman automatically handle "association lost" case for wireless?

It does seem to do that for me with my wep network.

regards,

Koen