Weird wireless/wpa_supplicant screw-up.

Weird wireless/wpa_supplicant screw-up.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

(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?



[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: Weird wireless/wpa_supplicant screw-up.

[Johannes Berg]

On Mon, 2010-03-08 at 17:22 -0500, Valdis.Kletnieks@vt.edu wrote:
> (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,

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

johannes

Re: Weird wireless/wpa_supplicant screw-up.

[Johannes Berg]

On Fri, 2010-03-12 at 03:14 -0800, Johannes Berg wrote:
> On Mon, 2010-03-08 at 17:22 -0500, Valdis.Kletnieks@vt.edu wrote:
> > (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,
> 
> and does it work? The iwlist stuff could just be a reporting error...

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

Re: Weird wireless/wpa_supplicant screw-up.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

On Fri, 12 Mar 2010 03:14:41 PST, Johannes Berg said:
> On Mon, 2010-03-08 at 17:22 -0500, Valdis.Kletnieks@vt.edu wrote:
> > (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,
> 
> and does it work? The iwlist stuff could just be a reporting error...

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.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: Weird wireless/wpa_supplicant screw-up.

[Pavel Roskin]

On Fri, 2010-03-12 at 16:49 -0500, Valdis.Kletnieks@vt.edu wrote:

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

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

Re: Weird wireless/wpa_supplicant screw-up.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Fri, 12 Mar 2010 17:19:41 EST, Pavel Roskin said:
> On Fri, 2010-03-12 at 16:49 -0500, Valdis.Kletnieks@vt.edu wrote:
> 
> > So the root cause has something to do with params[idx].cipher being unset.
> 
> 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.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: Weird wireless/wpa_supplicant screw-up.

[Johannes Berg]

On Fri, 2010-03-12 at 16:49 -0500, Valdis.Kletnieks@vt.edu wrote:

> OK, getting closer ;)

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

> 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...

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.

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

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

Re: Weird wireless/wpa_supplicant screw-up.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

On Fri, 12 Mar 2010 19:09:09 PST, Johannes Berg said:
> 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.

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?

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

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

> GIWENCODE is 100% unsuitable for WPA. Just forget about "iwlist key".

Feel free to point me at the officially approved substitute.

> And then we'd like to know what the actual problem is.

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.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: Weird wireless/wpa_supplicant screw-up.

[Johannes Berg]

On Tue, 2010-03-16 at 23:06 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 12 Mar 2010 19:09:09 PST, Johannes Berg said:
> > 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.
> 
> It matches what 'iwlist keys' reports, but I remain unconvinced of
> its "correctness".  

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.

> If a TX key has been set anyplace, what allows me
> to verify that it was in fact set?

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

> > > So the root cause has something to do with params[idx].cipher being unset.
> > 
> > Not at all.
> 
> I was referring to the root cause of why 'iwlist keys' wasn't reporting
> anything for the other 3 key slots.

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'll point out that until fairly recently 'iwconfig' *did* report a
> key for WPA2, so this looks like a regression on somebody's part.

I'm sure it did not.

johannes

Re: Weird wireless/wpa_supplicant screw-up.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

On Tue, 16 Mar 2010 20:22:30 PDT, Johannes Berg said:
> On Tue, 2010-03-16 at 23:06 -0400, Valdis.Kletnieks@vt.edu wrote:

> > If a TX key has been set anyplace, what allows me
> > to verify that it was in fact set?
> 
> Nothing. Blame it on wext and on the fact that nobody cares.

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.

> 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.

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.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: Weird wireless/wpa_supplicant screw-up.

[Holger Schurig]

> 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

Re: Weird wireless/wpa_supplicant screw-up.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Wed, 17 Mar 2010 10:03:54 BST, Holger Schurig said:

> 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:

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




[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]