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.
CC: (none) => mageia
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 :)
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.
No worries - it's *very* hard to keep track of everything!
Assignee: bugsquad => mageiaSource RPM: drakxtools => initscripts
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.
CC: (none) => mageiaBlocks: (none) => 7557
Duplicate of bug 7317 *** This bug has been marked as a duplicate of bug 7317 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE