Unable to connect to WPA after updates

Frantic · 2009-06-01 16:17:02

I'm trying to connect to a WPA2 AP with hidden ssid via wpa_supplicant (tried NM also, don't say that please).

I have two machines:
1) rt61pci driver, wifi works, can connect to open APs, can't connect to WPA2 hidden ssid AP
This machine used to be able to connect to the AP sometime in Feb I think was the latest time I tried. (it connects via giga ethernet since then)
While installing machine #2, I've re-tried connecting with this machine using the exact same script, wpa_supp conf, etc, I get the same result as machine #2.

2) iwl3945 driver, as #1, can connect to open APs, can't connect to WPA2 AP with hidden ssid
I've recently installed this machine: here's what happened:
I installed it, I could connect, ran pacman -Syu: could no longer connect
After a LOT of trying out things, I got the idea to try to boot the arch 02.09 LiveCD (from which I installed): this worked, I could connect.

So I guess this is a regression somewhere.

I've tried downgrading wpa_supplicant: the latest version in the repo is 0.6.9, I've downgraded to 0.5.11 (which is on the LiveCD also), I still can't connect, so I guess the problem is somewhere else.

Exactly what happens is that:
- wpa_supplicant finds the AP (shows empty ssid string and i've confirmed the mac addr)
- wpa_supplicant goes over all APs in WPA and non-WPA modes
- when going over the right AP it discards it with "skip - SSID mismatch"
- when finished, it says "No suitable AP found."

I've tried setting the ssid in both hex and string, tried setting the psk key in both string and wpa_passphrase format (is that hex?), no change.

I believe other people are having this sort of trouble, I found a few topics describing very lightly what could be my exact came problem (about WPA AP with hidden ssid).

Does anyone know of a fix for this? Or a way I can further debug it?

Edit: some more info I missed out:
My AP uses WPA1,2 with a AES PSK.
I've also tried specifying the ap ssid and bssid via iwconfig before running wpa_supplicant.
I've also tried setting the bssid in the network block of the config file.

Here's my wpa.conf:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
ap_scan=1
update_config=1
network={
    scan_ssid=1
    #ssid=<hexSsid>
    ssid="myssid"
    #psk="myStringKey"
    psk=<key generated by wpa_passphrase here>
}

Last edited by Frantic (2009-06-01 17:03:02)

eldragon · 2009-06-01 17:10:31

have you tried netcfg?

Frantic · 2009-06-01 17:37:24

why would I want to run a tool that wraps around the original tool that doesn't work?
lol it's like I told you my car's engine is broken and you ask me if I tried running the car.
but yes, I thought about me having done something wrong, so I installed NM, didn't help.

.:B:. · 2009-06-01 17:55:55

wpa_supplicant $otheroptions -v

should show you more verbosity (add another v for more verbosity).

Frantic · 2009-06-01 18:14:06

Actually, that's the -d parameter, and I've ran it with -dddd, nothing interesting there besides what I already described.

Anyway here's the output:
http://pastie.org/496786
Uppercases Xes are added by me to block macs and such, I've marked my AP (you'll know it when you see it).

.:B:. · 2009-06-01 18:45:55

Yes... Sorry .

On Windows, at work, atm .

As for your problem, some people have hidden SSIDs working on Linux, but it gives a lot of problems often - and the security benefit is zero. So if you have no particular reason for (or aren't particularly attached to) that hidden SSID, I'd say turn it off - even if it worked before, it can help you now to debug your setup (one less possible cause).

Frantic · 2009-06-02 10:03:24

Well, I don't think it's an option when I take my laptop somewhere to ask the person to turn on his ssid broadcast because the "so cool" laptop can't connect to it otherwise

There's obviously something wrong somewhere.

I have the same scenario with iwl3945 and rt61pci, but I've found at least one more guy on arch forums who has the exact same problem with iwl4945.
I've tried downgrading wpa_supplicant.

So from the above I must conclude that the problem is not with wpa_supplicant, and not with a specific driver, but where else could the problem be?

Please don't hijack the thread on this, but by hiding the ssid vs just setting a obfuscated name lets this decision pass as a network security and not as a social or privacy-related concern (which it really is).
Plus, a LOT of networks I've used have hidden ssids.

Any more ideas on what might be causing it? Should I file a bug report?

iphitus · 2009-06-02 11:17:44

Try removing both of the scan options from that config above. Neither are necessary for a functional wpa config.

Also try being more specific. Specify key_mgmt=WPA-PSK if they're wpa/2.

As a last resort you could also specify both pairwise and group, however this probably won't be needed.

Having messed around with those, don't background wpa_supplicant, instead pass, -d, or even -dd and pipe the output to less or redirect out to a file. wpa_supplicant's verbosity is quite useful, it'll print the whole scan results, it'll say why it hasn't found an appropriate AP or it'll say at what stage it gets up to when actually associating.

As for hidden/obfuscated, hidden is still pointless. The actual essid can be forced out using various tools. It also reduces compatability, I've seen windows boxes fail to connect to hidden ssid's too. Social private reasons are redundant too, the name doesn't have to mean anything. When I set networks up for friends I usually give them the name of a fruit. Though given wireless' short range nature, it's often pretty trivial to find out where a network is based and who it belongs to.

Last edited by iphitus (2009-06-02 11:18:44)

.:B:. · 2009-06-02 14:37:41

Frantic wrote:

Well, I don't think it's an option when I take my laptop somewhere to ask the person to turn on his ssid broadcast because the "so cool" laptop can't connect to it otherwise

I wasn't aware this was not on your own network. That of course narrows down your options considerably.

Please don't hijack the thread on this, but by hiding the ssid vs just setting a obfuscated name lets this decision pass as a network security and not as a social or privacy-related concern (which it really is).

I don't see in the slightest how I would be hijacking your thread. Hijacking a thread means asking your own question in someone else's thread. I am merely pointing out it might help during troubleshooting, and that it is frequently known to cause problems with Linux.

And no - hidden SSIDs aren't a 'security' feature. It's not because you can't see it scanners can't see it or intercept the SSID in traffic . I'll leave it at that.

Also - and this might be relevant to your problem - I found this article which states

It's a violation of the 802.11 specification to keep your SSID hidden; the 802.11i specification amendment (which defines WPA2, discussed later) even states that a computer can refuse to communicate with an access point that doesn't broadcast its SSID.

And, for the incredulous:

And, even if you think your SSID is hidden, it really isn't.

Maybe the IPW3495 driver's 802.11 implementation got tightened, have you tried using an older kernel?

Frantic · 2009-06-02 15:05:03

iphitus: please read my above posts and you will see that I have already done everything you asked for and also included logs and stuff

B: like I said, I also tried this with the rt61pci driver and it's the exact same issue

regarding the hidden ssid thing, you guys didn't understand what I said
I know the ssid can be picked up, it just allows people to say:
"No, I'm not hiding I'm only doing it because it's more secure." - even tho it's not more secure and they are doing it exactly to hide it
I didn't say I condone it, it's just the way it is

Now let's move back to the original point, anyone has a constructive idea?
But please don't post stupid stuff that was answered clearly in the other posts

iphitus · 2009-06-03 10:43:11

Oops, missed the output. Though you didnt try one of the things I mentioned

Try specifying key_mgmt=WPA-PSK, group= and pairwise=.

Also, the SSID is specified in clear text, not hex.

Otherwise I've got no other suggestions, try filing a bug upstream with the driver's developer.

Last edited by iphitus (2009-06-03 10:43:25)

Frantic · 2009-06-07 20:07:29

iphitus: tried, doesn't help

iphitus · 2009-06-08 00:34:34

File a bug upstream with wpa_supplicant.

Arch Linux

#1 2009-06-01 16:17:02

Unable to connect to WPA after updates

#2 2009-06-01 17:10:31

Re: Unable to connect to WPA after updates

#3 2009-06-01 17:37:24

Re: Unable to connect to WPA after updates

#4 2009-06-01 17:55:55

Re: Unable to connect to WPA after updates

#5 2009-06-01 18:14:06

Re: Unable to connect to WPA after updates

#6 2009-06-01 18:45:55

Re: Unable to connect to WPA after updates

#7 2009-06-02 10:03:24

Re: Unable to connect to WPA after updates

#8 2009-06-02 11:17:44

Re: Unable to connect to WPA after updates

#9 2009-06-02 14:37:41

Re: Unable to connect to WPA after updates

#10 2009-06-02 15:05:03

Re: Unable to connect to WPA after updates

#11 2009-06-03 10:43:11

Re: Unable to connect to WPA after updates

#12 2009-06-07 20:07:29

Re: Unable to connect to WPA after updates

#13 2009-06-08 00:34:34

Re: Unable to connect to WPA after updates

Board footer