Hostap-Patch causes strange behavior in scan results

[Vincent]

I tried and what I actually want isn't working.
So when a 802.11ac devices sends an probe request to 802.11n AP the vht
capabilities are null... :/

But now I can use the information if they can use vht together ...

On 25.07.2017 19:46, Vincent wrote:
> Thaaaaaanks for your answer! :)
> 
> On 25.07.2017 18:55, Dan Williams wrote:
>> On Tue, 2017-07-25 at 18:07 +0200, Vincent wrote:
>>> Hi,
>>> I wrote a patch to give me feedback about ht and vht capabilities in
>>> probe requests. (LEDE)
>>>
>>> https://github.com/berlin-open-wireless-lab/patches-pending/blob/mast
>>> er/patches/hostap_patches/601-probe-mgmt.patch
>>>
>>> I'm just adding
>>>
>>> +			struct ieee80211_ht_capabilities ht_capab;
>>> +			struct ieee80211_vht_capabilities vht_capab;
>>
>> That's the problem.  This struct describes the over-the-air probe
>> response (or the beacon, can't tell which you added these to) from the
>> AP.  The only fixed fields are the ones at the start of the struct
>> (timestamp, beacon_int, capab_info).  The rest are information elements
>> that can be given in any order by the AP.
> 
> Ahhhh ok. ^^
> 
>> Which includes the HT/VHT fields that you're trying to add as fixed
>> fields. They can appear anywhere in the rest of the frame, but you're
>> assuming they are appearing right after the capability info.  Which
>> they don't, as you've found out :)
>>
>> You'll need to parse the actual probe response variable info (pointed
>> to by the 'variable' member) as information elements and find the
>> HT/VHT IEs and then parse those.  Or something.
> 
> Ok! :)
> I was confused that the probe_req entry was deleted and is now a beacon...
> So I will just do something like this in handle_probe_req(...):
> 
> if (ieee802_11_parse_elems(mgmt->u.beacon.variable,
> 	len - (mgmt->u.beacon.variable - data), &elems, 0) ==  ParseFailed)
> 
> And then everything I need should be contained in elems?
> 
> Or wait. This is already done in this function with
> 
> if (ieee802_11_parse_elems(ie, ie_len, &elems, 0) == ParseFailed) {
> 	wpa_printf(MSG_DEBUG, "Could not parse ProbeReq from "
> MACSTR,MAC2STR(mgmt->sa));
> return;
> }
> 
> So elems should already contain the ht/vht fields.
> So I will try to give ieee802_11_elems to the ubus function. :D
> 
>> But what are you actually trying to do?  If the AP is sending the
>> HT/VHT IEs, they will already appear in the probe response frame, so
>> whatever is parsing that ieee80211_mgmt struct that you've pasted into
>> your mail either isn't finding those IEs, or doesn't have code to parse
>> them.
> 
> I'm trying to do build some decentralized wireless controller.
> I would like to know if a client supports ht and vht. This information
> is already contained in the probe request.
> So I can calculate if another ap is "better for the client".
> 
> I described it here:
> https://forum.lede-project.org/t/hostapd-ht-and-vht-flags-in-get-clients/5128
> 
> Thanks a lot!
> I will instantly try to build a new patch! :D
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap
>