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