| Summary: | network-center configures connections with an incorrect wireless type | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | w unruh <unruh> |
| Component: | RPM Packages | Assignee: | Olivier Blin <mageia> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | critical | ||
| Priority: | High | CC: | krefson, oktain, raphgro |
| Version: | 2 | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | drakx-net | CVE: | |
| Status comment: | |||
|
Description
w unruh
2012-05-23 01:47:43 CEST
Manuel Hiebel
2012-05-24 23:02:46 CEST
Assignee:
bugsquad =>
mageia Installing drakx-net, drakx-net-text, libdrakx-net from Mandriva 2010.1 (drakx-net version .90) gives me a working system. The configuration suggestions are correct, what I enter into the configuration sticks (ie is writtten to wpa_supplicant.conf without it being wrongly rewritten when the Network Center begins to make the connection) and icons come up properly on the approriate lines ( the green circular arrow when the association with the appropriate AP is make and the blue rectangle with the green checkmark-- the mandriva symbol for a connection-- comes up. As far as I can see, the Panel network applet does not come up properly, but it is far more important to be able to connect than it is to see in that icon that one is connected. Ie, mageia needs to go back to the Mandriva drakx-net and figure out what has been destroyed along the way to version 0.97 or later. This also indicates that this is not a problem with the wireless driver, since drakx 0.90 is able to extract the correct information from the driver. Oops, that was drakx-net 1.12 in Mageia 2 not .97 which was in Mageia 1 But the damage seems to have happened by Mageia 1. More information. The problem seems to be most severe if the Network Center is automatically opened (eg by having it saved on your kde desktop when you close down so it opens automatically when you log in again.) If you close it and then reopen it, or if you open it after your desktop is up, it seems to be much better behaved (very limited testing). Ie, there seems to be something wrong with its state in the case it is automatically opened. If for example you manage to connect, (with nothing or the wrong stuff displayed) close it and reopen, the connection is properly displayed. This really is a crucial bug, since for example for laptop use, wireless is probably the most used thing on the computer. On further testing: a)Re the no reporting the status of the connection within network center-- it seems that for some reason Network Center is not getting the report back that the connection has been made, and is not refreshing itself after it has tried to make the connection. If one hits the refresh button, it then uses mandi to query the network connection and comes back and reports (with the icon on the left side, and with the "Disconnect" button on the bottom of the network display). The net_applet on the other hand does appear to get the information and does report correctly b) on the other issue of the encryption type, it sometimes, not always, reports the correct type in the Encryption column via the little lock icon, but the flags and the signal strength do not get properly reported (0% signal strength and no encryption flags reported.) No wonder it tries to change the congigured encryption type. The problem seems to be either from the reports from iwlist or wpa_cli. It is not at all clear why the wpa_cli is in there, since it will only work if wpa_supplicant is already running, which of course is almost never true unless a connection is already made. It is hard to duplicate the problem since it happens sporadically, but it definitely happens. OK, more information. I put some printout lines into /usr/lib/libDrakx/network/monitor.pm to see which of the three monitoring vehicles was used and when (mandi, wpa_cli, iwlist) I just got bad reports from network center (ie, the authentication type was wrong for the essid) on opening network center. It did not try mandi It tried wpa_cli but since wpa_supplicant was not running it of course failed. It then tried iwlist, and apparently misinterpreted the report that one of my essid was WEP, when actually it is WPA-EAP. This would then lead to network center insisting on configuring to eitehr use WEP or NONE as the authentication, which is wrong. When I hit Refresh, it again dropped through to iwlist, and this time reported the correct authentications. After I connected to one of the SSID (ubcsecure which uses WPA-EAP) and hit refresh, it now used mandi to find the information ( and only reported that the the one essid was present, not the 10 that are actually there) It is clear that the network center is requesting new infomation, or is not being reported to that things have changed. I see very similar behaviour. The Mga2 network stuff is misbehaving terribly, starting multiple wpa_supplicant processes (I have seen up to five) and misremembering an SSID entry as WEP instead of WPA2 (PSK). CC:
(none) =>
krefson Keith: the multiple wpa_supplicant processes is a NetworkManager bug, tracked as bug 3344
Olivier Blin
2012-06-10 16:03:12 CEST
Summary:
network-center is completely messed up =>
network-center configures connections with an incorrect wireless type
Olivier Blin
2012-06-10 16:03:22 CEST
Priority:
Normal =>
High Oliver: No, it's not just a NetworkManager bug. I uninstalled NetworkManager precisely because it was conflicting with the draknet management. $ rpm -qa | grep -i networkmanager lib64proxy-networkmanager-0.4.7-6.mga2 and I still get multiple wpa_supplicant processes. This is a machine that was upgraded from mga1 to beta 3 and then to mga2, in case that makes a difference. lspcidrake | grep iwl iwlwifi : Intel Corporation|Ultimate N WiFi Link 5300 [NETWORK_OTHER] Keith: ok, then please open another bug report about this "multiple wpa_supplicant" issue, with the ouput of "ps axf" when you see this happening. I can reproduce "misremembering an SSID entry as WEP instead of WPA2 (PSK)" from comment #6. My work around is the following process to be able to recreate a new and fresh configuration for the connection and get it working again with automatically detected WPA2: 1) Shut down the NetApplet (no icon in the system tray).2 2) rm -f /etc/sysconfig/network-scripts/wireless.d/SSID (replace SSID with either * or your dedicated SSID) 3) rm /etc/sysconfig/network-scripts/ifcfg-wlan0 4) Start NetApplet again and configure the connection as new. The thing about multiple processes can't be confirmed from my side. CC:
(none) =>
raphgro Oh well, I am using Cauldron. Maybe I should mention that. Forgotten another thing: You have also to remove the settings from /etc/wpa_supplicant.conf to let it be written again. Otherwise, those existing settings will be detected as WEP. So I guess that Network Center is not able to read /etc/wpa_supplicant.conf but only writes it initially for newly detected Wifi connections being available. Settings seem to be read and written from the network scripts, see comment #10 for the pathes. Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D I could detect the following. If draknetcenter asks to check the connection settings, I click on Cancel. Afterwards, I can click on Connect and it works magically. Confirmed, the component is buggy, ready to supply information all about it. CC:
(none) =>
oktain This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad Status:
NEW =>
RESOLVED |