No worries! I've been busy with other stuff as well. > > 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. > 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. Hmm, I understand. Thanks for the input. I will take a look and see what we can do. I have two concerns with the existing implementation in the Linux kernel that I would like to address while doing this. 1) I think it would be best to not assume any specific structure among the regulatory rules. The indoor bands and restrictions are not necessarily a super set (or sub set) of the outdoor restrictions. Regulated frequency bands should also be allowed to overlap, completely or partially. Since regulatory bodies may (and do) specify frequency bands like this in any order and with any restrictions, the implementation should not make any assumptions about the rues. 2) If a rule in the data base has a flag that the kernel does not understand, that rule should be ignored. In this particular case it would have been fine if the kernel did not understand the NO-INDOOR flag, but it should then have ignored the rule instead of using the rule and just ignoring the flag. Hopefully I will have some time next week to work on this. > 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. Sounds good! Johan _______________________________________________ wireless-regdb mailing list wireless-regdb@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/wireless-regdb