| Summary: | wpa_supplicant: can not authenticate with an IEEE802.11b card using the orinoco card system | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Elmar Stellnberger <estellnb> |
| Component: | RPM Packages | Assignee: | Thomas Backlund <tmb> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | mageia, marja11, thierry.vignaud |
| Version: | 5 | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | wpa_supplicant | CVE: | |
| Status comment: | |||
| Attachments: |
dhclient.conf
wpa_computerzimmer.conf journalctl - repeated all steps + shorewall cfg output of lspcidrake wpa_supplicant messages journalctl - messages for trying the orinoco card |
||
|
Description
Elmar Stellnberger
2014-07-11 17:29:21 CEST
Created attachment 5282 [details]
dhclient.conf
Created attachment 5283 [details]
wpa_computerzimmer.conf
Installer and Release bugs should always be set to cauldron, because once the isos for a stable version have been created, they cannot be changed. This bug was filed very long ago, for Mageia 4. Was this bug still valid for Mageia 5? (If so, please do _not_ set the version to "5". Only asking because if it was still valid for Mageia 5, that then we'll know we'll have to pay attention to this issue when testing the 6 alpha's and later). Please close this bug report if the problem was solved in Mageia 5hhhh Keywords:
(none) =>
NEEDINFO Sorry for having overlooked this bug report. It's likely an issue with wpa_supplicant or similar, so not a "Release" bug as stated above. Could you test with Mageia 5 or Cauldron to see if the issue is still there? Or did you manage to solve it in the end? CC:
sysadmin-bugs =>
mageia, thierry.vignaud Hi Marja, Hi Rémi! No, I did not look after this bug any more in the meanwhile. As far as I remember it was filed with an USB WLAN stick from DLINK and a machine called GC Frontman. It should be possible to retest it with the WLAN stick and Cauldron on another machine (as I do not have the GC Frontman here at lake Ossiach). However I will have to fetch the WLAN stick first which may last a few days. Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. 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. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you 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. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. 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. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/ As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version) If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED" 2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. 3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page: https://wiki.mageia.org/en/How_to_report_a_bug_properly If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/ Status:
NEW =>
RESOLVED repeated all steps in comment #1 under Mageia 5 / 4.1.13-desktop-2.mga5 with the exactly same results as in comment #1; i.e. bug persists in spite of the latest wifi updates. Status:
RESOLVED =>
REOPENED (In reply to Elmar Stellnberger from comment #8) > repeated all steps in comment #1 under Mageia 5 / 4.1.13-desktop-2.mga5 with > the exactly same results as in comment #1; i.e. bug persists in spite of the > latest wifi updates. Thanks for the feedback, Elmar. Please attach journalctl.txt that is the result of (as root): journalctl -b > journalctl.txt and the output of: lspcidrake -v CC:
(none) =>
marja11 Created attachment 7329 [details]
journalctl - repeated all steps + shorewall cfg
It turned out that shorewall was not configured for any dynamically added network interfaces; I have finally done so by adding the following lines to /etc/shorewall/interfaces and by invoking shorewall restart:
net eth0 detect
net wlp0s2f3u1 detect
Created attachment 7330 [details]
output of lspcidrake
here for completeness reasons some info about my hardware.
Elmar Stellnberger
2016-01-09 19:12:31 CET
Attachment 7329 mime type:
text/plain =>
application/x-bzip2 As it turned out there was just a configuration issue when using my ralink network card. The following IEEE802.11b card supported by the orinoco card system seems to have a real problem though:
# lspcmcia
Socket 0 Bridge: [yenta_cardbus] (bus ID: 0000:00:08.0)
Socket 0 Device 0: [orinoco_cs] (bus ID: 0.0)
# #iwlist eth0 scanning
#eth0 Scan completed :
Cell 01 - Address: 38:22:9D:82:8B:8A
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=70/70 Signal level=-11 dBm
Encryption key:on
ESSID:"aonmodem"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s
Mode:Master
Extra:tsf=0000000000000000
Extra: Last beacon: 69ms ago
IE: Unknown: 0008616F6E6D6F64656D
IE: Unknown: 010882848B962430486C
IE: Unknown: 17C00000000000000000000000000000000000000000
Created attachment 7331 [details]
wpa_supplicant messages
As the output of wpa_supplicant shows it fails to authenticate with this card (used same configuration as with the ralink):
wpa_supplicant -c wpa_computerzimmer.conf -Dwext -ieth0
With -Dwired it is less verbose but does not work either.
wpa_supplicant -c wpa_computerzimmer.conf -Dwired -ieth0
Successfully initialized wpa_supplicant
eth0: Associated with 01:80:c2:00:00:03
^C
Created attachment 7332 [details]
journalctl - messages for trying the orinoco card
Elmar Stellnberger
2016-01-09 19:45:52 CET
Summary:
no (inter)net access with wlan: can do an arping but not a ping or any other network communication =>
wpa_supplicant: can not authenticate with an IEEE802.11b card using the orinoco card system For the orinoco_cs I have now opened a bug at the kernel bug tracker: https://bugzilla.kernel.org/show_bug.cgi?id=113461 Marking as resolved since the original issue has in deed been resolved. Status:
REOPENED =>
RESOLVED |