Hello, I cannot connect to the wireless hotspot I want to. If I select iit-wifi, using a WPA2 Enterprise security, either he would connect me to an open FreeWifi hotspot or he would ask me to confirm the wrong configuration for iit-wifi (he would take FreeWifi's config and apply it to iit-wifi, see screenshots). I still do not figure out how to solve the issue and connect to the proper hotspot, other than deleting all network configuration files in the system folders and reentering all my IDs. The screenshots show the fact the tool mixes the configurations of the hotspots. Thank you. Version-Release number of selected component (if applicable): drakx-net-0.97-1.mga1.noarch How reproducible: Very often. But not everywhere. Steps to reproduce: 1. Have open networks and WPA2 Enteprise networks at the same place. 2. Have registered connections to them. 3. Attempt a connection to both the WPA2 Enterprise and the opened hotspot. Rated as critical instead of major since this bug makes me loose hours and hours of work in the case where there are no opened hotspots. Thank you.
Created attachment 783 [details] Registered iit-wifi WPA2 Enterprise configuration
Created attachment 784 [details] This is what I can get when hitting the 'connect' button This is what I can get when hitting the 'connect' button : the configuration for FreeWifi, sticked to iit-wifi...
Created attachment 785 [details] The log when I tried to connect at my work (not my school) Actually, any WPA2 hotspot can make this bug happen.
Finally, the issue appear on september 9. So the phase that addresses this bug is located at the bottom of the file. But as I had other bugs the previous days, you may find other interesting information above the logs of Sept. 9. I apologise for the disorganized report. I am awfully tired and late. Thank you by advance for your help.
This bug has happenned once again today and I have lost two hours of work for nothing. I am writing you using Fedora to claim for help, as this situation is particularly frustrating and enerving. I have no clue of why the program is doing this and I do not know what to do to provide more information or understand more what the program does. I've explained these huge issues and discomfort in the mailing list twice, the bug occurs often on several laptops, I opened one ticket per issue, I posted logs concerning the problems, I did my best and I did not have a single answer while I am almost throwing this computer by the window every time I have to face this bug. Please help me and/or tell me what to do.
Summary: Wireless tool connects me to the wrong hotspot => Wireless tool connects me to the wrong hotspot or to the good one with wrong ids
The issue that happened at September 9 seems related due to a firmware error, citing from your dmesg output: Sep 9 10:44:21 Thomas-Pavilion kernel: iwlagn 0000:02:00.0: Microcode SW error detected. Restarting 0x2000000. There's not much we can do about that, this particular issue should be reported to Intel wireless developers http://www.intellinuxwireless.org/bugzilla Mayve you want to read the guide before doing so: http://intellinuxwireless.org/?n=fw_error_report About the problems with connecting, i've no clue :(
CC: (none) => doktor5000
I have suspected this initially, but the bug is also reproduced under my current laptop who uses the proprietary Broadcom driver and module. I'll take care of the firmware bug, but this is likely not the cause of the issue since I am also affected with another wireless hardware that is not using Intel's firmware (perhaps a consequence of my desperate attempts to solve the issue at that time).
No, it may be not the cause of your connection problems, just tried to explain why you had such a problem on september 9 again.
Ok, I understand.
As an experiment, you might want to try: rpm -e --nodeps networkmanager and reboot urpme will try to uninstall task-gnome, so you need to do it directly with rpm. Also, if you update via urpmi --auto-select, networkmanager may get reinstalled.
CC: (none) => ftg
Oh, and depending on whether the problem is something NM put in your ifcfg files, you may need to delete the wlan0 interface and re-add it once NM is gone.
I'll try this at home then (cannot connect anywhere else here, except to the network that is unreachable), I'll also need KNetworkManager since I use KDE.
Created attachment 952 [details] Draknetcenter_errors.txt I ran Draknetcenter with a few options for testing, and while he continued misdetecting my iit-wifi as opened instead of WPA2 Enterprise, and refusing to apply my login and password.
Created attachment 953 [details] iit-wifi file without NM (not modified)
Created attachment 954 [details] ifcfg-eth1 without NM (not modified) Note : the fact Mageia uses mysteriously eth1 instead of wlan0 is not a problem currently, even if this is a bug.
Attachment 954 mime type: application/octet-stream => text/plain
Bug assigned to the package maintainer.
Assignee: bugsquad => mageia
Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED. @ Blino Please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead. Don't change anything if you want to be pinged by me in this report again ;)
CC: (none) => marja11
Big is still there. the fact he may not be able read a hotspot ID's may be due because of permission issues though, NetworkMAnager requires me to enter my password for some connections.
3-monthly ping
This sounds similar to my issue with Gnome 3's beta atm. The network app works absolutely fine in KDE4. However, it seems to have difficulties of this nature in Gnome 3. I'll try connecting to one network, and it'll apply the credentials to another and attempt to connect to it instead. The network app will also continually try connecting using the lowest security type available rather than the selected (For instance, there are some WEP connections nearby...I try to connect to a WPA2 connection. It asks for my password, and I set it to WPA2 and enter the password. The connection fails, I check the config...lo and behold its set to "OPEN WEP" as the password type). Note this only happens to me in the gnome install. Seems like Network Manager and the network app might be fighting.
CC: (none) => ty.PixelPlane
I don't think this is related to NetworkManager : I can reproduce this bug while NM is not installed. And NM itself was the alternative I was forced to use to connect to my wireless network. Otherwise the symptoms are similar if not identical to what you describe.
This still occurs now. I am forced to connect using ethernet rather than wireless. This is a shame.
(In reply to comment #22) > This still occurs now. I am forced to connect using ethernet rather than > wireless. This is a shame. Do you have the same problem in Mageia 2?
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
No additional information was asked. The issue still occurs in Mageia 2.
(In reply to comment #25) > No additional information was asked. The issue still occurs in Mageia 2. Thx :)
Version: 1 => 2Whiteboard: (none) => MGA1TOO
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