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

[Jouni Malinen]

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#Concurrent_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
- 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)

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

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

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. 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)..

-- 
Jouni Malinen                                            PGP id EFC895FA