Restarting the connection from drakroam or draknetcenter result in a non-working setup if NetworkManager is enabled. The issue occurs at the moment the drakx-net tools overwrite the ifcfg file. It seems NM detects that the ifcfg file is deleted, then puts the interface in MANAGED mode and starts its own wpa_supplicant. After a very short time, it detects that the ifcfg file is written back, puts the interface in UNMANAGED mode, but it seems it does not kill its wpa_supplicant. Then conflicts occur between the two wpa_supplicant instances (one from drakx-net/initscripts, one from NM that should not be managing wlan0).
CC: (none) => tmbAssignee: bugsquad => mageia
CC: (none) => ftg
OK on whiteboard, cause assignee assigned to himself
CC: (none) => marja11Whiteboard: (none) => OK
Bug confirmed, sadly.
CC: (none) => oktain
Ping ?
*** Bug 5583 has been marked as a duplicate of this bug. ***
CC: (none) => theamazingchiepoo
Blocks: (none) => 1712
Blocks: (none) => 7557
Please refer to the discussion in bug#7873 and bug#2160 and see if your problems with NM go away if you either allow GNOME (if you have it installed) to activate it or you install plasma-network-management under KDE, add it to your panel, and use it to configure your SSID. For NM to handle wireless correctly, it needs to create SSID-specific files of its own by parsing the ifcfg files produced by drakconnect. GNOME's nm-applet does this automatically, since it has no option to *not* use NM, but since NM isn't the default yet for other desktops, it doesn't happen automatically there. You'll need to install NM and let it start, and recreate your wireless interface with drakconnect specifying "Allow NM to control this interface". Please test and post your results, as whether NM works for all the chips involved when it's properly configured will have a significant impact on how it needs to be handled for non-GNOME desktops in MGA3.
(In reply to comment #5) n/a here
(In reply to Frank Griffin from comment #5) > Please refer to the discussion in bug#7873 and bug#2160 and see if your > problems with NM go away if you either allow GNOME (if you have it > installed) to activate it or you install plasma-network-management under > KDE, add it to your panel, and use it to configure your SSID. > > For NM to handle wireless correctly, it needs to create SSID-specific files > of its own by parsing the ifcfg files produced by drakconnect. GNOME's > nm-applet does this automatically, since it has no option to *not* use NM, > but since NM isn't the default yet for other desktops, it doesn't happen > automatically there. > > You'll need to install NM and let it start, and recreate your wireless > interface with drakconnect specifying "Allow NM to control this interface". > > Please test and post your results, as whether NM works for all the chips > involved when it's properly configured will have a significant impact on how > it needs to be handled for non-GNOME desktops in MGA3. Testing Gnome 3 and OpenBox. No joy with Broadcom b43xx while using either closed or open firmware. Same outcome with ASUS N150 and Linksys WUSB600N v1. I'm learning to give up on any Mandriva based distro with wireless as it's just hopelessly broken. This same bug cripples PCLinux OS as well. What's weird is that Drakx-Net sees two instances of each wireless adapter, one of which permanently tied to proprietary drivers even if none are installed. (Example Broadcom 43xx has one instance listed for the wl drivers that are not present and the b43-openfwwf currently installed) Out of desperation, I removed all traces of Drake Tools to see if it was the culprit but the connection with NM alone was still terrible, holding for one minute at best during any given time. Perhaps there's just no compatibility? I've done all the testing I can for now. I need a productivity machine at the moment so I can't do any more follow-ups but figured I'd give you my status before leaving. Thanks and good luck
Hi Olivier, what is the status on that bug? Thanks!
CC: (none) => pierre-malo.denielou
I wold like to say that after M2 to M3 upgrade, nm-applet is started by default, (thou in M2 only net_applet was started), so a curious user will enable NetworkManager, just to find that it will not be able to use it on a non-gnome/non-kde desktop (LXDE in my case). "Failed to add/activate connection: (32) Insufficient privileges" is the error and the trouble seems to be that the networkmanager rpm does not check if a polkit wrapper (lmpolkit here) is installed. Maybe post install message stating something like "Make sure to have installed a polkit wrapper before using NM" will give some directions to the user?
CC: (none) => muie1121
@ Sorin: Thank you for reporting. Please post a separate bug on that.
CC: (none) => fri
*** Bug 5250 has been marked as a duplicate of this bug. ***
CC: (none) => farfouille64
*** Bug 10727 has been marked as a duplicate of this bug. ***
CC: (none) => desmond.armstrong
CC: (none) => olav
*** Bug 7676 has been marked as a duplicate of this bug. ***
CC: (none) => eeeemail
CC: (none) => mageia
This problem is, to me, not unrelated to my reports. (bug 5418). My solution was, and is, to uninstall 'networkmanager' leaving ifplugd in position. I had lots of discussion at that time and certainly uninstalling 'networkmanager' has been a reliable solution to this conflict issue. For me as I know to uninstall 'networkmanager' all is well but, this is little help to a new user and I shall report again when I have had chance to try the beta1 of Mageia 4.
The "uninstall networkmanager" option is really not a solution. The two systems should co-exist fine - e.g. you may want initscripts to handle your wired connection but want NM to handle your wifi. This should be quite possible and supported. We need to make this work in this scenario.
Based on Olivier's original description, the fix seems simple: leave the original ifcfg file there, write the new one to a different name, and then use mv -f to replace the original atomically. Obviously the real fix would be to have NM realize that its wpa is no longer needed, but given the present state of NM, how long will the drakx tools be running in parallel with NM as opposed to being simply an NM wrapper ?
(In reply to Frank Griffin from comment #16) > Obviously the real fix would be to have NM realize that its wpa is no longer > needed, but given the present state of NM, how long will the drakx tools be > running in parallel with NM as opposed to being simply an NM wrapper ? Medium to long term, the likely scenario will be to use a different component for low-level, non-desktop stuff. The people from CoreOS are developing something in partnership with systemd and connman folks to create a proper tool for managing networks without the drawbacks of the flimsy, held-together with sticky tape setup that initscripts currently has. Shelling out to tools with complex state machines just doesn't work and is so full of races that it's not funny. For large scale deployments, getting robust and fast networking support in the initrd is also highly desirable and thus a definitive tool should be friendly to that and have a low footprint. So ultimately, the low level stuff (and thus the drakx tools) will likely become a nice wrapper around this low level state (which should have nice dbus interfaces for working with it properly), but it should also deal nicely with NM and query NM for state etc. too for those interfaces managed there. I look forward to the day when ifplugd can disappear (even Lennart who wrote the tool in the first place is looking forward to that day too!) This is all some time away tho'.
I am sure that Lennart will understand what is going on here but for me there is no disadvantage in uninstalling 'networkmanager' as ifplugd does indeed provide the Wi-Fi connections and the wired connections without any problems. Every time I install a machine with Wi-Fi then I simply have to remember to uninstall networkmanager, this way I am getting total reliability with the connections.
In reply to what Andrew Paradiso 2013-02-26 10:40:55 CET said (in Comment 7): > What's weird is that Drakx-Net sees two instances of each wireless adapter, > one of which permanently tied to proprietary drivers even if none are > installed. (Example Broadcom 43xx has one instance listed for the wl drivers > that are not present and the b43-openfwwf currently installed) I have just installed 32-bit Mageia4-Beta2 (KEDIT) on a Samsung NC110 netbook with Broadcom BCM43225 WiFi. (drakx-net-2.7.1.mga4.src.rpm 28/12/13) Happily, the WiFi works beautifully, but Network Centre exhibits the same duplication of 'WiFi' panels reported by Andrew: The 1st WiFi panel (showing a red 'fan') is a dud - no SSID's shown, and if selected the message: "Broadcom Corporation BCM43225 802.l/b/g/n Unable to find network interface for selected device. (Using bcma driver)" appears. The 2nd WiFi panel (showing a green 'fan') is the genuine one (labelled "wl1s0" instead of the familiar "WLAN"), showing local SSID's, allowing connection to be achieved. (I'm not aware of using the Gnome NetworkManager (which I did try last year, but abandoned as it was being handled at user level instead of system level; otherwise I rather liked it, and would have otherwise settled on it for my use.) ) This duplication is going to confuse newcomers to Mageia and needs sorting out. For myself, I'm just happy that the Broadcom WiFi works well!
CC: (none) => maurice
(In reply to Maurice Batey from comment #19) > (I'm not aware of using the Gnome NetworkManager (which I did try last year, > but abandoned as it was being handled at user level instead of system level; > otherwise I rather liked it, and would have otherwise settled on it for my > use.) ) I wouldn't say it's Gnome NetworkManager. And you can configure it to be system level. You just have to tick the checkbox that makes connection a system level connection.
Certainly, on all the installations of Mageia3 which I do, I then uninstall 'networkmanager' and then things do work reliably. I do want to see this issue resolved before Mageia4 is released as this problem will discourage new users.
Networkmanager does not appear to be installed here. Have raised Bug 12197 for the duplicate WiFi panel glitch.
commit 360f3b5937e1fb1ff173240ec5c3ee9f8e9f9491 Author: Colin Guthrie <colin@...> Date: Fri Jan 24 09:57:13 2014 +0000 ifcfg: Do not write the NM_CONTROLLED flag unless we know it's value. If it's not read from the config, it will be read as undef, but written back as 'no'. This changes the behaviour where no setting means 'automatic' - i.e. if NM is installed, use it, otherwise don't. If the user wants to be specific, then they make the consious choice to tick the box in drakx-net. mga#6675 mga#9261 --- Commit Link: http://gitweb.mageia.org/software/drakx-net/commit/?id=360f3b5937e1fb1ff173240ec5c3ee9f8e9f9491 Bug links: Mageia https://bugs.mageia.org/show_bug.cgi?id=6675 https://bugs.mageia.org/show_bug.cgi?id=9261
Please, please, please can the whole issue of WiFi not connecting be addressed? I first reported these types of issue with Mandriva 2007 and it hasn't got any better since. I am now faced with non working WiFi again because I connected my laptop to a different network and, when trying to connect back to my original network, it all fails. The first indication is that drakconnect has "forgotten" about my original network and instead presents me with two SSIDs which are strings of escaped hex digits. I knew then that it had all gone pear shaped, but I tried to reconfigure my network anyway and of course it didn't work. After three or four attempts it briefly showed my network but was showing the ancient issue where the security setting always goes back to WEP. And then of course there's which tool to use?! drakconf, drakconnect, drakroam, Network Center, Wireless connection, uncle tom cobbly and all. With Mageia 1 I had to switch to Ubuntu and it looks like I'm going to have to again. I don't really like Ubuntu but one thing they seem to have absolutely nailed is WiFi.
CC: (none) => osavill
Update - I removed the line alias wlan0 b43 from /etc/modprobe.conf , since my network card is not a Broadcom device! rebooted and now the system has successfully connected to "\x00\x00\x00\x00\x00\x00\x00". A bit of an odd name but at least it's connecting again. Presumably the other hex number is the WiFi hotspot I connected to!
Watching theser topics... It is preventing me form installing Mageia 4. Me too reported this kind of network problems on both Mageia 3 and 4. I needs to be resolved. If an end user does not at least have a working network connection right form an install, he cannot even google for solutions for problems so IMO a OS cannot be realesed with such a problem.
CC: (none) => uyskoos
This bug is tagged as releas blocker. What shall we do with this one?
CC: (none) => ennael1
I'll try and take a look.
Resetting assignee since Olivier doesn't seem to be looking at it.
CC: (none) => remiAssignee: mageia => bugsquad
CC: (none) => anaselli
Finally fixed. may be reopened if needed
Status: NEW => RESOLVEDResolution: (none) => FIXED