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

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

[Mihai Moldovan]

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 

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

[Mihai Moldovan]

* On 18.06.2013 11:25 PM, Mihai Moldovan wrote:
> [...]
> 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))))

Fugly print-debugged this statement, and I'm heavily confused.

The subcondition "cpu_to_be16(ethertype) != sdata->control_port_protocol" is
true for me!

Thus, I checked "sdata->control_port_protocol", which is ETH_P_PAE (0x888E)...
i.e., 802.1X. Great for WiFi authentication.

"ethertype", on the other hand, is ETH_P_DDCMP (0x0006) which left me totally
confused! How is this possible? ethertype should ideally also be ETH_P_PAE,
definitely not some only internally used DECnet port protocol.

Yes, CONFIG_DECNET is turned on in my kernel config, but I'm not (actively) even
using DECnet.

ethertype is set from the socket buffer's data (ethertype = (skb->data[12] << 8)
| skb->data[13]), but what is generating this packet? If the ethertype fetching
is actually correct in net/mac80211/tx.c, what would ever set it to 0x0006?

CCing Johannes Berg, as git is "blaming" him for those line(s) (originally Jiri
Benc, but I haven't seen list posts in a while, assuming he's not maintaining
anymore.)

-------------- 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/20130621/f361827a/attachment.bin 

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

[Johannes Berg]

On Fri, 2013-06-21 at 05:12 +0200, Mihai Moldovan wrote:
> * On 18.06.2013 11:25 PM, Mihai Moldovan wrote:
> > [...]
> > 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))))
> 
> Fugly print-debugged this statement, and I'm heavily confused.
> 
> The subcondition "cpu_to_be16(ethertype) != sdata->control_port_protocol" is
> true for me!
> 
> Thus, I checked "sdata->control_port_protocol", which is ETH_P_PAE (0x888E)...
> i.e., 802.1X. Great for WiFi authentication.
> 
> "ethertype", on the other hand, is ETH_P_DDCMP (0x0006) which left me totally
> confused! How is this possible? ethertype should ideally also be ETH_P_PAE,
> definitely not some only internally used DECnet port protocol.

http://en.wikipedia.org/wiki/EtherType

Anyway, this might just be some random bridging frames.

johannes