[wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Johannes Berg]

From: Johannes Berg <johannes.berg@intel.com>

When in world roaming mode, allow 40 MHz to be used
on channels 12 and 13 so that an AP that is, e.g.,
using HT40+ on channel 9 (in the UK) can be used.

Reported-by: Eddie Chapman <eddie@ehuk.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
Will also send a corresponding patch for the in-kernel definition.

 db.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/db.txt b/db.txt
index 4c54543..5318505 100644
--- a/db.txt
+++ b/db.txt
@@ -1,8 +1,8 @@
 # This is the world regulatory domain
 country 00:
 	(2402 - 2472 @ 40), (3, 20)
-        # Channel 12 - 13. No HT40 channel fits here
-        (2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
+        # Channel 12 - 13.
+        (2457 - 2482 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
         # Channel 14. Only JP enables this and for 802.11b only
         (2474 - 2494 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS, NO-OFDM
         # Channel 36 - 48
-- 
1.8.0




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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Johannes Berg]

On Mon, 2012-11-12 at 10:51 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
> 
> When in world roaming mode, allow 40 MHz to be used
> on channels 12 and 13 so that an AP that is, e.g.,
> using HT40+ on channel 9 (in the UK) can be used.

Ping?
johannes


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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[John W. Linville]

On Tue, Dec 04, 2012 at 03:52:41PM +0100, Johannes Berg wrote:
> On Mon, 2012-11-12 at 10:51 +0100, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> > 
> > When in world roaming mode, allow 40 MHz to be used
> > on channels 12 and 13 so that an AP that is, e.g.,
> > using HT40+ on channel 9 (in the UK) can be used.
> 
> Ping?
> johannes

Sorry, I need to give the wireless-regdb tree some love.  If no one
objects I'll try to get this merged in the next day or two.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Johannes Berg]

On Tue, 2012-12-04 at 11:11 -0500, John W. Linville wrote:
> On Tue, Dec 04, 2012 at 03:52:41PM +0100, Johannes Berg wrote:
> > On Mon, 2012-11-12 at 10:51 +0100, Johannes Berg wrote:
> > > From: Johannes Berg <johannes.berg@intel.com>
> > > 
> > > When in world roaming mode, allow 40 MHz to be used
> > > on channels 12 and 13 so that an AP that is, e.g.,
> > > using HT40+ on channel 9 (in the UK) can be used.
> > 
> > Ping?
> > johannes
> 
> Sorry, I need to give the wireless-regdb tree some love.  If no one
> objects I'll try to get this merged in the next day or two.

Ping again -- the discussion was a bit confusing but we did exactly this
change in the kernel so should do it here as well.

johannes


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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[John W. Linville]

On Tue, Feb 12, 2013 at 12:29:07PM +0100, Johannes Berg wrote:
> On Tue, 2012-12-04 at 11:11 -0500, John W. Linville wrote:
> > On Tue, Dec 04, 2012 at 03:52:41PM +0100, Johannes Berg wrote:
> > > On Mon, 2012-11-12 at 10:51 +0100, Johannes Berg wrote:
> > > > From: Johannes Berg <johannes.berg@intel.com>
> > > > 
> > > > When in world roaming mode, allow 40 MHz to be used
> > > > on channels 12 and 13 so that an AP that is, e.g.,
> > > > using HT40+ on channel 9 (in the UK) can be used.
> > > 
> > > Ping?
> > > johannes
> > 
> > Sorry, I need to give the wireless-regdb tree some love.  If no one
> > objects I'll try to get this merged in the next day or two.
> 
> Ping again -- the discussion was a bit confusing but we did exactly this
> change in the kernel so should do it here as well.

OK, I merged this and the Spain patches.  I pushed the tarball through
kup to kernel.org.

I'm guessing that there aren't going to be any automatic release
messages anymore?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Johannes Berg]

On Tue, 2013-02-12 at 13:24 -0500, John W. Linville wrote:

> I'm guessing that there aren't going to be any automatic release
> messages anymore?

Yeah since kernel.org requires them being signed, there won't be; I
disabled the scripts for the tarballs on wireless.kernel.org.

johannes


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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Johannes Berg]

On Mon, 2012-11-12 at 10:51 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
> 
> When in world roaming mode, allow 40 MHz to be used
> on channels 12 and 13 so that an AP that is, e.g.,
> using HT40+ on channel 9 (in the UK) can be used.

Well, hold on.. this can't possibly work now :(

This is what happens when Luis and I disagree ...

I thought the bandwidth in a given section means the bandwidth that can
be used from this section, Luis implemented it to mean that a channel
overlapping any part of that section can only use that much bandwidth.

Note sure which was intended?

johannes


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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Luis R. Rodriguez]

On Tue, Dec 4, 2012 at 9:48 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2012-11-12 at 10:51 +0100, Johannes Berg wrote:
>> From: Johannes Berg <johannes.berg@intel.com>
>>
>> When in world roaming mode, allow 40 MHz to be used
>> on channels 12 and 13 so that an AP that is, e.g.,
>> using HT40+ on channel 9 (in the UK) can be used.
>
> Well, hold on.. this can't possibly work now :(
>
> This is what happens when Luis and I disagree ...
>
> I thought the bandwidth in a given section means the bandwidth that can
> be used from this section,

No, indeed that was the objective.

> Luis implemented it to mean that a channel
> overlapping any part of that section can only use that much bandwidth.

This was a side effect of the checks we have in place, it was not expected.

> Note sure which was intended?

Technically speaking the math should be possible to figure out to
enable HT40 or not based on peer channels and although that was
assumed the user reported it not allowing HT40 due to the peer
channels not allowing HT40. I took your patch as an assumption that
was not possible.

  Luis

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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Johannes Berg]

On Tue, 2012-12-04 at 10:13 -0800, Luis R. Rodriguez wrote:

> >> When in world roaming mode, allow 40 MHz to be used
> >> on channels 12 and 13 so that an AP that is, e.g.,
> >> using HT40+ on channel 9 (in the UK) can be used.
> >
> > Well, hold on.. this can't possibly work now :(
> >
> > This is what happens when Luis and I disagree ...
> >
> > I thought the bandwidth in a given section means the bandwidth that can
> > be used from this section,
> 
> No, indeed that was the objective.

That's not what's implemented though.

> > Luis implemented it to mean that a channel
> > overlapping any part of that section can only use that much bandwidth.
> 
> This was a side effect of the checks we have in place, it was not expected.

But this is what happens due to the reg.c implementation -- it checks
that the freqband into which the primary and secondary channel fall each
allows 40 MHz, even if they are two different freqbands.

> > Note sure which was intended?
> 
> Technically speaking the math should be possible to figure out to
> enable HT40 or not based on peer channels and although that was
> assumed the user reported it not allowing HT40 due to the peer
> channels not allowing HT40. I took your patch as an assumption that
> was not possible.

Indeed this is what we had, but I built the db.txt parser based on the
assumption that in fact "@ 20" in the channel 11/12 freqband would have
been sufficient to allow 40 Mhz on channel 9+. This isn't the case in
the kernel implementation today.

johannes


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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Luis R. Rodriguez]

On Tue, Dec 4, 2012 at 10:20 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2012-12-04 at 10:13 -0800, Luis R. Rodriguez wrote:
>
>> >> When in world roaming mode, allow 40 MHz to be used
>> >> on channels 12 and 13 so that an AP that is, e.g.,
>> >> using HT40+ on channel 9 (in the UK) can be used.
>> >
>> > Well, hold on.. this can't possibly work now :(
>> >
>> > This is what happens when Luis and I disagree ...
>> >
>> > I thought the bandwidth in a given section means the bandwidth that can
>> > be used from this section,
>>
>> No, indeed that was the objective.
>
> That's not what's implemented though.
>
>> > Luis implemented it to mean that a channel
>> > overlapping any part of that section can only use that much bandwidth.
>>
>> This was a side effect of the checks we have in place, it was not expected.
>
> But this is what happens due to the reg.c implementation -- it checks
> that the freqband into which the primary and secondary channel fall each
> allows 40 MHz, even if they are two different freqbands.

As I implemented it, it should be checking if HT40 is used. If so then
it should be checking to see if the primary can use 40 MHz bandwidth
and then check to see if the secondary can use 20 MHz. The issue
should be that the code should likely is checking that the secondary
requires 40 MHz. It should only need to check if the secondary can use
20 MHz if HT40 is desired.

>> > Note sure which was intended?
>>
>> Technically speaking the math should be possible to figure out to
>> enable HT40 or not based on peer channels and although that was
>> assumed the user reported it not allowing HT40 due to the peer
>> channels not allowing HT40. I took your patch as an assumption that
>> was not possible.
>
> Indeed this is what we had, but I built the db.txt parser based on the
> assumption that in fact "@ 20" in the channel 11/12 freqband would have
> been sufficient to allow 40 Mhz on channel 9+. This isn't the case in
> the kernel implementation today.

I'll fix that, but given you have a slew of updates not sure if this
should go in after / before your changes.

  Luis

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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Johannes Berg]

On Tue, 2012-12-04 at 10:28 -0800, Luis R. Rodriguez wrote:

> >> This was a side effect of the checks we have in place, it was not expected.
> >
> > But this is what happens due to the reg.c implementation -- it checks
> > that the freqband into which the primary and secondary channel fall each
> > allows 40 MHz, even if they are two different freqbands.
> 
> As I implemented it, it should be checking if HT40 is used. If so then
> it should be checking to see if the primary can use 40 MHz bandwidth
> and then check to see if the secondary can use 20 MHz. The issue
> should be that the code should likely is checking that the secondary
> requires 40 MHz. It should only need to check if the secondary can use
> 20 MHz if HT40 is desired.

I don't think this is really what we should do ... In fact given the way
we do it now with overlapping freqbands this would cause more problems
than it would solve, I think.

What it really should check is that for each freqband, as much bandwidth
is allowed as falls into that freqband. But given that we have
overlapping freqbands, much bandwidth will actually fall into each one
of them, so we must allow @40 again ...

I'm drawing some pictures now :-)


> > Indeed this is what we had, but I built the db.txt parser based on the
> > assumption that in fact "@ 20" in the channel 11/12 freqband would have
> > been sufficient to allow 40 Mhz on channel 9+. This isn't the case in
> > the kernel implementation today.
> 
> I'll fix that, but given you have a slew of updates not sure if this
> should go in after / before your changes.

I think the easiest for now would be to actually do what's implemented
and make this change to dbparse.py:

@@ -162,9 +164,6 @@ class DBParser(object):
                 self._syntax_error("Inverted freq range (%d - %d)" % (start, end))
             if start == end:
                 self._syntax_error("Start and end freqs are equal (%d)" % start)
-            if end - start < bw:
-                self._syntax_error("Invalid bandwidth: %d width channel "
-                       "cannot possibly fit between %d - %d" % (bw, start, end))
         except ValueError:
             self._syntax_error("band must have frequency range")
 

Then we can make the db.txt change I suggested in the the original patch
in this thread and keep the rules that both the primary and secondary
channel must be in a freqband that allows 40 MHz.

Note that this really only applies for the 00 world roaming regdomain
(and maybe Japan, but I don't actually think so) since every other
regdomain just uses a single rule.

johannes


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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Luis R. Rodriguez]

On Tue, Dec 4, 2012 at 10:41 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2012-12-04 at 10:28 -0800, Luis R. Rodriguez wrote:
>
>> >> This was a side effect of the checks we have in place, it was not expected.
>> >
>> > But this is what happens due to the reg.c implementation -- it checks
>> > that the freqband into which the primary and secondary channel fall each
>> > allows 40 MHz, even if they are two different freqbands.
>>
>> As I implemented it, it should be checking if HT40 is used. If so then
>> it should be checking to see if the primary can use 40 MHz bandwidth
>> and then check to see if the secondary can use 20 MHz. The issue
>> should be that the code should likely is checking that the secondary
>> requires 40 MHz. It should only need to check if the secondary can use
>> 20 MHz if HT40 is desired.
>
> I don't think this is really what we should do ... In fact given the way
> we do it now with overlapping freqbands this would cause more problems
> than it would solve, I think.

If we end up supporting overlapping frequency rules to be submitted.
Right now they don't overlap but point taken that we do support it and
there may possible issue of having them supported.

> What it really should check is that for each freqband, as much bandwidth
> is allowed as falls into that freqband. But given that we have
> overlapping freqbands, much bandwidth will actually fall into each one
> of them, so we must allow @40 again ...
>
> I'm drawing some pictures now :-)

:) Lets be clear though that your points on overlapping frequency
rules are a separate architectural position to take than addressing
the issue at hand. This however is a good crux point for us to
evaluate this particular architectural consideration.

>> > Indeed this is what we had, but I built the db.txt parser based on the
>> > assumption that in fact "@ 20" in the channel 11/12 freqband would have
>> > been sufficient to allow 40 Mhz on channel 9+. This isn't the case in
>> > the kernel implementation today.
>>
>> I'll fix that, but given you have a slew of updates not sure if this
>> should go in after / before your changes.
>
> I think the easiest for now would be to actually do what's implemented
> and make this change to dbparse.py:
>
> @@ -162,9 +164,6 @@ class DBParser(object):
>                  self._syntax_error("Inverted freq range (%d - %d)" % (start, end))
>              if start == end:
>                  self._syntax_error("Start and end freqs are equal (%d)" % start)
> -            if end - start < bw:
> -                self._syntax_error("Invalid bandwidth: %d width channel "
> -                       "cannot possibly fit between %d - %d" % (bw, start, end))
>          except ValueError:
>              self._syntax_error("band must have frequency range")
>
>
> Then we can make the db.txt change I suggested in the the original patch
> in this thread and keep the rules that both the primary and secondary
> channel must be in a freqband that allows 40 MHz.

Sure, we would just need to document this.

> Note that this really only applies for the 00 world roaming regdomain
> (and maybe Japan, but I don't actually think so) since every other
> regdomain just uses a single rule.

Sure.

  Luis

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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Johannes Berg]

On Tue, 2012-12-04 at 10:54 -0800, Luis R. Rodriguez wrote:

> >> As I implemented it, it should be checking if HT40 is used. If so then
> >> it should be checking to see if the primary can use 40 MHz bandwidth
> >> and then check to see if the secondary can use 20 MHz. The issue
> >> should be that the code should likely is checking that the secondary
> >> requires 40 MHz. It should only need to check if the secondary can use
> >> 20 MHz if HT40 is desired.
> >
> > I don't think this is really what we should do ... In fact given the way
> > we do it now with overlapping freqbands this would cause more problems
> > than it would solve, I think.
> 
> If we end up supporting overlapping frequency rules to be submitted.
> Right now they don't overlap but point taken that we do support it and
> there may possible issue of having them supported.

00 has overlapping rules today, also JP and KP

> > What it really should check is that for each freqband, as much bandwidth
> > is allowed as falls into that freqband. But given that we have
> > overlapping freqbands, much bandwidth will actually fall into each one
> > of them, so we must allow @40 again ...
> >
> > I'm drawing some pictures now :-)
> 
> :) Lets be clear though that your points on overlapping frequency
> rules are a separate architectural position to take than addressing
> the issue at hand. This however is a good crux point for us to
> evaluate this particular architectural consideration.

Agree.

johannes


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

Re: [wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Luis R. Rodriguez]

On Tue, Dec 4, 2012 at 11:11 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2012-12-04 at 10:54 -0800, Luis R. Rodriguez wrote:
>
>> >> As I implemented it, it should be checking if HT40 is used. If so then
>> >> it should be checking to see if the primary can use 40 MHz bandwidth
>> >> and then check to see if the secondary can use 20 MHz. The issue
>> >> should be that the code should likely is checking that the secondary
>> >> requires 40 MHz. It should only need to check if the secondary can use
>> >> 20 MHz if HT40 is desired.
>> >
>> > I don't think this is really what we should do ... In fact given the way
>> > we do it now with overlapping freqbands this would cause more problems
>> > than it would solve, I think.
>>
>> If we end up supporting overlapping frequency rules to be submitted.
>> Right now they don't overlap but point taken that we do support it and
>> there may possible issue of having them supported.
>
> 00 has overlapping rules today, also JP and KP

I was just thinking that after I wrote this.. otherwise this would not
have come up.

>> > What it really should check is that for each freqband, as much bandwidth
>> > is allowed as falls into that freqband. But given that we have
>> > overlapping freqbands, much bandwidth will actually fall into each one
>> > of them, so we must allow @40 again ...
>> >
>> > I'm drawing some pictures now :-)
>>
>> :) Lets be clear though that your points on overlapping frequency
>> rules are a separate architectural position to take than addressing
>> the issue at hand. This however is a good crux point for us to
>> evaluate this particular architectural consideration.
>
> Agree.

:)

  Luis

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