Sorry for the slow response. I've been on vacation. On Wed, Jun 30, 2021 at 12:23:57AM +0200, Johan Almbladh wrote: > On Tue, Jun 8, 2021 at 2:57 PM Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote: > > > > On Wed, Jun 02, 2021 at 03:05:56PM +0200, Johan Almbladh wrote: > > > The parser dbparse.py and nl80211.h understand the NO-INDOOR keyword, > > > but I cannot find any occurrences of it in db.txt. Furthermore, as the > > > reg domain rules are processed by cfg80211, the supported frequencies > > > are annotated accordingly and NO-OUTDOOR is mapped to the flag > > > NL80211_FREQUENCY_ATTR_INDOOR_ONLY. There is however no equivalent for > > > the NO-INDOOR annotation. > > > > Correct, it is defined but completely unused. I suspect this is because > > restrictions have been more common on outdoor use rather than indoor. > > Yes, that makes sense. > > > In principle we could have separate rules for indoor vs outdoor use, but > > the regulatory support in the kernel can't currently deal with that. So > > we would first need to add support in the kernel, but this would require > > care to ensure older kernels can continue to use the regulatory > > database. > > I have been looking into this a bit. From what I can see in the > regulatory support code in the Linux kernel, the outdoor environment > mode could be handled by the same mechanism as indoor mode uses today. > I can put together a patch set for review on the linux-wireless list. There's a more fundamental problem to solve though. To my recollection the kernel does not support duplicate rules for a given channel with differing constraints. > Backwards compatibility is more difficult. The problem I see is that > the current kernel ignores the NO-INDOOR flag. If we add a band with > this flag set in db.txt, older kernels will incorrectly use channels > in that band. Solving this depends on where the compatibility is > expected. I understand that db.txt must be portable and compatible > with older kernels. From this file a binary database file is generated > by the db2bin.py script. Does the binary database also need to be > compatible with older kernels? If not, one solution could be to let > db2bin.py take an an argument to include (or not) NO-INDOOR bands in > the binary output. We could also bump the file version number so that > older kernels won't accidentally use a binary database generated for a > kernel with NO-INDOOR support. Otherwise, I see no other way than > somehow putting the NO-INDOOR bands in a part of the binary file where > older kernels cannot "see" it. If they cannot handle duplicate rules for the same channel, there may be some way to take advantage of the implementation to make sure they end up using the rule we want them to use. I'm not sure without refamiliarizing myself with the code. > There is also the CRDA tool to consider for backwards compatibility. CRDA only suports the older db format, and we can just limit that database to having one of the rules for a given range, which we could specify to be the rule without NO-INDOOR. Seth _______________________________________________ wireless-regdb mailing list wireless-regdb@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/wireless-regdb
