Hi,
I'm running OpenWRT von AR9003 (ath9k, Kernel 3.7.6 with
compat-wireless 2013-01-07 and openwrt patches) cards and have trouble
using vlans.
In the test setup, two STAs connect using WPA (CCMP only) and are
assigned into the same VLAN.
The VLAN device is bridged by hostapd.
With the first STA, everything is fine. Then the second STA connects.
Now hostapd sets it pairwise keys and moves the STA into the
VLAN-WLAN-device (i.e. wlan0_2.501).
Then, the broadcasts start to be encryted with the GTK of the primary
wlan device (i.e. wlan0_2), although wlan0_2.501 is in the bridge.
Hostapd did not change the GTK of any device while this happens. As soon
as the second STA disconnects, the AP encrypts using the original key
again. Sending broadcasts from the STA to the AP works fine, though.
Debug:
I modified hostapd / wpa_supplicants driver_nl80211.c to print the keys
whenever set_key is called, which uses nl80211's ADD_KEY/SET_KEY api.
Further, the kernel was patched to print the key used to encrypt
broadcasts packets by editing net/mac80211/tx.c:ieee80211_tx_h_select_k
in the "else if (is_multicast_ether_addr(hdr->addr1)" section to call
pr_err using the content of key->conf.key.
Logs:
The first STA configures the GTK, sees broadcasts (router
advertisments) incoming. The the second STAs connects and the first STA
no longer receives (decrypted) broadcasts from the AP.
AP Logs are attached. wlan0 has neither ipv4 nor ipv6 address assigned
nor is it in any bridge. wlan0_2.501 is in a bridge. There is only one
bssid (wlan0).
First, you see hostapd assigning GTK to wlan0 and wlan0_2.501. Then
thinks work fine, the wrong key is only used rarely. Then the second STA
connects. A few packets later, the wrong key gets used mostly. Then the
second STA disconnects. Almost immediately the good key is used again.
Any hints?
Thanks alot!
M. Braun
Hi,
tracing mac80211 using debug calls, here come traces for two packages.
The first is fine, the second uses the wrong key.
[ 301.020467] ieee80211_subif_start_xmit:2000 wlan0_2.501: multicast
packet to 33:33:00:00:00:01
[ 301.029146] ieee80211_tx_prepare:1174 wlan0_2.501: multicast packet
to 33:33:00:00:00:01
[ 301.037249] ieee80211_tx:1442 wlan0_2.501: multicast packet to
33:33:00:00:00:01
[ 301.044688] wlan0_2.501: packet to 33:33:00:00:00:01 using key type
CCMP idx 1 len 16 data de 46 7b 31 4f a3 13 8b 88 0b 4e fb 3f 77 d0 18
[ 305.000447] ieee80211_subif_start_xmit:2000 wlan0_2.501: multicast
packet to 33:33:00:00:00:01
[ 305.009136] ieee80211_tx_prepare:1174 wlan0_2.501: multicast packet
to 33:33:00:00:00:01
[ 305.017238] ieee80211_tx:1442 wlan0_2.501: multicast packet to
33:33:00:00:00:01
[ 305.171713] ieee80211_tx_prepare:1174 wlan0: multicast packet to
33:33:00:00:00:01
[ 305.179314] ieee80211_get_buffered_bc:2797 wlan0: multicast packet to
33:33:00:00:00:01
[ 305.187359] wlan0: packet to 33:33:00:00:00:01 using key type CCMP
idx 1 len 16 data ca 85 0f 27 80 78 83 09 49 7a fb c8 c4 dc 45 aa
The number behind the function indicates the line. It looks to me, as
if ps_data buffering is local to the bss, so when dequeing,
ieee80211_get_buffered_bc uses bss vif for tx->sdata instead of the
group interface, which means that vlan support is currently broken in
mac80211?
Any ideas?
Thanks,
M. Braun