OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version openwrt-21.02
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Jan Hoffmann - 03.06.2021
Last edited by Felix Fietkau - 17.06.2021

FS#3852 - 802.11r management messages incorrectly sent without VLAN tag when network uses VLAN-aware bridge

This problem occurs when 802.11r is used together with a network interface that uses a VLAN-aware bridge.

In this case the 802.11r key distribution messages are sent to the bridge without VLAN tag. Effectively this means that they are dropped.

Basic configuration to reproduce:


config interface 'lan'
	option device 'br-lan.10'
	option proto 'static'
	option ipaddr ''
	option netmask ''
	option ip6assign '60'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan1:u*'
	list ports 'lan2:u*'
	list ports 'lan3:u*'
	list ports 'lan4:u*'


config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'psk2+ccmp'
	option key 'mysupersecretpassphrase'

	option mobility_domain 'abcd'
	option ieee80211r '1'
	option nasid '112233445566'
	option ft_psk_generate_local '0'
	option ft_over_ds '1'
	option pmk_r1_push '1'
	list r0kh 'aa:bb:cc:dd:ee:ff,aabbccddeeff,F9EE3F971A72960A66AEA00D0A5894F3'
	list r1kh 'aa:bb:cc:dd:ee:ff,aa:bb:cc:dd:ee:ff,F9EE3F971A72960A66AEA00D0A5894F3'

How to repruduce:

With this configuration a key distribution message is sent to MAC address aa:bb:cc:dd:ee:ff whenever a client connects.

Using tcpdump it is possible to verify the the messages are sent without VLAN tag:

tcpdump -i br-lan "!ip and !ip6 and !arp and !vlan"
tcpdump -i br-lan.10 "!ip and !ip6 and !arp"

The messages should appear with the second command, but instead they only appear for the first one. (The actual messages are sent with Ethertype 0x88b7, but tcpdump refuses to filter for that.)

Closed by  Felix Fietkau
17.06.2021 16:29
Reason for closing:  Fixed
Etienne CHAMPETIER commented on 03.06.2021 23:27

Do not trust tcpdump too much when playing with VLAN, it takes a lot of liberty and behavior change depending on the place of the vlan keyword in the filter (I don't remember the details).
Always display the ethertype with '-e'.
I think you should be able to use 'ether proto 0x88b7'
(can't help with your actual issue sorry ;) )

Jan Hoffmann commented on 04.06.2021 00:05

I actually looked at the data from tcpdump in Wireshark, and there the VLAN tag was missing for the 802.11r messages, but it was there for everything else. So this is an actual issue and not just because of the tcpdump filter.

Thanks for the tip to use "ether proto 0x88b7" and the "-e" option. I accidentally typed "ether type 0x88b7", which results in "tcpdump: 802.11 link-layer types supported only on 802.11"...

So, the best way to check for the issue then is to use the following tcpdump command and look for the VLAN tag (which is not displayed, because it is not there):

tcpdump -i br-lan -e "ether proto 0x88b7"
Jo-Philipp Wich commented on 04.06.2021 09:26

Well I don't see why hostapd should send frames tagged with VLAN 10 in the first place. From hostapd's pov the wireless interface is simply bridged to br-lan. It seems additional configuration would be required to tell hostapd that it is supposed to send frames with a VLAN tag.

What makes you think that your configuration is in fact valid and should work? Is it working like that on other Linux distributions?

Project Manager
Felix Fietkau commented on 04.06.2021 11:51

Please try the latest version from my staging tree at;a=summary

Project Manager
Felix Fietkau commented on 04.06.2021 11:55

Some details about this: hostapd currently assumes that it can communicate with other 802.11r enabled APs on the same bridge that the WLAN interface.
With VLAN filtering enabled, this is no longer true, since different member ports could use different tagging settings.
With your configuration, my hostapd and netifd changes would tell it to listen and send on br-lan.10 instead of br-lan.

Jan Hoffmann commented on 04.06.2021 20:11

With your changes the VLAN tag is set correctly! Reception also works (I can see responses from the other AP when the client is roaming).


Available keyboard shortcuts


Task Details

Task Editing