Description of problem: You have a variety of wireless APs all of which have been selected in the past, so entries exist in wpa_supplicant.conf. You now choose one to connect to this time. wpa_supplicant will not honour your choice but makes its own choice based on some hidden criteria (signal strength, etc) The drakxnet tools use ifup-eth. This calls ifup-wireless which uses iwconfig to set parameters for the connection. Then, for wpa authentication APs wpa_supplicant is called. But wpa_supplicant ignores anything set by iwconfig and has its own heuristic for selecting which SSID to connect to. Thus you do not get the one you want. (The problem of having many SSIDs all visible at once is common in universities) I raised this with Jouni Malinen, the writer of wpa_supplicant who told me wpa_supplicant ignores all other settings and told me that the way to tell wpa_supplicant to connect to a specific SSID was to use wpa_sli **************************************************** http://w1.fi/bugz/show_bug.cgi?id=360 Jouni Malinen <j@w1.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME --- Comment #3 from Jouni Malinen <j@w1.fi> 2010-08-28 10:18:05 --- "wpa_cli select_network <network id>" asks wpa_supplicant to connect to a specific network in the configuration file. You do not need to edit the configuration file to do this. Another option is to use an external tool like NetworkManager or ConnMan to manage the networks (which is the approach selected by most Linux distributions). ****************************************************************** Version-Release number of selected component (if applicable): All Drakxnetwork versions and initscripts since at least 2010 (ie in Mandriva as well as Mageia) How reproducible: randomly if there are many possible SSIDS visible and listed in wpa_supplicant.conf. Steps to Reproduce: Have many SSIDs visible to the wireless card, many of which are listed in /etc/wpa_supplicant.conf ( eg because previous attempts have been made to connect to them). Choose one in Network Center, and ask to connect to it. It will randomly connect to a different ssid than the one selected (depends on signal strength and other criteria unkown to me. ) This is apparently wpa_supplicant working as designed. Reproducible: Steps to Reproduce:
blino, maybe something you could be interesting mga3 too
CC: (none) => mageia
While I certainly think this should be fixed-- it has caused me no end of frustration for example-- I suspect that the fix is going to more difficult. You have to start up wpa_supplicant, without it trying to connect to something. Then you need to run wpa_cli and tell it to pick a specific SSID, and finally tell wpa_supplicant to connect. wpa_cli is HORRIBLY documented (the man page, which seems to be the only documentation) only lists about 1/2 of the commands that wpa_cli actually honours, and the explanation is pretty terse. And I have tried to use wpa_cli to connect to a running wpa_supplicant, and have failed miserably-- and who knows why, the error messages are not very helpful. Now, blino may well know both programs a lot better than I do, and it may be easy for him, in which case I urge him to go for it. On the minus side, the number of people this affects is probably small and in the triage for what gets solved before MDV3 gets released it probably does not rank terribly high. But that should not mean it is neglected for another 6 years (the problem has been there for a long time in Mandriva before Mageia.)
Is it a duplicate to bug #6675 ?
Keywords: (none) => NEEDINFOCC: (none) => stormi
No. This bug exists even if Network Manager is not installed at all, never mind running. This bug exists because there is a apparently a misunderstanding of how wpa_suppolicant works. Draknetcenter tries to use the standard wireless tools to set up the connection, but wpa_supplicant ignores any such setup. Thus for example, it connects to the strongest wpa signal, and ignores draknetcenter's attempt to get it to connect to a specific ESSID. This is true of all attempts by draknetcenter to specify attributes of the connection. I get around this by having ifup-eth copy only the lines for the desired essid to a different file and telling wpa_supplicant to connect using that config file. But this is clearly a kludge. NetworkManager apparently does it right somehow. (using wpa_cli) I have not been able to figure out how to make wpa_cli inteact properlywith wpa_supplicant. I have also not been able to figure out where NetworkManager stores it configuration info.
Ok, assigning to drakx-net maintainer. Can you also tell me if it's still valid in Mageia 3?
Keywords: NEEDINFO => TriagedAssignee: bugsquad => mageiaSource RPM: wpa_supplicant, drakxnet, initscripts => drakx-net
I do not have any mageia 3 system so I cannot test it. I doubt very much that it has been fixed there. This is not a bug that can be fixed by accidnt as it is really a serous misunderstanding about how wpa_supplicant works.
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 => RESOLVEDResolution: (none) => OLD