On Wed, 2017-07-26 at 11:23 +0200, Vincent wrote: > > 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? Looking further into the Linux kernel mac80211 implementation, I appear to be wrong. mac80211-based drivers will always add the HT and VHT IEs to a probe request if the driver indicates that it supports HT/VHT on a given band. Are you sure that your parsing code was correct, eg that the HT/VHT IE was actually in the probe request but that your code was not finding it correctly? Dan > 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-ge > > > > t-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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
