[ath9k-devel] Dropped frames (unauthorized port) in AP mode

[Mihai Moldovan <ionic@ionic.de>]

Hi all,

I am still experiencing huge problems with my ath9k cards (AR9380 and AR5416) in
master mode.

Both devices + some e1000e card are bridged together, with hostapd acting as a
WPA-PSK authenticator.

However, no station is able to successfully authenticate and create a connection.

hostapd is throwing out those messages:

hostapd: wifi1: STA f8:1e:df:dd:01:f7 IEEE 802.11: authentication OK (open system)
[...] MLME: MLME-AUTHENTICATE.indication(f8:1e:df:dd:01:f7, OPEN_SYSTEM)
[...] MLME: MLME-DELETEKEYS.request(f8:1e:df:dd:01:f7)
[...] IEEE 802.11: authenticated
[...] IEEE 802.11: association OK (aid 1)
[...] IEEE 802.11: associated (aid 1)
[...] MLME: MLME-ASSOCIATE.indication(f8:1e:df:dd:01:f7)
[...] MLME: MLME-DELETEKEYS.request(f8:1e:df:dd:01:f7)
[...] WPA: event 1 notification
[...] WPA: start authentication
[...] IEEE 802.1X: unauthorizing port
[...] WPA: sending 1/4 msg of 4-Way Handshake
[...] WPA: EAPOL-Key timeout
[...] WPA: sending 1/4 msg of 4-Way Handshake
[...] WPA: EAPOL-Key timeout
[...] WPA: sending 1/4 msg of 4-Way Handshake
[...] WPA: EAPOL-Key timeout
[...] WPA: sending 1/4 msg of 4-Way Handshake
[...] WPA: EAPOL-Key timeout
[...] WPA: PTKSTART: Retry limit 4 reached
[...] WPA: event 3 notification
[...] IEEE 802.1X: unauthorizing port
[...] MLME: MLME-DEAUTHENTICATE.indication(f8:1e:df:dd:01:f7, 2)
[...] MLME: MLME-DELETEKEYS.request(f8:1e:df:dd:01:f7)
[...] IEEE 802.11: deauthenticated due to local deauth request

(information in [...] is redundant and the same as within the very first line)

Also, those kernel messages pop up:

[ 7131.846665] wifi1: Allocated STA f8:1e:df:dd:01:f7
[ 7131.846670] wifi1: moving STA f8:1e:df:dd:01:f7 to state 2
[ 7131.846672] wifi1: moving STA f8:1e:df:dd:01:f7 to state 3
[ 7131.846731] wifi1: Inserted STA f8:1e:df:dd:01:f7
[ 7131.846759] wifi1: dropped frame to f8:1e:df:dd:01:f7 (unauthorized port)
[ 7134.951612] wifi1: moving STA f8:1e:df:dd:01:f7 to state 2
[ 7134.951621] wifi1: moving STA f8:1e:df:dd:01:f7 to state 1
[ 7134.951623] wifi1: Removed STA f8:1e:df:dd:01:f7
[ 7134.976011] wifi1: Destroyed STA f8:1e:df:dd:01:f7
[ 7153.896641] wifi1: Allocated STA f8:1e:df:dd:01:f7
[ 7153.896647] wifi1: moving STA f8:1e:df:dd:01:f7 to state 2
[ 7153.896649] wifi1: moving STA f8:1e:df:dd:01:f7 to state 3
[ 7153.896712] wifi1: Inserted STA f8:1e:df:dd:01:f7
[ 7153.896734] wifi1: dropped frame to f8:1e:df:dd:01:f7 (unauthorized port)
[ 7157.001024] wifi1: moving STA f8:1e:df:dd:01:f7 to state 2
[ 7157.001035] wifi1: moving STA f8:1e:df:dd:01:f7 to state 1
[ 7157.001037] wifi1: Removed STA f8:1e:df:dd:01:f7
[ 7157.016011] wifi1: Destroyed STA f8:1e:df:dd:01:f7

What does "unauthorized port" mean?

Looking at the kernel source (net/mac80211/tx.c), this condition is being triggered:

if (unlikely(!ieee80211_vif_is_mesh(&sdata->vif) &&
                     !is_multicast_ether_addr(hdr.addr1) && !authorized &&
                     (cpu_to_be16(ethertype) != sdata->control_port_protocol ||
                      !ether_addr_equal(sdata->vif.addr, skb->data + ETH_ALEN))))

not mesh... check.
not a multicast address... check.
not authorized... check (at least not yet, obviously).
ethertype is not control_port_protocol... SHOULD evaluate to false, because the
STA is actually trying to authenticate via the control port protocol, if I have
understood the documentation correctly. I can't guarantee that, though.
I don't quite understand the last condition, any insights in what it is supposed
to do? sdata->vif.addr sounds like the AP/wifi1 MAC, but I have no idea what
skb->data + ETH_ALEN is. I suspect this sub condition is true, making the whole
condition pass, which it really shouldn't.

Any help with that would be *greatly* appreciated.

BTW, I have previously (on 3.7.x) bisected this problem back to a specific
commit a729cff8ad512 "mac80211: implement wifi TX status". Reverting this commit
fixed those authentication issues, but I can't revert it on top of 3.9.5/6, the
code base is just too different and my amateurish attempts at fixing the merge
conflicts not very successful.

Back then, I suspected the card/hostapd is not getting responses from my
connecting stations, thus dying mid-authentication. Turns out this is only half
true... the card is seeing those frames, but dropping them.

Again, any help is greatly appreciated. :)

Best regards,



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4506 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130618/da4adae7/attachment.bin