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 at gmail.com] On Behalf Of Luis R. > > Rodriguez > > Sent: Wednesday, February 19, 2014 02:15 > > To: Peer, Ilan > > Cc: linux-wireless at vger.kernel.org; wireless-regdb at 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 at 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 -------------- 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/3184ff1a/attachment-0001.sig>
