New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#3852 - 802.11r management messages incorrectly sent without VLAN tag when network uses VLAN-aware bridge #8875
Comments
champtar: 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). |
janhoffmann: 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): |
jow-: 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? |
nbd: Please try the latest version from my staging tree at https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary |
nbd: 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. |
janhoffmann: 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). |
janhoffmann:
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:
/etc/config/network:
config interface 'lan'
option device 'br-lan.10'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
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*'
/etc/config/wireless:
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'psk2+ccmp'
option key 'mysupersecretpassphrase'
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.)
The text was updated successfully, but these errors were encountered: