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@xxxxxxxxxxxxxxxxxxx >>> http://lists.infradead.org/mailman/listinfo/hostap >>> >> >> _______________________________________________ >> Hostap mailing list >> Hostap@xxxxxxxxxxxxxxxxxxx >> http://lists.infradead.org/mailman/listinfo/hostap > > _______________________________________________ > Hostap mailing list > Hostap@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/hostap > _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
