> >> 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(). > >> > > > > This make sense (also got a direct answer from our regulatory folks on > > this ... finally ;)) > > Oh wow, are they on the wireless-regdb list? Not sure ... I asked them to join some time ago ... > > >> 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 ? > >> > > > > Our regulatory people said that a similar approach is WIP in the FCC where > they are willing to use a similar relaxation as the beacons hints but with some > limitations such as having at least a number of APs operating on the channel > etc. > > That seems to be biased towards populated spectrum areas. I suspect the > conflict here would be not wanting to trust GO's, but consider Actually no. The concern is more to the increasing number of APs that are bought it one country and then used in some other country, thus possibly violating regulatory. AFAIK, one of the options they are considering is to allow such relaxation if beacon from several (>1) different BSS was received. > this: why not? GO's won't IR unless they have some heuristics like the one > you are adding to determine its OK to IR. Furthermore our own beacon hint > infrastructure in the kernel does check to ensure we don't trust mesh or > IBSS, we ensure its from an ESS, ie WLAN_CAPABILITY_ESS: > > if (res->pub.capability & WLAN_CAPABILITY_ESS) > regulatory_hint_found_beacon(wiphy, channel, gfp); > > BTW I just updated our documentation for this, here: > > http://wireless.kernel.org/en/developers/Regulatory/processing_rules#Bea > con_hints > > Please feel free to socialize this algorithm with the FCC PHBs and other > regulatory folks to see if they can see any loopholes or would prefer any > other considerations or APIs to be extended. I think this is pretty safe and I'd > love to know of issues that people could be concerned over this. > Sure, but as I wrote above, the FCC does not consider a beacon of a single BSS sufficient and would like better assurance that it is safe to enable IR. Will update once I get some answers. > > If its ok with you I prefer to leave things as is for now. > > You mean you'll drop this patch for sure then while we hope a socialization of > our algorithm can be proven as reasonable for Intel to embrace :) ? DSTM ;) ... anyway, I'll drop it since I do not see the benefit and since your argument about indoor not implying IR is true and I'm waiting for answers if this is also allowed another the NO_IR relaxations. Regards, Ilan. ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
