Hostap-Patch causes strange behavior in scan results

[Dan Williams]

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 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
> > 
> > _______________________________________________
> > 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