VLAN support broken

VLAN support broken

[michael-dev]

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

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

[-- Attachment #2: ap-log-20130212.txt.xz --]
[-- Type: application/octet-stream, Size: 5712 bytes --]

[BUG] mac80211 queues per bss breaking vlan support

[michael-dev]

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