Marshaling issues w/ compat-wireless-2010-08-19

(1) "Unknown event 5" messages when starting up hostapd (line 95 below):

(2) Some highly unlikely values from the hostapd debugging messages when parsing out WEP authentication messages (line 507):

This is captured in http://pastebin.ca/1924659 :

authentication: STA=f8:1e:df:1e:c2:23 auth_alg=35510 auth_transaction=79 status_code=21688 wep=1 Unsupported authentication algorithm (35510)

I'm wondering if some messages that are passed up to user-space via netlink from the driver might have changed their schema, i.e. adding new fields in the middle of a structure or moving fields around within a structure.

Quoted 4 lines

authentication: STA=f8:1e:df:1e:c2:23 auth_alg=35510 auth_transaction=79 status_code=21688 wep=1 Unsupported authentication algorithm (35510)

Quoted 4 lines

I'm wondering if some messages that are passed up to user-space via netlink from the driver might have changed their schema, i.e. adding new fields in the middle of a structure or moving fields around within a structure.

Looks more like a crypto problem to me, as this should be the encrypted challenge in your shared key handshake. IOW, it looks like the frame isn't getting decrypted by mac80211 for some reason.

Quoted 8 lines · Johannes Berg

Quoted 8 lines

authentication: STA=f8:1e:df:1e:c2:23 auth_alg=35510 auth_transaction=79 status_code=21688 wep=1 Unsupported authentication algorithm (35510)

I'm wondering if some messages that are passed up to user-space via netlink from the driver might have changed their schema, i.e. adding new fields in the middle of a structure or moving fields around within a structure.

Quoted 3 lines

Looks more like a crypto problem to me, as this should be the encrypted challenge in your shared key handshake. IOW, it looks like the frame isn't getting decrypted by mac80211 for some reason.

Works fine here in hwsim, so likely to be either a driver problem (hw decrypts frame, but driver doesn't tell us so), something that has been fixed between then and now, or a compat specific problem.

johannes

Quoted 17 lines · Johannes Berg

Quoted 11 lines · Johannes Berg

Quoted 8 lines

authentication: STA=f8:1e:df:1e:c2:23 auth_alg=35510 auth_transaction=79 status_code=21688 wep=1 Unsupported authentication algorithm (35510)

I'm wondering if some messages that are passed up to user-space via netlink from the driver might have changed their schema, i.e. adding new fields in the middle of a structure or moving fields around within a structure.

Looks more like a crypto problem to me, as this should be the encrypted challenge in your shared key handshake. IOW, it looks like the frame isn't getting decrypted by mac80211 for some reason.

Works fine here in hwsim, so likely to be either a driver problem (hw decrypts frame, but driver doesn't tell us so), something that has been fixed between then and now, or a compat specific problem.

Quoted 1 line

johannes

I'll bump to yesterday's baking, apply your patch, and retry. Maybe it was a spurious issue.

If that doesn't work, I'll try forcing h/w decryption off in the NIC.

Retried with yesterday's baking. No joy. Also reloaded the module with nohwcrypt=1 and same result (except that the value in the auth_alg field changed from 6421 to 44995).

I've got a stock Fedora Core 13 install (updated today) with the hostapd-0.6.10 rpm and hostapd-0.7.2 compiled from sources. The NIC is a Ubiquiti SR71e (AR9280).

(2) Some highly unlikely values from the hostapd debugging messages when parsing out WEP authentication messages (line 507):

authentication: STA=f8:1e:df:1e:c2:23 auth_alg=35510 auth_transaction=79 status_code=21688 wep=1 Unsupported authentication algorithm (35510)

Quoted 4 lines · Philip Prindeville

I've got a stock Fedora Core 13 install (updated today) with the hostapd-0.6.10 rpm and hostapd-0.7.2 compiled from sources. The NIC is a Ubiquiti SR71e (AR9280).
(2) Some highly unlikely values from the hostapd debugging messages when parsing out WEP authentication messages (line 507):
authentication: STA=f8:1e:df:1e:c2:23 auth_alg=35510 auth_transaction=79 status_code=21688 wep=1
Unsupported authentication algorithm (35510)

I was unable to reproduce this with the current development tree snapshots. Shared key authentication worked with AR9280 and the current wireless-testing.git and hostap.git in my tests. If you are still seeing this, you could also try to disable hw crypto to remove one possible issue area by using nohwcrypt=1 module parameter when loading ath9k.

Quoted 11 lines · Jouni Malinen

Quoted 4 lines · Philip Prindeville

I've got a stock Fedora Core 13 install (updated today) with the hostapd-0.6.10 rpm and hostapd-0.7.2 compiled from sources. The NIC is a Ubiquiti SR71e (AR9280).
(2) Some highly unlikely values from the hostapd debugging messages when parsing out WEP authentication messages (line 507):
authentication: STA=f8:1e:df:1e:c2:23 auth_alg=35510 auth_transaction=79 status_code=21688 wep=1
Unsupported authentication algorithm (35510)

I was unable to reproduce this with the current development tree snapshots. Shared key authentication worked with AR9280 and the current wireless-testing.git and hostap.git in my tests. If you are still seeing this, you could also try to disable hw crypto to remove one possible issue area by using nohwcrypt=1 module parameter when loading ath9k.

Already tried that, and it didn't help.

-Philip

Quoted 13 lines · Philip Prindeville

Quoted 11 lines · Jouni Malinen

Quoted 4 lines · Philip Prindeville

I've got a stock Fedora Core 13 install (updated today) with the hostapd-0.6.10 rpm and hostapd-0.7.2 compiled from sources. The NIC is a Ubiquiti SR71e (AR9280).
(2) Some highly unlikely values from the hostapd debugging messages when parsing out WEP authentication messages (line 507):
authentication: STA=f8:1e:df:1e:c2:23 auth_alg=35510 auth_transaction=79 status_code=21688 wep=1
Unsupported authentication algorithm (35510)

I was unable to reproduce this with the current development tree snapshots. Shared key authentication worked with AR9280 and the current wireless-testing.git and hostap.git in my tests. If you are still seeing this, you could also try to disable hw crypto to remove one possible issue area by using nohwcrypt=1 module parameter when loading ath9k.

Quoted 3 lines

Already tried that, and it didn't help.

-Philip

I also tried with the tarballs from 2010-07-19, and 2010-08-29 and saw the same issue.

I also was able to reproduce the issue with "nohwcrypt=1".

So I'm wondering what if decryption is working fine, but the buffer has an alignment issue or isn't being marshaled into netlink properly?

-Philip

Just following up: I isolated the problem.

I had taken the sample hostapd.conf that comes with hostapd-0.7.2 and copied it into /etc/.

Then I enabled the following commented out fields:

bridge=br0
driver=nl80211
ssid=my-hp-test
country_code=US
hw_mode=g
channel=10
wep_default_key=0
wep_key0=123456789a
ieee80211n=1

but what broke it was:

wep_key_len_broadcast=5
wep_key_len_unicast=5
wep_rekey_period=300

if I turned off those last 3, things work again.

Quoted 22 lines · Philip Prindeville

Just following up: I isolated the problem.

I had taken the sample hostapd.conf that comes with hostapd-0.7.2 and copied it into /etc/.

Then I enabled the following commented out fields:

bridge=br0
driver=nl80211
ssid=my-hp-test
country_code=US
hw_mode=g
channel=10
wep_default_key=0
wep_key0=123456789a
ieee80211n=1

but what broke it was:

wep_key_len_broadcast=5
wep_key_len_unicast=5
wep_rekey_period=300

Quoted 1 line

if I turned off those last 3, things work again.

Hah. I don't even know what that does. What were you trying to achieve? Aren't those related to dynamic WEP, but you configured static WEP?

johannes

Quoted 16 lines

Quoted 16 lines

bridge=br0
driver=nl80211
ssid=my-hp-test
country_code=US
hw_mode=g
channel=10
wep_default_key=0
wep_key0=123456789a
ieee80211n=1

but what broke it was:

wep_key_len_broadcast=5
wep_key_len_unicast=5
wep_rekey_period=300

Quoted 3 lines

Quoted 1 line

if I turned off those last 3, things work again.

Hah. I don't even know what that does. What were you trying to achieve? Aren't those related to dynamic WEP, but you configured static WEP?

I was trying to test the rekeying feature, where new keys are multicast when the group membership changes.