Hostap-Patch causes strange behavior in scan results

Dan Williams dcbw at redhat.com
Tue Jul 25 13:17:11 PDT 2017


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.

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



More information about the Hostap mailing list