Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#18423 - [netcfg] Wireless connectivity broken due to desupported wpaessid quirk

Attached to Project: Arch Linux
Opened by V.I. (vi) - Monday, 22 February 2010, 04:12 GMT
Last edited by Rémy Oudompheng (remyoudompheng) - Monday, 06 June 2011, 06:30 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
In netcfg 2.5.2+ the wpaessid quirk is no longer supported, which breaks connectivity for certain Atheros wireless cards, like AR5BXB63 on Acer Aspire One. The attached one-line patch for netcfg-2.5.4 adds this support back and allows the card to work with these netcfg versions.

Steps to reproduce:
netcfg myprofile

>WPA Authentication/Association Failed
   netcfg-2.5.4-wireless.patch (0.5 KiB)
This task depends upon

Closed by  Rémy Oudompheng (remyoudompheng)
Monday, 06 June 2011, 06:30 GMT
Reason for closing:  Fixed
Additional comments about closing:  Support for hidden SSIDs has been implemented.
Comment by James Rayner (iphitus) - Tuesday, 23 February 2010, 11:41 GMT
This hack really shouldn't be required by now. Which driver are you using?

If it's ath5k/ath9k, try creating /etc/network.d/interface/$INTERFACE and putting this line in it:
WPA_DRIVER="nl80211"

Comment by V.I. (vi) - Thursday, 25 February 2010, 03:06 GMT
I am using ndiswrapper and a hidden ESSID.
ath5k does not provide reliable connectivity with this card - it disconnects after a minute or so.
However, even ath5k cannot connect unless wpaessid is provided.
I have tried it today several times, and verified with lsmod and ps -eF that ath5k was loaded and wpa_supplicant used -D nl80211.
Comment by Georg Wolfram (Gosi) - Thursday, 25 February 2010, 07:29 GMT
I have an Intel Pro 2200 wireless interface and I also used this quirk to support my hidden ESSID. I think the ESSID needs to be set manually, if it is hidden.
Maybe it is better to introduce a new config option like ESSID_HIDDEN=yes instead of the quirks. There are also a lot of reports regarding hidden essid in the forum (search for "netcfg hidden").
Comment by James Rayner (iphitus) - Thursday, 25 February 2010, 09:33 GMT
I don't really want to introduce a new config option or the quirk. It's a bug somewhere else and I don't like the idea of re-introducing the workaround to hide a bug

try this:
PRE_UP="iwconfig wlan0 essid mynetworkessid"
Comment by Georg Wolfram (Gosi) - Thursday, 25 February 2010, 18:32 GMT
Thanks, PRE_UP solved it for me.
Comment by V.I. (vi) - Friday, 26 February 2010, 04:12 GMT
This works for me as well.
   netcfg-2.5.4-wpaessid.patch (0.7 KiB)
Comment by Dan Griffiths (Ghost1227) - Saturday, 27 February 2010, 10:00 GMT
since both instances referenced have been resolved, can we now close this bug?
Comment by V.I. (vi) - Saturday, 27 February 2010, 17:25 GMT
The bug is that a feature has been removed without any reasonable notification, so from the point of view of the end-users the new version of the package stopped working. If we want the users to trust our software, we cannot simply knowingly remove working features and make the affected users waste hours debugging the issue. The second patch solves this problem. Also, the wiki should mention the deprecation of wpaessid.
Comment by Matthias Dienstbier (fs4000) - Friday, 05 March 2010, 23:02 GMT
I don't think that's the right solution. If wpa_supplicant isn't able to associate it won't be able to reassociate if connection gets lost, i think. You should try
ap_scan=2
in wpa_supplicant's config. This will make wpa_supplicant to try to associate with any AP regardless if it thinks it's the right one or not.
Comment by V.I. (vi) - Saturday, 06 March 2010, 05:40 GMT
ap_scan=2 by itself did not fix the issue for me. PRE_UP="iwconfig $INTERFACE essid $ESSID" in the profile did. I wonder if this is always needed whenever a hidden ESSID is used.
Comment by James Rayner (iphitus) - Saturday, 06 March 2010, 07:00 GMT
Also, I forgot about this option,

Try setting:
IWCONFIG="essid youressidhere"

That should also work.

Vassiliy: "Hidden"/blank SSID's are in violation of the 802.11 spec which is why you get dodgy and unpredictable behaviour. Further, hidden networks provide no extra security. The network is still "visible" and the actual SSID can be determined easily.
Comment by V.I. (vi) - Tuesday, 09 March 2010, 02:07 GMT
IWCONFIG="essid $ESSID" works as well.
It would be good to be able to connect easily from Linux, even when one does not have control over the AP which is set up in a non-standard way.
Comment by Thomas Bächler (brain0) - Tuesday, 03 August 2010, 22:45 GMT
http://projects.archlinux.org/netcfg.git/commit/?id=6b626a4773a26b4275cd7be663a5d7547ea4cb11

Loading...