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

[Jouni Malinen]

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

> * 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 also
>   concurrently connected to BSS on the same channel on the 2 GHz band or to
>   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?

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

> * 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 change
>   in the regulatory settings.

CSA support is now included. Would you happen to have updated version
for this P2P GO case as well?

> * In case that Multi Concurrent Channel (MCC) is supported, add support for
>   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..

> * To improve the frequency selection during P2P GO channel changes, the patch
>   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.

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

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

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

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

-- 
Jouni Malinen                                            PGP id EFC895FA