[PATCH v2 00/23] Support for new regulatory flags and P2P GO channel
Sun Oct 26 11:05:28 PDT 2014
Thanks for reviewing this set. I tried answering your comment below.
The following might also help:
Also adding Noam, who came with requirements/definitions that evolved into this patch set.
> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Sunday, October 26, 2014 01:52
> To: Peer, Ilan
> Cc: hostap at lists.shmoo.com
> Subject: Re: [PATCH v2 00/23] Support for new regulatory flags and P2P GO
> On Mon, Jul 07, 2014 at 02:20:53PM +0300, Ilan Peer wrote:
> > The patch add support for the following features:
> I'm finally trying to find enough time to go through this set. As an initial step, I
> rebased this on top of the current master branch and applied the clear cases
> for which I had no questions (or dependencies on commits with open
> > * Support for channel regulatory flag GO CONCURRENT which allows GO
> > instantiation on such a channel even if the channel setting do not allow
> > initiating radiation on the channel. A channel marked with the
> > GO CONCURRENT flag can be used for GO instantiation iff the device is
> > concurrently connected to BSS on the same channel on the 2 GHz band or
> > a channel in the same UNII band (on the 5 GHz band) and radar is not set.
> > The main motivation for this relaxation is that such channels can be used
> > for GO operation, since the device is under the guidance of some other
> > master device that is assumed to be reliable in the context of regulatory
> > adherence.
> That "assumed to be reliable" gets difficult to define and as such,
> implement.. Is there some specific set of rules that are expected to be
> addressed here?
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.
> > * In order to prevent daisy chaining scenarios, the above relaxation is not
> > allowed when the station interface is connected to a GO. For the similar
> > reason, if a GO is instantiated on a channel due to the GO CONCURRENT
> > relaxation, it should not allow legacy clients connection to it.
> Could you please provide some more details on why this is needed and what
> this has to do with legacy clients?
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.
> > * Add support for changing the P2P GO operating channel (at this point
> > without CSA which will be addressed in a different patch set) due to a
> > in the regulatory settings.
> CSA support is now included. Would you happen to have updated version for
> this P2P GO case as well?
If you recall, you requested to split the original patch set which included the channel switch support, and suggested I repost that CS patches once the review process of this patch set is done. The patches are ready, so If you want, I can submit them regardless.
> > * In case that Multi Concurrent Channel (MCC) is supported, add support
> > changing the P2P GO's operating channel due to policy consideration, that
> > might prefer operating in single channel mode instead operating in
> > multiple channels concurrently.
> Didn't get this far yet in the review..
Sorry for making this so long :)
> > * To improve the frequency selection during P2P GO channel changes, the
> > set add support for saving the group common frequencies, and using this
> > information when switching a channel, so that the selected frequency/
> > channel would be one that can be used by all of the group members.
> This looked fine in general and I pulled in the first two patches for this now.
> > * Support for INDOOR regulatory flag in the context of P2P. Generally, a
> > P2P GO/Client operation on indoor channels is not allowed unless there is
> > some knowledge that the device is operating in indoor environment. The
> > patch set allows support for using such channels if the peer device is
> > identified as a non-mobile device.
> This is another of those complex areas.. What rules are you trying to meet
> with this design? I'm not sure I would trust either the WPS Device Type or
> that the GO and P2P Client would necessarily be close to each other, i.e., P2P
> Client may be outdoors even when associated with a GO that is indoors.
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?
> > Andrei Otcheretianski (2):
> > wpa_supplicant: Add more chan/freq conversion functions
> This seems to remove support for 4.9 GHz band in
The original patch is too old. Would u like me to send an updated version?
> > wpa_supplicant/hostapd: Add awareness of CSA support
> A separate variable for this purpose looks unnecessary. Driver flags are
> already available in hapd->drv_flags and hapd->drv_flags.
> > Ilan Peer (20):
> > wpa_supplicant: use the 'no_ir' notation
> > driver.h: add indoor only and go concurrent flags
> > nl80211: get indoor only and go concurrent attributes
> Applied those three (with the last two merged into a single commit).
> > P2P: allow additional operating channels for P2P GO and client
> For this, I'd need to understand the points mentioned above better and
> check whether this matches other interpretations of what the rules are at
> least as far as FCC is concerned.
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.
> > nl80211: clear beacon_set when deleting a beacon
> > P2P: Save group common frequencies
> > P2P: Save group common frequencies in invitation result
> > WPS: Add missing device types
> Applied those four.
> > P2P: deduce if a device is indoor based on the device category
> This is the part that I don't really see as sufficient determination for being
> > P2P: Do not allow GO Concurrent relaxation
> > P2P: Disallow legacy client connection on indoor channel
> I don't think I fully understood how these would prevent chaining and how
> legacy station vs. P2P Client makes much of a difference for that.
Hope that the above would clarify this.
> Jouni Malinen PGP id EFC895FA
More information about the Hostap