iwl4965: 11a channels disabled in current wireless-testing

iwl4965: 11a channels disabled in current wireless-testing

[Helmut Schaa]

Hi,

have there been any recent changes to the regulatory stuff, especially
in conjunction with iwlagn?

Because with wireless-testing I get all 11a channels disabled by default
and the same for channels 12 & 13 in the g-band.

Thanks,
Helmut

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Rafał Miłecki]

2010/2/28 Helmut Schaa <helmut.schaa@googlemail.com>:
> have there been any recent changes to the regulatory stuff, especially
> in conjunction with iwlagn?
>
> Because with wireless-testing I get all 11a channels disabled by default
> and the same for channels 12 & 13 in the g-band.

Please google for regulatory and regions. Higher frequencies
(channels) are not allowed in some countries.

-- 
Rafał

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Rafał Miłecki]

W dniu 28 lutego 2010 23:01 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał:
> 2010/2/28 Helmut Schaa <helmut.schaa@googlemail.com>:
>> have there been any recent changes to the regulatory stuff, especially
>> in conjunction with iwlagn?
>>
>> Because with wireless-testing I get all 11a channels disabled by default
>> and the same for channels 12 & 13 in the g-band.
>
> Please google for regulatory and regions. Higher frequencies
> (channels) are not allowed in some countries.

Blah, you wrote about regulatory changes... Ignore my response.

-- 
Rafał

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Helmut Schaa]

Am Sonntag 28 Februar 2010 schrieb Rafał Miłecki:
> W dniu 28 lutego 2010 23:01 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał:
> > 2010/2/28 Helmut Schaa <helmut.schaa@googlemail.com>:
> >> have there been any recent changes to the regulatory stuff, especially
> >> in conjunction with iwlagn?
> >>
> >> Because with wireless-testing I get all 11a channels disabled by default
> >> and the same for channels 12 & 13 in the g-band.
> >
> > Please google for regulatory and regions. Higher frequencies
> > (channels) are not allowed in some countries.
> 
> Blah, you wrote about regulatory changes... Ignore my response.

Yeah, maybe I wasn't precise enough. I always had quite a number of 11a
channels enabled with my iwl4965 (AFAIK depending on the channel mask encoded
in the cards EEPROM) but that changed some time ago. I don't know when because
I didn't have a need to connect to 11a APs for quite some time. Hence my
question.

Helmut

Re: iwl4965: 11a channels disabled in current wireless-testing

[reinette chatre]

On Sun, 2010-02-28 at 06:34 -0800, Helmut Schaa wrote:
> have there been any recent changes to the regulatory stuff, especially
> in conjunction with iwlagn?
> 
> Because with wireless-testing I get all 11a channels disabled by default
> and the same for channels 12 & 13 in the g-band.

This could be related to a change in the default regulatory domain. It
used to be US, but now it is world, which is more restrictive. You can
modify your regulatory domain using "iw reg set <domain>"

Reinette

Re: iwl4965: 11a channels disabled in current wireless-testing

[Luis R. Rodriguez]

On Mon, Mar 1, 2010 at 9:46 AM, reinette chatre
<reinette.chatre@intel.com> wrote:
> On Sun, 2010-02-28 at 06:34 -0800, Helmut Schaa wrote:
>> have there been any recent changes to the regulatory stuff, especially
>> in conjunction with iwlagn?
>>
>> Because with wireless-testing I get all 11a channels disabled by default
>> and the same for channels 12 & 13 in the g-band.
>
> This could be related to a change in the default regulatory domain. It
> used to be US, but now it is world,

This change actually happened a while ago and the world regulatory
domain actually enables passive scanning on a lot of channels instead
of straight out disabling them.

> which is more restrictive. You can
> modify your regulatory domain using "iw reg set <domain>"

For Intel, as well as with Atheros cards, cards using 'iw reg set'
would actually not yield enabling new channels, it would only disable
channels further.

  Luis

Re: iwl4965: 11a channels disabled in current wireless-testing

[Helmut Schaa]

Am Montag 01 März 2010 schrieb Luis R. Rodriguez:
> On Mon, Mar 1, 2010 at 9:46 AM, reinette chatre
> <reinette.chatre@intel.com> wrote:
> > On Sun, 2010-02-28 at 06:34 -0800, Helmut Schaa wrote:
> >> have there been any recent changes to the regulatory stuff, especially
> >> in conjunction with iwlagn?
> >>
> >> Because with wireless-testing I get all 11a channels disabled by default
> >> and the same for channels 12 & 13 in the g-band.
> >
> > This could be related to a change in the default regulatory domain. It
> > used to be US, but now it is world,
> 
> This change actually happened a while ago and the world regulatory
> domain actually enables passive scanning on a lot of channels instead
> of straight out disabling them.

How do channels get disabled then?

> > which is more restrictive. You can
> > modify your regulatory domain using "iw reg set <domain>"
> 
> For Intel, as well as with Atheros cards, cards using 'iw reg set'
> would actually not yield enabling new channels, it would only disable
> channels further.

Right, that's what I can see here as well.

However, I just noticed in dmesg:

iwlagn 0000:10:00.0: Tunable channels: 13 802.11bg, 19 802.11a channels

So it seems the card reports the correct set of channels but it doesn't
get reflected in cfg80211.

Thanks,
Helmut

Re: iwl4965: 11a channels disabled in current wireless-testing

[Luis R. Rodriguez]

On Mon, Mar 1, 2010 at 10:27 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Am Montag 01 März 2010 schrieb Luis R. Rodriguez:
>> On Mon, Mar 1, 2010 at 9:46 AM, reinette chatre
>> <reinette.chatre@intel.com> wrote:
>> > On Sun, 2010-02-28 at 06:34 -0800, Helmut Schaa wrote:
>> >> have there been any recent changes to the regulatory stuff, especially
>> >> in conjunction with iwlagn?
>> >>
>> >> Because with wireless-testing I get all 11a channels disabled by default
>> >> and the same for channels 12 & 13 in the g-band.
>> >
>> > This could be related to a change in the default regulatory domain. It
>> > used to be US, but now it is world,
>>
>> This change actually happened a while ago and the world regulatory
>> domain actually enables passive scanning on a lot of channels instead
>> of straight out disabling them.
>
> How do channels get disabled then?

In this order:

  * if the Intel card has an EEPROM where certain channels are disabled
  * if you set the country yourself
  * if your AP tells you that you are in a country where certain
channels are disabled

>> > which is more restrictive. You can
>> > modify your regulatory domain using "iw reg set <domain>"
>>
>> For Intel, as well as with Atheros cards, cards using 'iw reg set'
>> would actually not yield enabling new channels, it would only disable
>> channels further.
>
> Right, that's what I can see here as well.
>
> However, I just noticed in dmesg:
>
> iwlagn 0000:10:00.0: Tunable channels: 13 802.11bg, 19 802.11a channels
>
> So it seems the card reports the correct set of channels but it doesn't
> get reflected in cfg80211.

You can try to register to nl80211 events after loading cfg80211:

iw event -t

Then load iwlagn and see if you pick anything up. Might want to enable
CFG80211_REG_DEBUG.

  Luis

Re: iwl4965: 11a channels disabled in current wireless-testing

[Helmut Schaa]

Am Montag 01 März 2010 schrieb Luis R. Rodriguez:
> You can try to register to nl80211 events after loading cfg80211:
> 
> iw event -t
> 
> Then load iwlagn and see if you pick anything up. Might want to enable
> CFG80211_REG_DEBUG.

That's the only regulatory event I get:

1267558985.672513: phy #0: regulatory domain change: set to world roaming by the wireless core upon initialization request

When I set the reg domain to DE via iw I get:

1267559015.166161: regulatory domain change: set to DE by a user request

However all previously disabled channels are still disabled.
Reloading iwlagn afterwards gives the following again:

1267559087.050649: regulatory domain change: set to DE by a user request

And afterwards the 11a channels and 12+13bg are enabled (passive scanning
only, but that is fine) again.

I have no clue what's happening here.

Helmut

Re: iwl4965: 11a channels disabled in current wireless-testing

[reinette chatre]

Hi Helmut,

On Tue, 2010-03-02 at 11:47 -0800, Helmut Schaa wrote:
> That's the only regulatory event I get:
> 
> 1267558985.672513: phy #0: regulatory domain change: set to world roaming by the wireless core upon initialization request
> 
> When I set the reg domain to DE via iw I get:
> 
> 1267559015.166161: regulatory domain change: set to DE by a user request
> 
> However all previously disabled channels are still disabled.
> Reloading iwlagn afterwards gives the following again:
> 
> 1267559087.050649: regulatory domain change: set to DE by a user request
> 
> And afterwards the 11a channels and 12+13bg are enabled (passive scanning
> only, but that is fine) again.
> 
> I have no clue what's happening here.

Me neither. 

I too have a 4965 and its channels appear fine under the world
regulatory domain. Specifically:

$ iw reg get
country 00:
	(2402 - 2472 @ 40), (3, 20)
	(2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
	(2474 - 2494 @ 20), (3, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
	(5170 - 5250 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
	(5735 - 5835 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS

$ iw phy phy0 info
Wiphy phy0
	Band 1:
[...]
			* 2412 MHz [1] (15.0 dBm)
			* 2417 MHz [2] (15.0 dBm)
			* 2422 MHz [3] (15.0 dBm)
			* 2427 MHz [4] (15.0 dBm)
			* 2432 MHz [5] (15.0 dBm)
			* 2437 MHz [6] (15.0 dBm)
			* 2442 MHz [7] (15.0 dBm)
			* 2447 MHz [8] (15.0 dBm)
			* 2452 MHz [9] (15.0 dBm)
			* 2457 MHz [10] (15.0 dBm)
			* 2462 MHz [11] (15.0 dBm)
			* 2467 MHz [12] (15.0 dBm) (passive scanning, no IBSS)
			* 2472 MHz [13] (15.0 dBm) (passive scanning, no IBSS)
[...]

	Band 2:
[...]
		Frequencies:
			* 5180 MHz [36] (15.0 dBm) (passive scanning, no IBSS)
			* 5200 MHz [40] (15.0 dBm) (passive scanning, no IBSS)
			* 5220 MHz [44] (15.0 dBm) (passive scanning, no IBSS)
			* 5240 MHz [48] (15.0 dBm) (passive scanning, no IBSS)
			* 5260 MHz [52] (disabled)
			* 5280 MHz [56] (disabled)
			* 5300 MHz [60] (disabled)
			* 5320 MHz [64] (disabled)
			* 5500 MHz [100] (disabled)
			* 5520 MHz [104] (disabled)
			* 5540 MHz [108] (disabled)
			* 5560 MHz [112] (disabled)
			* 5580 MHz [116] (disabled)
			* 5600 MHz [120] (disabled)
			* 5620 MHz [124] (disabled)
			* 5640 MHz [128] (disabled)
			* 5660 MHz [132] (disabled)
			* 5680 MHz [136] (disabled)
			* 5700 MHz [140] (disabled)

Hopefully Luis can see why your channels are not showing up correctly.

Reinette

Re: iwl4965: 11a channels disabled in current wireless-testing

[Helmut Schaa]

Am Mittwoch 03 März 2010 schrieb reinette chatre:
> Hi Helmut,
> 
> On Tue, 2010-03-02 at 11:47 -0800, Helmut Schaa wrote:
> > That's the only regulatory event I get:
> > 
> > 1267558985.672513: phy #0: regulatory domain change: set to world roaming by the wireless core upon initialization request
> > 
> > When I set the reg domain to DE via iw I get:
> > 
> > 1267559015.166161: regulatory domain change: set to DE by a user request
> > 
> > However all previously disabled channels are still disabled.
> > Reloading iwlagn afterwards gives the following again:
> > 
> > 1267559087.050649: regulatory domain change: set to DE by a user request
> > 
> > And afterwards the 11a channels and 12+13bg are enabled (passive scanning
> > only, but that is fine) again.
> > 
> > I have no clue what's happening here.
> 
> Me neither. 
> 
> I too have a 4965 and its channels appear fine under the world
> regulatory domain. Specifically:
> 
> $ iw reg get
> country 00:
> 	(2402 - 2472 @ 40), (3, 20)
> 	(2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
> 	(2474 - 2494 @ 20), (3, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
> 	(5170 - 5250 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
> 	(5735 - 5835 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS

Oops, that's what I get:

country 00:
        (2402 - 2472 @ 40), (3, 20)

Luis, is the world reg domain encoded in cfg80211 or in the regdb? Maybe
the regdb is too old or something like that?

Thanks,
Helmut

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[John W. Linville]

On Wed, Mar 03, 2010 at 08:08:47PM +0100, Helmut Schaa wrote:
> Am Mittwoch 03 März 2010 schrieb reinette chatre:

> > $ iw reg get
> > country 00:
> > 	(2402 - 2472 @ 40), (3, 20)
> > 	(2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
> > 	(2474 - 2494 @ 20), (3, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
> > 	(5170 - 5250 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
> > 	(5735 - 5835 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
> 
> Oops, that's what I get:
> 
> country 00:
>         (2402 - 2472 @ 40), (3, 20)
> 
> Luis, is the world reg domain encoded in cfg80211 or in the regdb? Maybe
> the regdb is too old or something like that?

Should be both -- start w/ the one encoded in the kernel and request
an update from userland if it is available.

Hth!

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

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Helmut Schaa]

Am Mittwoch 03 März 2010 schrieb John W. Linville:
> On Wed, Mar 03, 2010 at 08:08:47PM +0100, Helmut Schaa wrote:
> > Am Mittwoch 03 März 2010 schrieb reinette chatre:
> 
> > > $ iw reg get
> > > country 00:
> > > 	(2402 - 2472 @ 40), (3, 20)
> > > 	(2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
> > > 	(2474 - 2494 @ 20), (3, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
> > > 	(5170 - 5250 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
> > > 	(5735 - 5835 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
> > 
> > Oops, that's what I get:
> > 
> > country 00:
> >         (2402 - 2472 @ 40), (3, 20)
> > 
> > Luis, is the world reg domain encoded in cfg80211 or in the regdb? Maybe
> > the regdb is too old or something like that?
> 
> Should be both -- start w/ the one encoded in the kernel and request
> an update from userland if it is available.
> 
> Hth!

It does indeed. I moved crda out of the way so that it cannot get called
anymore and after loading cfg80211, mac80211 and iwlagn I had all the
channels set up the same way as Reinette (and that is how I expected it to
be).

So I guess it's my regdb that's outdated.

Thanks,
Helmut

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Daniel Halperin]

On Mar 3, 2010, at 10:18 AM, reinette chatre wrote:
> 	Band 2:
> [...]
> 		Frequencies:
> 			* 5180 MHz [36] (15.0 dBm) (passive scanning, no IBSS)
> 			* 5200 MHz [40] (15.0 dBm) (passive scanning, no IBSS)
> 			* 5220 MHz [44] (15.0 dBm) (passive scanning, no IBSS)
> 			* 5240 MHz [48] (15.0 dBm) (passive scanning, no IBSS)
> 			* 5260 MHz [52] (disabled)
> 			* 5280 MHz [56] (disabled)
> 			* 5300 MHz [60] (disabled)
> 			* 5320 MHz [64] (disabled)
> 			* 5500 MHz [100] (disabled)
> 			* 5520 MHz [104] (disabled)
> 			* 5540 MHz [108] (disabled)
> 			* 5560 MHz [112] (disabled)
> 			* 5580 MHz [116] (disabled)
> 			* 5600 MHz [120] (disabled)
> 			* 5620 MHz [124] (disabled)
> 			* 5640 MHz [128] (disabled)
> 			* 5660 MHz [132] (disabled)
> 			* 5680 MHz [136] (disabled)
> 			* 5700 MHz [140] (disabled)

Is this really correct? With some update between now and a while ago (October?) I can no longer even monitor on most 11a channels. (E.g., "iwconfig wlan0 mode monitor ; iwconfig wlan0 channel 64" returns an error). This was not the old behavior, and seems to be wrong to me.

Dan

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[reinette chatre]

On Wed, 2010-03-03 at 12:14 -0800, Daniel Halperin wrote:
> On Mar 3, 2010, at 10:18 AM, reinette chatre wrote:
> > 	Band 2:
> > [...]
> > 		Frequencies:
> > 			* 5180 MHz [36] (15.0 dBm) (passive scanning, no IBSS)
> > 			* 5200 MHz [40] (15.0 dBm) (passive scanning, no IBSS)
> > 			* 5220 MHz [44] (15.0 dBm) (passive scanning, no IBSS)
> > 			* 5240 MHz [48] (15.0 dBm) (passive scanning, no IBSS)
> > 			* 5260 MHz [52] (disabled)
> > 			* 5280 MHz [56] (disabled)
> > 			* 5300 MHz [60] (disabled)
> > 			* 5320 MHz [64] (disabled)
> > 			* 5500 MHz [100] (disabled)
> > 			* 5520 MHz [104] (disabled)
> > 			* 5540 MHz [108] (disabled)
> > 			* 5560 MHz [112] (disabled)
> > 			* 5580 MHz [116] (disabled)
> > 			* 5600 MHz [120] (disabled)
> > 			* 5620 MHz [124] (disabled)
> > 			* 5640 MHz [128] (disabled)
> > 			* 5660 MHz [132] (disabled)
> > 			* 5680 MHz [136] (disabled)
> > 			* 5700 MHz [140] (disabled)
> 
> Is this really correct?

This is the information that iw provides. I am not familiar with how it
obtains it and is perhaps just a reflection of the regulatory domain in
use as opposed to what the device actually supports. The above does not
reflect what the device is capable of and since it does its own
regulatory things should work. When I load the module with debug=0x1 I
do see that the channels listed above as disabled can be used (just not
for beaconing) since they are radar channels.


[13071.468278] ieee80211 phy0: U iwl_init_channel_map Ch. 34 Flags 0 [5.2GHz] - No traffic
[13071.476329] ieee80211 phy0: U iwl_init_channel_map Ch. 36 [5.2GHz] VALID IBSS ACTIVE WIDE DFS (0xab 15dBm): Ad-Hoc supported
[13071.487587] ieee80211 phy0: U iwl_init_channel_map Ch. 38 Flags 0 [5.2GHz] - No traffic
[13071.495646] ieee80211 phy0: U iwl_init_channel_map Ch. 40 [5.2GHz] VALID IBSS ACTIVE WIDE DFS (0xab 15dBm): Ad-Hoc supported
[13071.506902] ieee80211 phy0: U iwl_init_channel_map Ch. 42 Flags 0 [5.2GHz] - No traffic
[13071.514952] ieee80211 phy0: U iwl_init_channel_map Ch. 44 [5.2GHz] VALID IBSS ACTIVE WIDE DFS (0xab 15dBm): Ad-Hoc supported
[13071.526210] ieee80211 phy0: U iwl_init_channel_map Ch. 46 Flags 0 [5.2GHz] - No traffic
[13071.534260] ieee80211 phy0: U iwl_init_channel_map Ch. 48 [5.2GHz] VALID IBSS ACTIVE WIDE DFS (0xab 15dBm): Ad-Hoc supported
[13071.545520] ieee80211 phy0: U iwl_init_channel_map Ch. 52 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.556293] ieee80211 phy0: U iwl_init_channel_map Ch. 56 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.567032] ieee80211 phy0: U iwl_init_channel_map Ch. 60 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.577770] ieee80211 phy0: U iwl_init_channel_map Ch. 64 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.588509] ieee80211 phy0: U iwl_init_channel_map Ch. 100 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.599332] ieee80211 phy0: U iwl_init_channel_map Ch. 104 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.610157] ieee80211 phy0: U iwl_init_channel_map Ch. 108 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.620999] ieee80211 phy0: U iwl_init_channel_map Ch. 112 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.631822] ieee80211 phy0: U iwl_init_channel_map Ch. 116 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.642646] ieee80211 phy0: U iwl_init_channel_map Ch. 120 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.653471] ieee80211 phy0: U iwl_init_channel_map Ch. 124 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.664294] ieee80211 phy0: U iwl_init_channel_map Ch. 128 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.675120] ieee80211 phy0: U iwl_init_channel_map Ch. 132 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.685977] ieee80211 phy0: U iwl_init_channel_map Ch. 136 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.696802] ieee80211 phy0: U iwl_init_channel_map Ch. 140 [5.2GHz] VALID RADAR WIDE (0x31 15dBm): Ad-Hoc not supported
[13071.707624] ieee80211 phy0: U iwl_init_channel_map Ch. 145 Flags 0 [5.2GHz] - No traffic
[13071.715762] ieee80211 phy0: U iwl_init_channel_map Ch. 149 Flags 0 [5.2GHz] - No traffic
[13071.723897] ieee80211 phy0: U iwl_init_channel_map Ch. 153 Flags 0 [5.2GHz] - No traffic
[13071.732041] ieee80211 phy0: U iwl_init_channel_map Ch. 157 Flags 0 [5.2GHz] - No traffic
[13071.740185] ieee80211 phy0: U iwl_init_channel_map Ch. 161 Flags 0 [5.2GHz] - No traffic
[13071.748322] ieee80211 phy0: U iwl_init_channel_map Ch. 165 Flags 0 [5.2GHz] - No traffic


>  With some update between now and a while ago (October?) I can no
> longer even monitor on most 11a channels. (E.g., "iwconfig wlan0 mode
> monitor ; iwconfig wlan0 channel 64" returns an error). This was not
> the old behavior, and seems to be wrong to me.

What error do you get? Have you tried to set up monitor channel using
iw? Is bisect an option to try to find out what caused this?

Reinette

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Daniel Halperin]

On Mar 3, 2010, at 1:19 PM, reinette chatre wrote:
> 
>> With some update between now and a while ago (October?) I can no
>> longer even monitor on most 11a channels. (E.g., "iwconfig wlan0 mode
>> monitor ; iwconfig wlan0 channel 64" returns an error). This was not
>> the old behavior, and seems to be wrong to me.
> 
> What error do you get? Have you tried to set up monitor channel using
> iw? Is bisect an option to try to find out what caused this?

Haven't dug into it yet; I will though!

Dan

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Daniel Halperin]

On Mar 3, 2010, at 2:54 PM, Daniel Halperin wrote:

> 
> On Mar 3, 2010, at 1:19 PM, reinette chatre wrote:
>> 
>>> With some update between now and a while ago (October?) I can no
>>> longer even monitor on most 11a channels. (E.g., "iwconfig wlan0 mode
>>> monitor ; iwconfig wlan0 channel 64" returns an error). This was not
>>> the old behavior, and seems to be wrong to me.
>> 
>> What error do you get? Have you tried to set up monitor channel using
>> iw? Is bisect an option to try to find out what caused this?
> 
> Haven't dug into it yet; I will though!

Here's some initial analysis. Comments are inline at the commands I entered, and summary at the bottom. I think the problem is that iwlwifi doesn't implement/register reg_notifier with the relevant cfg80211 code in net/wireless/reg.c . I'm using Ubuntu 8.04 LTS, iwlwifi-2.6.git tip (2f12075065fc81c848a75a5c51cf2ddece8036c9) and I just updated/reinstalled my CRDA. 

# rmmod iwlagn iwlcore mac80211 cfg80211   [this last resets CRDA to world domain]
# modprobe iwlagn debug50=0x40003	   [iwlwifi's MAC80211 and INFO debug flags, plus the firmware crash dump flag]
# iw list				   [Note that channels 64 and nearby are completely disabled in world domain]
[...]
		Frequencies:
			* 5180 MHz [36] (15.0 dBm) (passive scanning, no IBSS)
			* 5200 MHz [40] (15.0 dBm) (passive scanning, no IBSS)
			* 5220 MHz [44] (15.0 dBm) (passive scanning, no IBSS)
			* 5240 MHz [48] (15.0 dBm) (passive scanning, no IBSS)
			* 5260 MHz [52] (disabled)
			* 5280 MHz [56] (disabled)
			* 5300 MHz [60] (disabled)
			* 5320 MHz [64] (disabled)
			* 5500 MHz [100] (disabled)
			* 5520 MHz [104] (disabled)
			* 5540 MHz [108] (disabled)
			* 5560 MHz [112] (disabled)
			* 5580 MHz [116] (disabled)
			* 5600 MHz [120] (disabled)
			* 5620 MHz [124] (disabled)
			* 5640 MHz [128] (disabled)
			* 5660 MHz [132] (disabled)
			* 5680 MHz [136] (disabled)
			* 5700 MHz [140] (disabled)
			* 5745 MHz [149] (15.0 dBm) (passive scanning, no IBSS)
			* 5765 MHz [153] (15.0 dBm) (passive scanning, no IBSS)
			* 5785 MHz [157] (15.0 dBm) (passive scanning, no IBSS)
			* 5805 MHz [161] (15.0 dBm) (passive scanning, no IBSS)
			* 5825 MHz [165] (15.0 dBm) (passive scanning, no IBSS)
[...]

# iw reg get			  [Note that channels 64 and nearby are completely disabled in world domain, matches iw list]
country 00:
	(2402 - 2472 @ 40), (3, 20)
	(2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
	(2474 - 2494 @ 20), (3, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
	(5170 - 5250 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
	(5735 - 5835 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS

# iw reg set US
# iw reg get			  [Now channel 64 (5320) is a legitimate channel]
country US:
	(2402 - 2472 @ 40), (3, 27)
	(5170 - 5250 @ 40), (3, 17)
	(5250 - 5330 @ 40), (3, 20), DFS
	(5490 - 5600 @ 40), (3, 20), DFS
	(5650 - 5710 @ 40), (3, 20), DFS
	(5735 - 5835 @ 40), (3, 30)

# iw list			  [cfg80211 + mac80211 + iwlwifi didn't notice the regulatory change!]
[...]
		Frequencies:
			* 5180 MHz [36] (15.0 dBm) (passive scanning, no IBSS)
			* 5200 MHz [40] (15.0 dBm) (passive scanning, no IBSS)
			* 5220 MHz [44] (15.0 dBm) (passive scanning, no IBSS)
			* 5240 MHz [48] (15.0 dBm) (passive scanning, no IBSS)
			* 5260 MHz [52] (disabled)
			* 5280 MHz [56] (disabled)
			* 5300 MHz [60] (disabled)
			* 5320 MHz [64] (disabled)
			* 5500 MHz [100] (disabled)
			* 5520 MHz [104] (disabled)
			* 5540 MHz [108] (disabled)
			* 5560 MHz [112] (disabled)
			* 5580 MHz [116] (disabled)
			* 5600 MHz [120] (disabled)
			* 5620 MHz [124] (disabled)
			* 5640 MHz [128] (disabled)
			* 5660 MHz [132] (disabled)
			* 5680 MHz [136] (disabled)
			* 5700 MHz [140] (disabled)
			* 5745 MHz [149] (15.0 dBm) (passive scanning, no IBSS)
			* 5765 MHz [153] (15.0 dBm) (passive scanning, no IBSS)
			* 5785 MHz [157] (15.0 dBm) (passive scanning, no IBSS)
			* 5805 MHz [161] (15.0 dBm) (passive scanning, no IBSS)
			* 5825 MHz [165] (15.0 dBm) (passive scanning, no IBSS)

[...]

# rmmod iwlagn && modprobe iwlagn debug50=0x40003
# iw list			  [everything's better!]
[...]
		Frequencies:
			* 5180 MHz [36] (15.0 dBm) (passive scanning, no IBSS)
			* 5200 MHz [40] (15.0 dBm) (passive scanning, no IBSS)
			* 5220 MHz [44] (15.0 dBm) (passive scanning, no IBSS)
			* 5240 MHz [48] (15.0 dBm) (passive scanning, no IBSS)
			* 5260 MHz [52] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5280 MHz [56] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5300 MHz [60] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5320 MHz [64] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5500 MHz [100] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5520 MHz [104] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5540 MHz [108] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5560 MHz [112] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5580 MHz [116] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5600 MHz [120] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5620 MHz [124] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5640 MHz [128] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5660 MHz [132] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5680 MHz [136] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5700 MHz [140] (15.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5745 MHz [149] (15.0 dBm) (passive scanning, no IBSS)
			* 5765 MHz [153] (15.0 dBm) (passive scanning, no IBSS)
			* 5785 MHz [157] (15.0 dBm) (passive scanning, no IBSS)
			* 5805 MHz [161] (15.0 dBm) (passive scanning, no IBSS)
			* 5825 MHz [165] (15.0 dBm) (passive scanning, no IBSS)
[...]

I have a guess as to the problem. In net/wireless/reg.c:wiphy_update_regulatory, the cfg80211 regulatory code is as follows:

        printk("%s: here\n", __func__);
        if (wiphy->reg_notifier) {
                printk("%s: here 1\n", __func__);
                wiphy->reg_notifier(wiphy, last_request);
        }

(obviously, the printk's are added). Looking at my dmesg, the second printk is never called, so Intel doesn't set a reg_notifier. This looks to be the mechanism by which it should be notified of the regulatory change, so the flag's aren't getting updated until the next time the driver is reloaded. And, given that the flags need to be an OR of the CRDA regulatory flags and the driver regulatory flags, it's presumably the driver's responsibility to update these flags. I note that ath9k does have a reg_notifier.

My hypothesis as to why this code used to work is that I was using the CONFIG_WIRELESS_OLD_REGULATORY.

Dan

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Luis R. Rodriguez]

On Thu, Mar 4, 2010 at 2:24 AM, Daniel Halperin
<dhalperi@cs.washington.edu> wrote:
> On Mar 3, 2010, at 2:54 PM, Daniel Halperin wrote:

> My hypothesis as to why this code used to work is that I was using the CONFIG_WIRELESS_OLD_REGULATORY.

Can you test the same by disabling CONFIG_WIRELESS_OLD_REGULATORY ?

There is a way for a driver to claim a custom world regulatory domain,
this can be done wiphy_apply_custom_regulatory(), ath/regd.c uses
that. Otherwise indeed the pegged regulatory domain will be used as a
basis for disabling further channels.

  Luis?

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Daniel Halperin]

On Mar 4, 2010, at 9:31 AM, Luis R. Rodriguez wrote:

> On Thu, Mar 4, 2010 at 2:24 AM, Daniel Halperin
> <dhalperi@cs.washington.edu> wrote:
>> On Mar 3, 2010, at 2:54 PM, Daniel Halperin wrote:
> 
>> My hypothesis as to why this code used to work is that I was using the CONFIG_WIRELESS_OLD_REGULATORY.
> 
> Can you test the same by disabling CONFIG_WIRELESS_OLD_REGULATORY ?

I am no longer using CONFIG_WIRELESS_OLD_REGULATORY; in fact I believe that kernel option has been removed. I don't have any old versions around any more unfortunately to test this hypothesis with.

> There is a way for a driver to claim a custom world regulatory domain,
> this can be done wiphy_apply_custom_regulatory(), ath/regd.c uses
> that. Otherwise indeed the pegged regulatory domain will be used as a
> basis for disabling further channels.

It turns out that disabling WIPHY_FLAG_STRICT_REGULATORY:

--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -2632,7 +2632,7 @@ static int iwl_mac_setup_register(struct iwl_priv *priv)
                BIT(NL80211_IFTYPE_STATION) |
                BIT(NL80211_IFTYPE_ADHOC);
 
-       hw->wiphy->flags |= WIPHY_FLAG_STRICT_REGULATORY |
+       hw->wiphy->flags |= //WIPHY_FLAG_STRICT_REGULATORY |
                            WIPHY_FLAG_DISABLE_BEACON_HINTS;
 
        /*

also fixes the problem; in reality this is a hack. It does seem to keep the proper driver-set regulatory limits even when I switch modes or channels or CRDA domains. This is because iwl_mac_setup_register() happens after the eeprom is read in iwl-agn.c, and thus the regulatory flags (chan->orig_flags) are pegged and thus stay set properly throughout the run. But it seems like the right approach is actually to do what ath/regd.c does and apply the custom regulatory domain.

Right now, iwlwifi sets WIPHY_FLAG_STRICT_REGULATORY but never sends the custom regulatory domain and so all CRDA requests are ignored by the checks in <base>/net/wireless/reg.c:handle_channel. (Until iwlagn, but not cfg80211, is reloaded).

Dan

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Daniel Halperin]

Fyi, I created bug #2172 (http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2172) for this issue.

Dan

On Mar 9, 2010, at 2:05 PM, Daniel Halperin wrote:

> On Mar 4, 2010, at 9:31 AM, Luis R. Rodriguez wrote:
> 
>> On Thu, Mar 4, 2010 at 2:24 AM, Daniel Halperin
>> <dhalperi@cs.washington.edu> wrote:
>>> On Mar 3, 2010, at 2:54 PM, Daniel Halperin wrote:
>> 
>>> My hypothesis as to why this code used to work is that I was using the CONFIG_WIRELESS_OLD_REGULATORY.
>> 
>> Can you test the same by disabling CONFIG_WIRELESS_OLD_REGULATORY ?
> 
> I am no longer using CONFIG_WIRELESS_OLD_REGULATORY; in fact I believe that kernel option has been removed. I don't have any old versions around any more unfortunately to test this hypothesis with.
> 
>> There is a way for a driver to claim a custom world regulatory domain,
>> this can be done wiphy_apply_custom_regulatory(), ath/regd.c uses
>> that. Otherwise indeed the pegged regulatory domain will be used as a
>> basis for disabling further channels.
> 
> It turns out that disabling WIPHY_FLAG_STRICT_REGULATORY:
> 
> --- a/drivers/net/wireless/iwlwifi/iwl-agn.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
> @@ -2632,7 +2632,7 @@ static int iwl_mac_setup_register(struct iwl_priv *priv)
>                BIT(NL80211_IFTYPE_STATION) |
>                BIT(NL80211_IFTYPE_ADHOC);
> 
> -       hw->wiphy->flags |= WIPHY_FLAG_STRICT_REGULATORY |
> +       hw->wiphy->flags |= //WIPHY_FLAG_STRICT_REGULATORY |
>                            WIPHY_FLAG_DISABLE_BEACON_HINTS;
> 
>        /*
> 
> also fixes the problem; in reality this is a hack. It does seem to keep the proper driver-set regulatory limits even when I switch modes or channels or CRDA domains. This is because iwl_mac_setup_register() happens after the eeprom is read in iwl-agn.c, and thus the regulatory flags (chan->orig_flags) are pegged and thus stay set properly throughout the run. But it seems like the right approach is actually to do what ath/regd.c does and apply the custom regulatory domain.
> 
> Right now, iwlwifi sets WIPHY_FLAG_STRICT_REGULATORY but never sends the custom regulatory domain and so all CRDA requests are ignored by the checks in <base>/net/wireless/reg.c:handle_channel. (Until iwlagn, but not cfg80211, is reloaded).
> 
> Dan
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Ipw3945-devel mailing list
> Ipw3945-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[reinette chatre]

Hi Dan,

On Tue, 2010-03-09 at 14:05 -0800, Daniel Halperin wrote:

> It turns out that disabling WIPHY_FLAG_STRICT_REGULATORY:
> 
> --- a/drivers/net/wireless/iwlwifi/iwl-agn.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
> @@ -2632,7 +2632,7 @@ static int iwl_mac_setup_register(struct iwl_priv *priv)
>                 BIT(NL80211_IFTYPE_STATION) |
>                 BIT(NL80211_IFTYPE_ADHOC);
>  
> -       hw->wiphy->flags |= WIPHY_FLAG_STRICT_REGULATORY |
> +       hw->wiphy->flags |= //WIPHY_FLAG_STRICT_REGULATORY |
>                             WIPHY_FLAG_DISABLE_BEACON_HINTS;
>  
>         /*
> 
> also fixes the problem; in reality this is a hack. It does seem to keep the proper driver-set regulatory limits even when I switch modes or channels or CRDA domains. This is because iwl_mac_setup_register() happens after the eeprom is read in iwl-agn.c, and thus the regulatory flags (chan->orig_flags) are pegged and thus stay set properly throughout the run. But it seems like the right approach is actually to do what ath/regd.c does and apply the custom regulatory domain.

For this I think we need to set WIPHY_FLAG_CUSTOM_REGULATORY instead of
WIPHY_FLAG_STRICT_REGULATORY. Looking closer it actually look as though
this is a typo that slipped in with "cfg80211: convert bools to flags"
where "hw->wiphy->custom_regulatory = true" was translated to
"hw->wiphy->flags |= WIPHY_FLAG_STRICT_REGULATORY" by mistake.

Can you please try by replacing WIPHY_FLAG_STRICT_REGULATORY with
WIPHY_FLAG_CUSTOM_REGULATORY instead?

Reinette

Re: [ipw3945-devel] iwl4965: 11a channels disabled in current wireless-testing

[Helmut Schaa]

Hi Reinette,

Am Mittwoch 10 März 2010 schrieb reinette chatre:
> For this I think we need to set WIPHY_FLAG_CUSTOM_REGULATORY instead of
> WIPHY_FLAG_STRICT_REGULATORY. Looking closer it actually look as though
> this is a typo that slipped in with "cfg80211: convert bools to flags"
> where "hw->wiphy->custom_regulatory = true" was translated to
> "hw->wiphy->flags |= WIPHY_FLAG_STRICT_REGULATORY" by mistake.
> 
> Can you please try by replacing WIPHY_FLAG_STRICT_REGULATORY with
> WIPHY_FLAG_CUSTOM_REGULATORY instead?

Works perfectly for me.

Thanks a lot,
Helmut