[PATCH v2 00/23] Support for new regulatory flags and P2P GO channel

[Peer, Ilan]

Hi Jouni,

My replies are below, and I also requested Noam to further clarify any more questions/concerns that you might have.

I started reviewing the rebased patch set, but will finish this only later tonight.

Thanks again,

Ilan.

> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Monday, March 30, 2015 21:22
> To: Peer, Ilan
> Cc: hostap at lists.shmoo.com; Ginsburg, Noam
> Subject: Re: [PATCH v2 00/23] Support for new regulatory flags and P2P GO
> channel
> 
> On Sun, Oct 26, 2014 at 06:05:28PM +0000, Peer, Ilan wrote:
> > The following might also help:
> > http://wireless.kernel.org/en/developers/Regulatory/processing_rules#C
> > oncurrent_GO_Relaxation
> 
> Indeed. That's good to keep as a reference here. I think there are going to be
> two main items that will require clear definition:
> - how to determine that the device is indoors

We tried to do so using the WPS Device type and subtype of the peer. I understand that this might not be strong enough, but AFAIK from our regulatory people these guidelines are acceptable. I also wanted to add some control interface or configuration option that could be used to indicate to the wpa_supplicant that it is operating in indoor environment, but did not do so since currently we did not have any mechanism in the platform that can define this (I also do not this is the proper way to indicate this, other than for testing purposes). We intend add this once we have a platform component that can clearly deduce indoor.

> - how to avoid chaining authorization in a way that works with all peer
>   implementations (i.e., do not assume this specific wpa_supplicant
>   implementation is used by the peer)
> 

I tried to address this in the patch set, assuming that all patches are taken or none. 

> > The main point here, is that the GO_CONCURRENT relaxation allows to
> ignore the NO_IR setting in case that we have a station that is already
> associated to some AP, and is communicating with it. This means that the
> device is already transmitting on the channel (or same UNII band) and thus as
> the device is already transmitting on the channel it seems permissible to also
> allow P2P GO functionality on this channel.
> 
> This sounds somewhat clear, but just today, there was a proposed
> cfg80211 patch to extend this to a state where the BSS association does not
> exist anymore. How would this work with that type of relaxation of the rules?
> This is pushing the rules pretty far at least as far as FCC is concerned..
> 

As before as far as I understand this was acceptable by the FCC, assuming that as long as the channel is not marked as indoor only, if the P2P GO was started while there was an associated station interface, then this means that there was an AP operating on this channel in the near environment, i.e., the device did not switch to another country.

> > When a station interface is connected to a GO that is instantiated due to the
> GO Concurrent relaxation, it can enable the same relaxation on its device,
> instantiating a P2P GO on the same channel and thus allow a 3rd station
> interface to connect to the P2P GO and similarly allow additional station
> interfaces to connect to P2P GOs created due to the relaxation. The end
> result might be a P2P GO initiating radiation far from the original AP that
> allowed it. Thus, the above mechanisms are added to limit the number of hops
> the relaxation allows.
> 
> Will this work if any of the peer devices uses a different mechanism of
> avoiding multiple hops? Some of the limitations on legacy STA interface
> looked a bit unfortunate and specific to this implementation choice (i.e.,
> depending on GO preventing that connection rather than local STA
> interface?).
> 

I tried to handle this in patch #10 in your rebase version, which does not allow station interfaces to connect to the P2P GO in case that it is operating on and indoor only channel, so this would leave the control over the chaining in the local device. Do you think that additional enforcement is required?

> > I was not sure about this as well. The main use case was to enable
> connection with Miracast adapters that might support channels that are
> generally not allowed for use by the local device but allow usage in case the
> device is operating in an indoor environment. Identifying this by WPS Device
> type to identify miracast adapters was one of the options we considered.
> Maybe I can make this optional in configuration?
> 
> I would not trust _any_ information advertised by a peer device. I don't see
> how this type of assume-we-are-inside-if-peer-advertises-dev-type-X
> is going to meet any of the FCC expectations. If this design is the requirement
> for this full patch set functionality, I may not be able to apply this. Is there a
> clear subset of patches that does not depend on this peer-telling-when-_we_-
> are-inside concept?
> 

Maybe Noam would be able to elaborate on this more (as I tend to agree with you ..). I think that removing #6 and #7 in your rebased version should do the work (and maybe some cleanup in the following ones). I can handle this if you want.

> I don't see why a Miracast device would be expected to be indoors in the first
> place. Surely there can be outside venues that provide displays with Miracast
> support. And even if we assume that the peer device is inside, how would that
> in any way indicate that we are inside if we can associate with it?
> 
> > > > Andrei Otcheretianski (2):
> > > >   wpa_supplicant: Add more chan/freq conversion functions
> > >
> > > This seems to remove support for 4.9 GHz band in
> > > ieee80211_freq_to_chan().
> >
> > The original patch is too old. Would u like me to send an updated version?
> 
> No need for that anymore, i.e., the rebased version from today covers this.
> 

Sure.

> > Sure. BTW, these relaxation are driven by FCC but some other regulatory
> bodies like ETSI are following the same. For example, although ETSI is not using
> the UNII terminology, it also defines sub bands that share the same regulatory
> definitions/restrictions.
> 
> Can you point me to anything that any of the regulators would accept
> something like the peer's WPS device type? The proposed rules from FCC
> seem to point to a completely different direction (don't accept anything
> receive over 802.11 from any device to determine where you are)..
> 

Noam can probably better answer this.

Ilan.