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
