Weird wireless/wpa_supplicant screw-up.

(This could be user error/userspace bug, feel free to point me in the right direction if you think so. Hopefully somebody knows what I've broken this time...)

Fedora Rawhide as of this morning, 2.6.33-mmotm0304 kernel, wpa_supplicant-0.6.8-8.fc13.x86_64 wireless-tools-29-5.1.fc12.x86_64. Dell Latitude E6500, Intel 5100AGN card.

So I finally get a few spare cycles, and re-try getting WPA2 working on our enterprise wireless network, and wpa_supplicant reports it completed successfully and set the keys, but 'iwconfig' reports back:

wlan0 IEEE 802.11abgn ESSID:"VT-Wireless"
Mode:Managed Frequency:2.412 GHz Access Point: 00:0F:F7:14:2A:91
Bit Rate=1 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=42/70 Signal level=-68 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

No encryption key. Yee. Hah.

But wait... 'iwlist keys' reports:

wlan0 2 key sizes : 40, 104bits

          4 keys available :
                [1]: off
                [2]: 6A7D-5232-BDE6-E40A-71C5-EC21-6399-00F3-5CAD-D394-D1E5-1261-BD99-0115-F4A8-63B2 (256 bits)
                [3]: off
                [4]: off
          Current Transmit Key: [1]

So we got a perfectly good key, but we're not using it.

Anybody got any ideas/hints?

and does it work? The iwlist stuff could just be a reporting error...

johannes

In fact, it's not even an error, it's perfectly normal because we use that key for RX only since that's the group key ... So if there is a problem, iwlist is completely unsuitable for diagnosing it.

johannes

OK, getting closer ;)

in net/wireless/wext-compat.c, we have this in cfg80211_wext_giwencode() after I add some printk's:

printk(KERN_INFO "In giwencode idx=%d keys=%x cipher=%x\n", idx, wdev->wext.keys, wdev->wext.keys->params[idx].cipher);
        if (!wdev->wext.keys || !wdev->wext.keys->params[idx].cipher) {
printk(KERN_INFO "And we're going home...\n");
                erq->flags |= IW_ENCODE_DISABLED;
                erq->length = 0;
                return 0;
        }

which produces

[  151.401195] In giwencode idx=0 keys=1d023600 cipher=0
[  151.401198] And we're going home...

So the root cause has something to do with params[idx].cipher being unset.

I've become reasonably sure it's not pilot error on my part, as a co-worker's laptop has the same issue - mine is a Dell Latitude E6500 with an Intel 5000agn cardrunning Fedora Rawhide and a 2.6.34-rc1-mmotm kernel, and his is a Latitude D830 with an Intel 3945, Ubuntu with a 2.6.32 kernel.

Looks like time to instrument more of wext-compat.c. Oh joy.

Sorry if it's obvious, but please make sure you don't have another wpa_supplicant running and there is no other software that tries to control the interface.

If you have NetworkManager, the device in question should be unmanaged. This could be done by adding this
to /etc/NetworkManager/nm-system-settings.conf:

[main]
plugins=keyfile

[keyfile] unmanaged-devices=/org/freedesktop/Hal/devices/net_00_1f_11_01_06_55

If the "plugins" line exists, "keyfile" should be added, separated by comma from the previous word. The MAC address must be lowercase. Entries on the unmanaged-devices line are separated by semicolons.

Use "cnetworkmanager -d" to make sure the device is unmanaged (install cnetworkmanager if needed). You may need to restart NetworkManager or even reboot after changing the configuration.

Perhaps we need it in the FAQ somewhere.

Regards,
Pavel Roskin

No NetworkManager here, so that shoots that theory. There's just a wpa_supplicant running and nothing else managing the interface.

No ... you're not getting closer at all ... you ignored my second email.

No ... look at _all_ that it produces.

[   98.592575] In giwencode idx=0 keys=ffff88001b304000 cipher=0
[   98.592580] And we're going home...
*****
[   98.592633] In giwencode idx=1 keys=ffff88001b304000 cipher=fac04
*****
[   98.592749] In giwencode idx=2 keys=ffff88001b304000 cipher=0
[   98.592751] And we're going home...
[   98.592803] In giwencode idx=3 keys=ffff88001b304000 cipher=0
[   98.592805] And we're going home...
[   98.592856] In giwencode idx=0 keys=ffff88001b304000 cipher=0
[   98.592859] And we're going home...

See? It reports one key which is the RX-only group key which is absolutely correct.

Not at all.

GIWENCODE is 100% unsuitable for WPA. Just forget about "iwlist key". And then we'd like to know what the actual problem is.

johannes

It matches what 'iwlist keys' reports, but I remain unconvinced of its "correctness". If a TX key has been set anyplace, what allows me to verify that it was in fact set?

I was referring to the root cause of why 'iwlist keys' wasn't reporting anything for the other 3 key slots.

Feel free to point me at the officially approved substitute.

The problem is that I do 'iwconfig', and I see:

Encryption key:off

And if I do 'iwlist keys', I don't see a TX key listed, which certainly gives the at least the impression that we're not encrypting outbound traffic. If I'm not supposed to trust 'iwconfig' or 'iwlist key' to tell me whether WPA2 traffic is in fact encrypted or not, what *am* I supposed to use instead?

There's two possibilities:

1) iwconfig and iwlist keys are correctly reporting I don't have a TX key set - which means wpa_supplicant and/or the kernel is failing to get the key set, which is a problem.

2) iwconfig and iwlist are lying through their teeth, and reporting there isn't any key set when in fact there is. This is still a problem because it implies to users their traffic isn't secured.

I'll point out that until fairly recently 'iwconfig' *did* report a key for WPA2, so this looks like a regression on somebody's part.

That's your problem then, not mine. It's correct in how wext operates. If you want to know why, you'll have to understand the distinction between PTK and GTK and how wext operates with them.

Nothing. Blame it on wext and on the fact that nobody cares.

Right ... all of that is completely correct. See above about PTK and GTK ... You seem to not be interested in telling me what your actual problem is, if there is one. If your actual problem is just that iwlist reports what you think is wrong information (which is just incomplete, it doesn't show the PTK) then that's nothing I actually care about fixing.

I'm sure it did not.

johannes

Pretty fucking fundemental thing to not care about, being able to tell whether or not your connection is in fact encrypted or not. But I guess you expect users to be all-knowing and magically know that even though iwconfig says 'Encryption key: off' that in fact their connection is encrypted (unless of course it's off because it's not encrypted), and how to troubleshoot the difference between "not encrypted" and "lying about not being encrypted" when the utilities in wireless-tools provide the same output in both cases.

Unfortunately, I'm a stupid idiot, and when I'm trying to get wpa_supplicant working and hitting various unrelated certificate issues, resolve those, finally get wpa_supplicant to say it connected, but then I type 'iwconfig' and it *still* says "Encryption key: off", I'm unable to make the leap of logic and say "AHA! It's encrypted now", and I start trying to find what I still have to fix so it will say it's encrypted.

Sorry for bothering you and wasting your time.

The problem is a combination of things - (a) iwlist and iwconfig report no crypto and (b) there doesn't seem to be any *other* way for userspace to find out that in fact you have an encrypted WPA2 connection.

That's not true.

I'm using cfg80211 with wpa_supplicant (even when I only use WEP, despite the name of the wpa_supplicant application!).

And in this case, you can use "wpa_cli status" and well see all the details, no matter if you use WPA, WPA2, WEXT or some of the 802.11x derivates:

# wpa_cli status
Selected interface 'wlan0'
bssid=00:xx:xx:xx:xx:xx
ssid=MUMBLEFUTZ
id=0
mode=station
pairwise_cipher=WEP-40
group_cipher=WEP-40
key_mgmt=NONE
wpa_state=COMPLETED
ip_address=172.16.xxx.xx

http://www.holgerschurig.de

Wow. Is *that* where they hid it?

In any case, that does fit the bill, even if it was well-hidden:

# wpa_cli status
Selected interface 'wlan0'
bssid=00:0f:f7:14:2a:91
ssid=VT-Wireless
id=0
pairwise_cipher=CCMP
group_cipher=TKIP
key_mgmt=WPA2/IEEE 802.1X/EAP
wpa_state=COMPLETED
ip_address=172.31.143.252
Supplicant PAE state=AUTHENTICATED
suppPortStatus=Authorized
EAP state=SUCCESS
selectedMethod=13 (EAP-TLS)
EAP TLS cipher=DHE-RSA-AES256-SHA