RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

[Peng Xu]

> Is a new version of this patch hinging only on this? We'd love to have a 
> fixed-
> up one :-)

The new version covers the use cases mentioned by Jouni as the OUIs of the 
vendor commands 
has the format of OUI + type + subtype. For other format of vendor commands, 
they will be treated
as different vendor commands and are added in the new IE as well. 

Jouni, could you chime in to explain your view on this?

Thanks,
Peng

RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

[Peng Xu]

> On Tue, Nov 14, 2017 at 02:39:31PM +0000, Peng Xu wrote:
> > > I'm not even sure why this is necessary anyway though, do we really
> > > think vendors will expect to be able to put vendor IEs inside the
> > > subelements and override the ones outside?
> > >
> > > Is there even any point for the WFA ones? It seems WMM really ought
> > > to be the same for all anyway, for example.
> >
> > I don't have any use case for such scenario. If vendor elements are
> > unlikely to be present in subelement, this logic can be removed.
> 
> As far as WMM element is concerned, I'd note that IEEE 802.11 standard does
> not list EDCA Parameter Set element as one of the items that has to be same
> for all the BSSs in a multiple BSSID set and as such, I'd consider it to be
> allowed behavior for an AP to advertise different WMM parameters for
> different nontransmitted BSSIDs.
> 
> As far as other vendor specific elements are concerned, there could certainly
> be use cases for using different values for WPA element, Hotspot 2.0
> element, MBO/OCE element.
> 
Hi Jouni,
As you pointed out the use cases for having vendor elements in MBSSID 
subelements, what is
your suggestion to identify and process the vendor elements? 

Thanks,
Peng

RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

[Peng Xu]

> 
> Right, not really.
> 
> I'm not even sure why this is necessary anyway though, do we really think
> vendors will expect to be able to put vendor IEs inside the subelements and
> override the ones outside?
> 
> Is there even any point for the WFA ones? It seems WMM really ought to be
> the same for all anyway, for example.
> 

I don't have any use case for such scenario. If vendor elements are unlikely to
be present in subelement, this logic can be removed.

Thanks,
Peng

RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

[Peng Xu]

> >
> > It is OUI + type + subTye.
> 
> Ah, right, type/subtype.
> 
> Still, this is problematic, because there's nothing that says that the vendor 
> IE
> must have OUI + type + subtype, the spec only says OUI + vendor specific
> data.
> 
> This may be right for the WFA/Microsoft OUI, but not necessary anything
> else?
> 

Right, I only considered the most common cases since I did not find a generic 
way to compare two vendor elements. Any suggestion?

Thanks,
Peng

RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

[Peng Xu]

> 
> > +   if (tmp_old[0] == WLAN_EID_VENDOR_SPECIFIC) {
> > +   if (!memcmp(tmp_old + 2, tmp + 2, 5)) {
> > +   /* same vendor ie, copy from new ie
> */
> > +   memcpy(pos, tmp, tmp[1] + 2);
> > +   pos += tmp[1] + 2;
> > +   } else {
> > +   memcpy(pos, tmp_old, tmp_old[1] +
> 2);
> > +   pos += tmp_old[1] + 2;
> 
> This seems really strange. What's 5? Should it be 4, so you have
> OUI+subelement ID?
> 

It is OUI + type + subTye.


Thanks,
Peng