[wireless-regdb] Different indoor and and outdoor constraints for the same band

[wireless-regdb] Different indoor and and outdoor constraints for the same band

[Johan Almbladh]

I noticed that the rule for ID (Indonesia) looks like it only allows
for indoor operation.

country ID: DFS-JP
        # ref: https://jdih.kominfo.go.id/produk_hukum/view/id/676/t/peraturan+menteri+komunikasi+dan+informatika+nomor+1+tahun+2019+tanggal+24+april+2019
        (2400 - 2483.5 @ 40), (500 mW), NO-OUTDOOR
        (5150 - 5350 @ 80), (200 mW), NO-OUTDOOR
        (5725 - 5825 @ 80), (200 mW), NO-OUTDOOR

However, the referenced document seems to allow frequencies in the 2.4
and 5.8 GHz bands for outdoor use as well, but with a different power
and channel width constraints. Therefore I propose the following
additional rules for the ID regulatory domain.

        (2400 - 2483.5 @ 20), (4 W), NO-INDOOR
        (5725 - 5825 @ 20), (4 W), NO-INDOOR

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.

Should same frequency band, or parts of it, be specified multiple
times with the NO-INDOOR and NO-OUTDOOR annotations as proposed? If
not, how should cases like this otherwise be handled, where the indoor
constraints are not a superset of the outdoor constraints?

Thanks,
Johan

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [wireless-regdb] Different indoor and and outdoor constraints for the same band

[Seth Forshee]

On Wed, Jun 02, 2021 at 03:05:56PM +0200, Johan Almbladh wrote:
> I noticed that the rule for ID (Indonesia) looks like it only allows
> for indoor operation.
> 
> country ID: DFS-JP
>         # ref: https://jdih.kominfo.go.id/produk_hukum/view/id/676/t/peraturan+menteri+komunikasi+dan+informatika+nomor+1+tahun+2019+tanggal+24+april+2019
>         (2400 - 2483.5 @ 40), (500 mW), NO-OUTDOOR
>         (5150 - 5350 @ 80), (200 mW), NO-OUTDOOR
>         (5725 - 5825 @ 80), (200 mW), NO-OUTDOOR
> 
> However, the referenced document seems to allow frequencies in the 2.4
> and 5.8 GHz bands for outdoor use as well, but with a different power
> and channel width constraints. Therefore I propose the following
> additional rules for the ID regulatory domain.
> 
>         (2400 - 2483.5 @ 20), (4 W), NO-INDOOR
>         (5725 - 5825 @ 20), (4 W), NO-INDOOR
> 
> 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.

> Should same frequency band, or parts of it, be specified multiple
> times with the NO-INDOOR and NO-OUTDOOR annotations as proposed? If
> not, how should cases like this otherwise be handled, where the indoor
> constraints are not a superset of the outdoor constraints?

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.

Seth

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [wireless-regdb] Different indoor and and outdoor constraints for the same band

[Johan Almbladh]

On Tue, Jun 8, 2021 at 2:57 PM Seth Forshee <seth.forshee@canonical.com> 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.

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.

There is also the CRDA tool to consider for backwards compatibility.

Let me know what you think.
Johan

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [wireless-regdb] Different indoor and and outdoor constraints for the same band

[Seth Forshee]

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@canonical.com> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [wireless-regdb] Different indoor and and outdoor constraints for the same band

[Johan Almbladh]

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb