I'm a bit confused what the meaning of the ht and vht flags in the
I thought they say me if the station (client) supports ht or vht in general. After giving me feedback if the ap supports ht/vht I realized that this is not the case:
So VHT flag is only set if vht is supported on ap AND on client side. This pictures shows a client (supporting 802.11ac) that is connected to different bssids...
Is this a bug?
There can I get the information if the client supports vht although the ap doesn't support it?
Looking at sta_info I would assume that I can get this iformation from ht_capabilities and vht_capabilities...
But I have no idea what flags I have to check... And can't find the answer.
- If the AP doesn't support ht no information about the client ht capabilities will be safed
- If the AP doesn't support vht no information about the client vht capabilities will be safed
To findout if the client supports vht I will have too look in the [association request] (https://mrncciew.com/2014/10/28/802-11-mgmt-association-reqresponse). (not sure if this is correct...)
Or I will write a patch that saves the information although there no support. Hope this will not screw up the entire hostapd logic...
I think the patch would be editing the
add_associated_sta (or more files... would have to go through all 80211AC defines...)
I think the best way I will try is to use the probe request somehow and get the information from mgmt_frame.
So the probe request solution would be acceptable. (even if only the stations who supports ht and vht will receive this informations...)
Although the probe request contains the needed informations, hostapd doesn't support this informations.
Hostapd mgmt entry for probe requests:
Ok. I found the solution...
Only look at:
Other changes are irrelevant.
I can get HT and VHT Information in the probe request even the AP doesn't support HT and VHT.
Tested with WDR4300 V1. (only 802.11n)
And Acer C7 v2 (802.11ac...)
The patch causes strange behavior in scan results. -.-
So solution is wrong...