Bug 8971 - draknet tries to activate wifi interface with NM active and no NM_CONTROLLED in ifcfg
Summary: draknet tries to activate wifi interface with NM active and no NM_CONTROLLED ...
Status: RESOLVED DUPLICATE of bug 7317
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 7557
  Show dependency treegraph
 
Reported: 2013-02-05 17:33 CET by Frank Griffin
Modified: 2013-05-11 14:50 CEST (History)
2 users (show)

See Also:
Source RPM: initscripts
CVE:
Status comment:


Attachments

Description Frank Griffin 2013-02-05 17:33:20 CET
I have a laptop with a fresh cauldron install.  I have never used drakconnect to create a wifi interface, but instead run NetworkManager without ifcfg-rh and used the plasma-applet-networkmanager to activate the interface (wlan0).

During startup, presumably in the "network" service, the journalctl log shows something trying to activate wlan0 using ifplugd.  Upon investigation, this appears to be due to udev creating an ifcfg-wlan0 containing:

DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

However, Colin says that network shouldn't be trying to start wlan0:

(from bug#6541)
******************************************************
Also the network scripts should assume that if there is no NM_CONTROLLED
variable present, that it should assume NM *is* controlling it (i.e. see the
code: "! is_false $NM_CONTROLLED && is_nm_running && _use_nm=true" in both
network-up and network-functions in initscripts package
******************************************************

The sequence can be seen in journalctl:

********************************************************
Feb 05 07:41:56 ftglap NetworkManager[3223]: <info> Policy set 'NETGEAR55' (wlan0) as default for IPv4 routing and DNS.
Feb 05 07:41:56 ftglap NetworkManager[3223]: <info> Activation (wlan0) successful, device activated.
Feb 05 07:41:56 ftglap NetworkManager[3223]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) complete.

(NM has just finished bringing wlan0 up)

Feb 05 07:41:56 ftglap network[3345]: Bringing up loopback interface:  127.0.0.1
Feb 05 07:41:57 ftglap network[3345]: squid.service - LSB: Starts the squid daemon
Feb 05 07:41:57 ftglap network[3345]: Loaded: loaded (/etc/rc.d/init.d/squid)
Feb 05 07:41:57 ftglap network[3345]: Active: inactive (dead)
Feb 05 07:41:57 ftglap network[3345]: CGroup: name=systemd:/system/squid.service
Feb 05 07:41:57 ftglap network[3345]: squid: ERROR: No running copy
Feb 05 07:41:57 ftglap network[3345]: [  OK  ]
Feb 05 07:41:57 ftglap network[3345]: Configuring wireless regulatory domain  [  OK  ]
Feb 05 07:41:57 ftglap ifplugd(eth0)[3734]: ifplugd 0.28 initializing.
Feb 05 07:41:57 ftglap ifplugd(eth0)[3734]: Using interface eth0/30:85:A9:08:FA:BB with driver <atl1c> (version: 1.0.1.0-NAPI)
Feb 05 07:41:57 ftglap ifplugd(eth0)[3734]: Using detection mode: SIOCETHTOOL
Feb 05 07:41:57 ftglap ifplugd(eth0)[3734]: Initialization complete, link beat not detected.
Feb 05 07:41:57 ftglap network[3345]: Bringing up interface eth0:  [  OK  ]
Feb 05 07:41:57 ftglap kernel: wlan0: deauthenticating from 84:1b:5e:44:cf:f2 by local choice (reason=3)
Feb 05 07:41:57 ftglap kernel: cfg80211: Calling CRDA to update world regulatory domain
Feb 05 07:41:57 ftglap systemd-udevd[3784]: failed to execute '/usr/sbincrda' '/usr/sbincrda': No such file or directory
Feb 05 07:41:57 ftglap ifplugd(wlan0)[3785]: ifplugd 0.28 initializing.
Feb 05 07:41:57 ftglap ifplugd(wlan0)[3785]: Using interface wlan0/78:92:9C:99:62:2A with driver <iwlwifi> (version: 3.8.0-desktop-0.rc5.1.mga3)
Feb 05 07:41:57 ftglap ifplugd(wlan0)[3785]: Using detection mode: SIOCETHTOOL
Feb 05 07:41:57 ftglap ifplugd(wlan0)[3785]: Initialization complete, link beat not detected.
Feb 05 07:41:57 ftglap NetworkManager[3223]: <info> (wlan0): supplicant interface state: completed -> disconnected
Feb 05 07:41:57 ftglap network[3345]: Bringing up interface wlan0:  [  OK  ]
Feb 05 07:41:58 ftglap systemd[1]: Started LSB: Bring up/down networking.
Feb 05 07:41:58 ftglap systemd[1]: Starting LSB: Wait for the hotplugged network to be up...
Feb 05 07:41:58 ftglap NetworkManager[3223]: <info> (wlan0): supplicant interface state: disconnected -> scanning
eb 05 07:41:58 ftglap kernel: wlan0: authenticate with 84:1b:5e:44:cf:f2
Feb 05 07:41:58 ftglap kernel: wlan0: send auth to 84:1b:5e:44:cf:f2 (try 1/3)
Feb 05 07:41:58 ftglap NetworkManager[3223]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Feb 05 07:41:58 ftglap kernel: wlan0: authenticated
Feb 05 07:41:58 ftglap kernel: wlan0: associate with 84:1b:5e:44:cf:f2 (try 1/3)
Feb 05 07:41:58 ftglap kernel: wlan0: RX AssocResp from 84:1b:5e:44:cf:f2 (capab=0x401 status=0 aid=2)
Feb 05 07:41:58 ftglap NetworkManager[3223]: <info> (wlan0): supplicant interface state: authenticating -> associating
Feb 05 07:41:58 ftglap kernel: wlan0: associated
Feb 05 07:41:58 ftglap NetworkManager[3223]: <info> (wlan0): supplicant interface state: associating -> completed
Feb 05 07:41:58 ftglap ifplugd(wlan0)[3785]: Link beat detected.
Feb 05 07:41:59 ftglap ifplugd(wlan0)[3785]: Executing '/etc/ifplugd/ifplugd.action wlan0 up'.
*************************************************************

Since drakconnect normally creates an ifcfg with NM_CONTROLLED=NO if you don't check the box to let NM control the interface, I'm wondering if the fact that udev is not adding NM_CONTROLLED is causing network to default to assuming NM_CONTROLLED=NO.

In any case, this is bad berries.  udev can't know whether NM is controlling the device or not.  If it blindly adds NM_CONTROLLED=YES and NM *isn't* being used, the user is screwed.  If it blindly adds NM_CONTROLLED=NO and NM *is* being used, the user is only partially screwed for the time that NM and ifplugd are butting heads as above.

Ideally, udev should check whatever NM uses to define the interfaces it controls, and behave accordingly.
Frank Griffin 2013-02-05 17:34:01 CET

CC: (none) => mageia

Comment 1 Colin Guthrie 2013-02-05 17:37:20 CET
Do you know if it's actively draknet doing this rather than the network scripts in the initscripts package? It's nice to know where to start looking :)
Comment 2 Frank Griffin 2013-02-05 17:46:19 CET
Sorry, I've seen so many names for the MGA network support that I get confused.  I would assume the network scripts, since that appears to be what's running in journalctl.
Comment 3 Colin Guthrie 2013-02-05 18:02:49 CET
No worries - it's *very* hard to keep track of everything!

Assignee: bugsquad => mageia
Source RPM: drakxtools => initscripts

Comment 4 Frank Griffin 2013-02-05 18:11:05 CET
Poking around a bit, it seems that all the network scripts (or ifup, or whatever) has to do is look in /etc/NetworkManager/system-connections for a match on the SSID, and back off if it finds one.

Probably not worth worrying about non-system connections, since NM won't be trying to activate them until long after network ends.
Manuel Hiebel 2013-02-10 13:53:57 CET

CC: (none) => mageia
Blocks: (none) => 7557

Comment 5 Olivier Blin 2013-05-11 14:50:20 CEST
Duplicate of bug 7317

*** This bug has been marked as a duplicate of bug 7317 ***

Status: NEW => RESOLVED
Resolution: (none) => DUPLICATE


Note You need to log in before you can comment on or make changes to this bug.