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 ;) )
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"
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?
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.