Hostap-Patch causes strange behavior in scan results

[Vincent]

On 25.07.2017 22:17, Dan Williams wrote:
> On Tue, 2017-07-25 at 21:32 +0200, Vincent wrote:
>> 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... :/
> 
> That makes sense because the 802.11n AP doesn't know anything about
> VHT, because VHT is part of the ac standard.  The client doesn't send
> something it knows the AP doesn't understand.
> 

I thought in a Probe Request Broadcast this information will be sent? :/
Too bad. ^^ So there is no way to find out if a client supports vht when
the station don't?

I will contact the hostapd ubus patch developer and give him my
changes... Nevertheless I think it's a good idea to give the 80211_elems
to the ubus function...

Thanks! :D


> Dan
> 
>> 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/blo
>>>>> b/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-cl
>>> ients/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
>>>
>>
>> _______________________________________________
>> Hostap mailing list
>> Hostap at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/hostap
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap
>