[wireless-regdb] [PATCH v3 3/6] cfg80211: Enable GO operation on additional channels

[Luis R. Rodriguez]

On Wed, Feb 19, 2014 at 02:52:13PM +0000, Peer, Ilan wrote:
> > Ilan, also extend the above with language similar to the one I provided on the
> > cellular base station hints if you ended up adding a device feature capability.
> > 
> 
> You mean specify that this option is enabled, drivers can still use
> the device specific flags to disable this?

Yeap! In particular its important to make it clear that
enabling this option isn't enough to get enable this feature,
this option will only be usable on device drivers that have
support for this feature.

> > > +
> > > +		if (!other_chan)
> > > +			continue;
> > > +
> > > +		if (chan == other_chan)
> > > +			return true;
> > 
> > This seems to me to indicate that we have allowed here daisy chaining / trust
> > on another GO who also trusted its AP. That is, we are leaving it up to the
> > kernel for the above few lines of code to check if the STA was associated to
> > an AP that had DFS support. How do we know the AP the STA was associated
> > to was not another GO that ran through this permissive check? Is the FCC
> > happy with that?
> > 
> 
> This verification should be done by user space, i.e., if the station
> is a legacy client associated to a GO, then wpa_supplicant should not
> allow the GO_CONCURRENT relaxation. In addition, a GO instantiated on
> channel based on this relaxation should not allow connection from
> legacy clients ... again this should be enforced by user space. System
> wise this should adhere to the FCC expectations and prevent daisy
> chaining.

Wow this is a hugely important piece of information, please toss it into
the documentation both kconfig and wiki (once accepted upstream). As for
references to userspace you can mention supplicant (wpa_supplicant).

> > Also to be clear, you check for IEEE80211_CHAN_GO_CONCURRENT only on
> > the caller's channel, not the STA's device, is that OK ? Lets
> > consider the case case of two different types of interfaces on the
> > same system. I am aware of at least one 802.11 AP company selling
> > devices with one 802.11 vendor as the AP and another as the STA. I
> > don't consider this rare anymore now, as such please think about
> > this case as well.
> 
> The property is of the channel so this should suffice. Overall, I
> think that the FCC definition rules are centered on the UNII bands, so
> the rules mandated for a given channel in a specific channel should
> also hold to other channels in the same UNII band. Ultimately, I would
> expect all channels in the same UNII band to share the same settings.

OK.

> The iteration in this case is over all the interfaces of the same
> registered device

This feature seems limited then. Can this be extended to relay on the
information from any other registered device? I suspect folks may soon
enter bug reports for this otherwise. That carefulness here seems to
be an implementation preference, but is it a hard requirement? If not
then please considering revising all registered devices.

  Luis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/wireless-regdb/attachments/20140219/8b53040d/attachment.sig>