Re: [PATCH v3 6/6] mac80211: Enable initiating radiation on indoor channels

["Luis R. Rodriguez" <mcgrof@do-not-panic.com>]

[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

On Wed, Feb 19, 2014 at 03:28:29PM +0000, Peer, Ilan wrote:
> I'll abandon this change ... 

Wait lets talk about this.

> > -----Original Message-----
> > From: Luis R. Rodriguez [mailto:mcgrof@gmail.com] On Behalf Of Luis R.
> > Rodriguez
> > Sent: Wednesday, February 19, 2014 02:15
> > To: Peer, Ilan
> > Cc: linux-wireless@vger.kernel.org; wireless-regdb@lists.infradead.org
> > Subject: Re: [PATCH v3 6/6] mac80211: Enable initiating radiation on indoor
> > channels
> > 
> > On Mon, Jan 27, 2014 at 12:21:58PM +0200, Ilan Peer wrote:
> > > Allow active scanning and frame injection on channels marked with
> > > IEEE80211_CHAN_NO_IR iff the channel is also marked with
> > > IEEE80211_CHAN_INDOOR_ONLY and the wireless core thinks that it
> > > operates in an indoor environment.
> > >
> > > Signed-off-by: Ilan Peer <ilan.peer@intel.com>
> > 
> > I don't see why being indoor should allow to override the NO-IR flag. I do see
> > however why being indoor should enable to IR if you are IR if you have the
> > indoor flag. Enabling to IR if you are indoor for all NO-IR channels is... pretty
> > permissive I do not see the correlation.
> > 
> 
> Make sense. I did not have such relaxations defined, just thought that
> similar relaxations could also be used in cases of scanning etc. but I
> guess this is not always true. 

The original beacon hint mechanism is very expansive
to all beacons on non 5 GHz DFS channels and non 2.4 channel
12 or 13. If a vendor can possibly not like that beacon hint
implementation as its too permissive (and I don't think it is)
but they do want to trust beacon hints from APs in the case you
are describing then you can enable a new feature flag to
distinguish this. The beacon infrastructure code would then
ignore the regular beacon hints on devices that don't have the
old flag, but would trust this new form of beacon hint. If
a device supported the old all inclusive flag they'd trust
both. You'd have to update the kdocs for the old one, and
likely add a new routine similar to
regulatory_hint_found_beacon().

I'm not sure its worth it though, I'd rather push vendors to
consider first using the regular becaon hint mechanism and
trusting it. Maybe devices that want this new functionality
you are trusting should implicate revising trusting beacon
hint mechanism ?

  Luis

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]