ath9k 9380: All 5Ghz channels flagged as passive-scanning

ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

This is on 2.6.39-wl+

All the 5Ghz channels are showing as passive scanning, which
makes them unusable for APs if nothing else.

Any idea why this is happening?

On a previous boot, I had an STA associated on channel
40 and that was the single 5Ghz channel that didn't
show 'passive scanning'.  I removed it's configuration
so that it wouldn't associate and upon reboot I see
the output below.

More than happy to provide more details...

[root@lec-ath9k-9380 ~]# iw phy wiphy0 info
Wiphy wiphy0
	Band 1:
		Capabilities: 0x11ef
			RX LDPC
			HT20/HT40
			SM Power Save disabled
			RX HT20 SGI
			RX HT40 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 8 usec (0x06)
		HT TX/RX MCS rate indexes supported: 0-23
		Frequencies:
			* 2412 MHz [1] (17.0 dBm)
			* 2417 MHz [2] (17.0 dBm)
			* 2422 MHz [3] (17.0 dBm)
			* 2427 MHz [4] (17.0 dBm)
			* 2432 MHz [5] (17.0 dBm)
			* 2437 MHz [6] (17.0 dBm)
			* 2442 MHz [7] (17.0 dBm)
			* 2447 MHz [8] (17.0 dBm)
			* 2452 MHz [9] (17.0 dBm)
			* 2457 MHz [10] (17.0 dBm)
			* 2462 MHz [11] (17.0 dBm)
			* 2467 MHz [12] (17.0 dBm) (passive scanning)
			* 2472 MHz [13] (17.0 dBm) (passive scanning)
			* 2484 MHz [14] (disabled)
		Bitrates (non-HT):
			* 1.0 Mbps
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
	Band 2:
		Capabilities: 0x11ef
			RX LDPC
			HT20/HT40
			SM Power Save disabled
			RX HT20 SGI
			RX HT40 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 8 usec (0x06)
		HT TX/RX MCS rate indexes supported: 0-23
		Frequencies:
			* 5180 MHz [36] (18.0 dBm) (passive scanning, no IBSS)
			* 5200 MHz [40] (18.0 dBm) (passive scanning, no IBSS)
			* 5220 MHz [44] (18.0 dBm) (passive scanning, no IBSS)
			* 5240 MHz [48] (18.0 dBm) (passive scanning, no IBSS)
			* 5260 MHz [52] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5280 MHz [56] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5300 MHz [60] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5320 MHz [64] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5500 MHz [100] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5520 MHz [104] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5540 MHz [108] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5560 MHz [112] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5580 MHz [116] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5600 MHz [120] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5620 MHz [124] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5640 MHz [128] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5660 MHz [132] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5680 MHz [136] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5700 MHz [140] (18.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5745 MHz [149] (18.0 dBm) (passive scanning, no IBSS)
			* 5765 MHz [153] (18.0 dBm) (passive scanning, no IBSS)
			* 5785 MHz [157] (18.0 dBm) (passive scanning, no IBSS)
			* 5805 MHz [161] (18.0 dBm) (passive scanning, no IBSS)
			* 5825 MHz [165] (18.0 dBm) (passive scanning, no IBSS)
		Bitrates (non-HT):
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
	max # scan SSIDs: 4
	max scan IEs length: 2257 bytes
	Coverage class: 0 (up to 0m)
	Available Antennas: TX 0 RX 0
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * AP/VLAN
		 * WDS
		 * monitor
		 * mesh point
		 * P2P-client
		 * P2P-GO
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * new_beacon
		 * new_station
		 * new_mpath
		 * set_mesh_params
		 * set_bss
		 * authenticate
		 * associate
		 * deauthenticate
		 * disassociate
		 * join_ibss
		 * join_mesh
		 * remain_on_channel
		 * set_tx_bitrate_mask
		 * action
		 * frame_wait_cancel
		 * set_wiphy_netns
		 * set_channel
		 * set_wds_peer
		 * connect
		 * disconnect
	Supported TX frame types:
		 * IBSS: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * managed: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * AP: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * AP/VLAN: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * mesh point: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * P2P-client: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * P2P-GO: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
	Supported RX frame types:
		 * IBSS: 0x00d0
		 * managed: 0x0040 0x00d0
		 * AP: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
		 * AP/VLAN: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
		 * mesh point: 0x00b0 0x00c0 0x00d0
		 * P2P-client: 0x0040 0x00d0
		 * P2P-GO: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Mohammed Shafi]

On Sat, May 21, 2011 at 3:52 AM, Ben Greear <greearb@candelatech.com> wrote:
> This is on 2.6.39-wl+
>
> All the 5Ghz channels are showing as passive scanning, which
> makes them unusable for APs if nothing else.

for me channels 36,40,44,48 are ok in 5ghz. used the latest
wireless-testing just brought the card up as station mode.


>
> Any idea why this is happening?

don't know, may be regulatory.

>
> On a previous boot, I had an STA associated on channel
> 40 and that was the single 5Ghz channel that didn't
> show 'passive scanning'.  I removed it's configuration
> so that it wouldn't associate and upon reboot I see
> the output below.
>
> More than happy to provide more details...
>
> [root@lec-ath9k-9380 ~]# iw phy wiphy0 info
> Wiphy wiphy0
>        Band 1:
>                Capabilities: 0x11ef
>                        RX LDPC
>                        HT20/HT40
>                        SM Power Save disabled
>                        RX HT20 SGI
>                        RX HT40 SGI
>                        TX STBC
>                        RX STBC 1-stream
>                        Max AMSDU length: 3839 bytes
>                        DSSS/CCK HT40
>                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
>                Minimum RX AMPDU time spacing: 8 usec (0x06)
>                HT TX/RX MCS rate indexes supported: 0-23
>                Frequencies:
>                        * 2412 MHz [1] (17.0 dBm)
>                        * 2417 MHz [2] (17.0 dBm)
>                        * 2422 MHz [3] (17.0 dBm)
>                        * 2427 MHz [4] (17.0 dBm)
>                        * 2432 MHz [5] (17.0 dBm)
>                        * 2437 MHz [6] (17.0 dBm)
>                        * 2442 MHz [7] (17.0 dBm)
>                        * 2447 MHz [8] (17.0 dBm)
>                        * 2452 MHz [9] (17.0 dBm)
>                        * 2457 MHz [10] (17.0 dBm)
>                        * 2462 MHz [11] (17.0 dBm)
>                        * 2467 MHz [12] (17.0 dBm) (passive scanning)
>                        * 2472 MHz [13] (17.0 dBm) (passive scanning)
>                        * 2484 MHz [14] (disabled)
>                Bitrates (non-HT):
>                        * 1.0 Mbps
>                        * 2.0 Mbps (short preamble supported)
>                        * 5.5 Mbps (short preamble supported)
>                        * 11.0 Mbps (short preamble supported)
>                        * 6.0 Mbps
>                        * 9.0 Mbps
>                        * 12.0 Mbps
>                        * 18.0 Mbps
>                        * 24.0 Mbps
>                        * 36.0 Mbps
>                        * 48.0 Mbps
>                        * 54.0 Mbps
>        Band 2:
>                Capabilities: 0x11ef
>                        RX LDPC
>                        HT20/HT40
>                        SM Power Save disabled
>                        RX HT20 SGI
>                        RX HT40 SGI
>                        TX STBC
>                        RX STBC 1-stream
>                        Max AMSDU length: 3839 bytes
>                        DSSS/CCK HT40
>                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
>                Minimum RX AMPDU time spacing: 8 usec (0x06)
>                HT TX/RX MCS rate indexes supported: 0-23
>                Frequencies:
>                        * 5180 MHz [36] (18.0 dBm) (passive scanning, no
> IBSS)
>                        * 5200 MHz [40] (18.0 dBm) (passive scanning, no
> IBSS)
>                        * 5220 MHz [44] (18.0 dBm) (passive scanning, no
> IBSS)
>                        * 5240 MHz [48] (18.0 dBm) (passive scanning, no
> IBSS)
>                        * 5260 MHz [52] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5280 MHz [56] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5300 MHz [60] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5320 MHz [64] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5500 MHz [100] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5520 MHz [104] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5540 MHz [108] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5560 MHz [112] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5580 MHz [116] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5600 MHz [120] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5620 MHz [124] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5640 MHz [128] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5660 MHz [132] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5680 MHz [136] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5700 MHz [140] (18.0 dBm) (passive scanning, no
> IBSS, radar detection)
>                        * 5745 MHz [149] (18.0 dBm) (passive scanning, no
> IBSS)
>                        * 5765 MHz [153] (18.0 dBm) (passive scanning, no
> IBSS)
>                        * 5785 MHz [157] (18.0 dBm) (passive scanning, no
> IBSS)
>                        * 5805 MHz [161] (18.0 dBm) (passive scanning, no
> IBSS)
>                        * 5825 MHz [165] (18.0 dBm) (passive scanning, no
> IBSS)
>                Bitrates (non-HT):
>                        * 6.0 Mbps
>                        * 9.0 Mbps
>                        * 12.0 Mbps
>                        * 18.0 Mbps
>                        * 24.0 Mbps
>                        * 36.0 Mbps
>                        * 48.0 Mbps
>                        * 54.0 Mbps
>        max # scan SSIDs: 4
>        max scan IEs length: 2257 bytes
>        Coverage class: 0 (up to 0m)
>        Available Antennas: TX 0 RX 0
>        Supported interface modes:
>                 * IBSS
>                 * managed
>                 * AP
>                 * AP/VLAN
>                 * WDS
>                 * monitor
>                 * mesh point
>                 * P2P-client
>                 * P2P-GO
>        Supported commands:
>                 * new_interface
>                 * set_interface
>                 * new_key
>                 * new_beacon
>                 * new_station
>                 * new_mpath
>                 * set_mesh_params
>                 * set_bss
>                 * authenticate
>                 * associate
>                 * deauthenticate
>                 * disassociate
>                 * join_ibss
>                 * join_mesh
>                 * remain_on_channel
>                 * set_tx_bitrate_mask
>                 * action
>                 * frame_wait_cancel
>                 * set_wiphy_netns
>                 * set_channel
>                 * set_wds_peer
>                 * connect
>                 * disconnect
>        Supported TX frame types:
>                 * IBSS: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060
> 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                 * managed: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060
> 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                 * AP: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060
> 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                 * AP/VLAN: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060
> 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                 * mesh point: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050
> 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                 * P2P-client: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050
> 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>                 * P2P-GO: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060
> 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
>        Supported RX frame types:
>                 * IBSS: 0x00d0
>                 * managed: 0x0040 0x00d0
>                 * AP: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
>                 * AP/VLAN: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
>                 * mesh point: 0x00b0 0x00c0 0x00d0
>                 * P2P-client: 0x0040 0x00d0
>                 * P2P-GO: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
shafi

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>  wrote:
>> This is on 2.6.39-wl+
>>
>> All the 5Ghz channels are showing as passive scanning, which
>> makes them unusable for APs if nothing else.
>
> for me channels 36,40,44,48 are ok in 5ghz. used the latest
> wireless-testing just brought the card up as station mode.

Most of my systems show the same, at least most of the time.


>> Any idea why this is happening?
>
> don't know, may be regulatory.

After a reboot and an idle weekend, mine also look normal.
So, it's something transient it appears.

What a pain.

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/23/2011 09:54 AM, Ben Greear wrote:
> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>> wrote:
>>> This is on 2.6.39-wl+
>>>
>>> All the 5Ghz channels are showing as passive scanning, which
>>> makes them unusable for APs if nothing else.
>>
>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>> wireless-testing just brought the card up as station mode.
>
> Most of my systems show the same, at least most of the time.
>
>
>>> Any idea why this is happening?
>>
>> don't know, may be regulatory.
>
> After a reboot and an idle weekend, mine also look normal.
> So, it's something transient it appears.

Err, I mis-spoke..the 9380 system still shows passive
scanning everywhere...

Ben

>
> What a pain.
>
> Ben
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/23/2011 11:39 AM, Ben Greear wrote:
> On 05/23/2011 09:54 AM, Ben Greear wrote:
>> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>>> wrote:
>>>> This is on 2.6.39-wl+
>>>>
>>>> All the 5Ghz channels are showing as passive scanning, which
>>>> makes them unusable for APs if nothing else.
>>>
>>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>>> wireless-testing just brought the card up as station mode.
>>
>> Most of my systems show the same, at least most of the time.
>>
>>
>>>> Any idea why this is happening?
>>>
>>> don't know, may be regulatory.
>>
>> After a reboot and an idle weekend, mine also look normal.
>> So, it's something transient it appears.
>
> Err, I mis-spoke..the 9380 system still shows passive
> scanning everywhere...

Busted one:

ath: EEPROM regdomain: 0x6a
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x6a

cfg80211: Calling CRDA for country: US
cfg80211: Regulatory domain changed to country: US
cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)


Bleh, seems my Sparklan 127 NIC is set to world-roam :(

What a total pain in the arse!
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Mon, May 23, 2011 at 11:52 AM, Ben Greear <greearb@candelatech.com> wrote:
> On 05/23/2011 11:39 AM, Ben Greear wrote:
>>
>> On 05/23/2011 09:54 AM, Ben Greear wrote:
>>>
>>> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>>>>
>>>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>>>> wrote:
>>>>>
>>>>> This is on 2.6.39-wl+
>>>>>
>>>>> All the 5Ghz channels are showing as passive scanning, which
>>>>> makes them unusable for APs if nothing else.
>>>>
>>>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>>>> wireless-testing just brought the card up as station mode.
>>>
>>> Most of my systems show the same, at least most of the time.
>>>
>>>
>>>>> Any idea why this is happening?
>>>>
>>>> don't know, may be regulatory.
>>>
>>> After a reboot and an idle weekend, mine also look normal.
>>> So, it's something transient it appears.
>>
>> Err, I mis-spoke..the 9380 system still shows passive
>> scanning everywhere...
>
> Busted one:
>
> ath: EEPROM regdomain: 0x6a
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: 00
> ath: Regpair used: 0x6a
>
> cfg80211: Calling CRDA for country: US
> cfg80211: Regulatory domain changed to country: US
> cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
> cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>
>
> Bleh, seems my Sparklan 127 NIC is set to world-roam :(
>
> What a total pain in the arse!

Its what the card was designed and programmed for. The only thing you
can do with world roaming cards then is just scan, and if you find a
beacon on a channel which is a non-DFS channel beaconing will be
enabled then.

  Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/23/2011 12:26 PM, Luis R. Rodriguez wrote:
> On Mon, May 23, 2011 at 11:52 AM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 05/23/2011 11:39 AM, Ben Greear wrote:
>>>
>>> On 05/23/2011 09:54 AM, Ben Greear wrote:
>>>>
>>>> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>>>>>
>>>>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>>>>> wrote:
>>>>>>
>>>>>> This is on 2.6.39-wl+
>>>>>>
>>>>>> All the 5Ghz channels are showing as passive scanning, which
>>>>>> makes them unusable for APs if nothing else.
>>>>>
>>>>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>>>>> wireless-testing just brought the card up as station mode.
>>>>
>>>> Most of my systems show the same, at least most of the time.
>>>>
>>>>
>>>>>> Any idea why this is happening?
>>>>>
>>>>> don't know, may be regulatory.
>>>>
>>>> After a reboot and an idle weekend, mine also look normal.
>>>> So, it's something transient it appears.
>>>
>>> Err, I mis-spoke..the 9380 system still shows passive
>>> scanning everywhere...
>>
>> Busted one:
>>
>> ath: EEPROM regdomain: 0x6a
>> ath: EEPROM indicates we should expect a direct regpair map
>> ath: Country alpha2 being used: 00
>> ath: Regpair used: 0x6a
>>
>> cfg80211: Calling CRDA for country: US
>> cfg80211: Regulatory domain changed to country: US
>> cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain,
>> max_eirp)
>> cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>> cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>> cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>
>>
>> Bleh, seems my Sparklan 127 NIC is set to world-roam :(
>>
>> What a total pain in the arse!
>
> Its what the card was designed and programmed for. The only thing you
> can do with world roaming cards then is just scan, and if you find a
> beacon on a channel which is a non-DFS channel beaconing will be
> enabled then.

Makes it basically useless as a 5Ghz AP though, eh?

Guess it's time to go find a hack to over-ride eeprom
settings :(

Ben

>
>    Luis


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Mon, May 23, 2011 at 1:09 PM, Ben Greear <greearb@candelatech.com> wrote:
> Makes it basically useless as a 5Ghz AP though, eh?

Um yup. The card is a world roaming card... not an AP card. For AP
mode of functionality vendors have to go through a regulatory test
specific to 3 regions, and depending on which region they get
certification for they will have then programmed in the values
required for regulatory on the CTLs. The EEPROM would be configured
for the region the card was being tested for.

> Guess it's time to go find a hack to over-ride eeprom
> settings :(

Good luck with support from anyone for any further questions ;) [1].
The real solution to these issues is for regulatory agencies to start
warming up to the idea about dynamic regulatory selection but for this
you will also then need to ensure each card gets properly tested for
each regulatory region -- or we'd have to restrict the card to work in
beaconing mode only for the CTLs it was tested for.

Anyway, this will take some time but it is the path I think we need to
take. In the meantime the only thing you can do with world roaming
cards then is to scan prior to using a beaconing mode of operation.
That will enable beacon hints [2] which will enable beaconing on
non-DFS channels.

[1] http://wireless.kernel.org/en/developers/Regulatory/CRDA#Helping_compliance_by_allowing_to_change_regulatory_domains
[2] http://wireless.kernel.org/en/developers/Regulatory/processing_rules#Beacon_hints

  Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/23/2011 01:25 PM, Luis R. Rodriguez wrote:
> On Mon, May 23, 2011 at 1:09 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> Makes it basically useless as a 5Ghz AP though, eh?
>
> Um yup. The card is a world roaming card... not an AP card. For AP
> mode of functionality vendors have to go through a regulatory test
> specific to 3 regions, and depending on which region they get
> certification for they will have then programmed in the values
> required for regulatory on the CTLs. The EEPROM would be configured
> for the region the card was being tested for.

Well, if you have an AP on a 5Ghz channel, and associate a station
interface, that one channel becomes
usable, and then you can start hostapd, as far as I can tell.
You just can't use an un-used channel, which is of course
a pain if you want to do some 5Ghz AP testing on a clean
channel!

>> Guess it's time to go find a hack to over-ride eeprom
>> settings :(
>
> Good luck with support from anyone for any further questions ;) [1].

I can certainly disable the module parameter and have it bug for bug
compatible with upstream code.  I'm not going to
write to the eeprom or anything funny like that.

> The real solution to these issues is for regulatory agencies to start
> warming up to the idea about dynamic regulatory selection but for this
> you will also then need to ensure each card gets properly tested for
> each regulatory region -- or we'd have to restrict the card to work in

What kinds of things could fail in one region and not
another?  Are there any known regions of the world where
the AR9380 actually fails to function in any mode?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Mon, May 23, 2011 at 1:51 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 05/23/2011 01:25 PM, Luis R. Rodriguez wrote:
>>
>> On Mon, May 23, 2011 at 1:09 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>>>
>>> Makes it basically useless as a 5Ghz AP though, eh?
>>
>> Um yup. The card is a world roaming card... not an AP card. For AP
>> mode of functionality vendors have to go through a regulatory test
>> specific to 3 regions, and depending on which region they get
>> certification for they will have then programmed in the values
>> required for regulatory on the CTLs. The EEPROM would be configured
>> for the region the card was being tested for.
>
> Well, if you have an AP on a 5Ghz channel, and associate a station
> interface, that one channel becomes
> usable, and then you can start hostapd, as far as I can tell.
> You just can't use an un-used channel, which is of course
> a pain if you want to do some 5Ghz AP testing on a clean
> channel!

You don't even need to associate, you just need to scan, that's it. It
is a pain to test AP functionality but that is not how vendors test AP
functionality -- remember you are using a world roaming card, the fact
that you can even get away with beaconing modes of operation on some
channels is actually a feature.

The issue here comes from the fact that people think using AP mode of
functionality is a freedom they are entitled to with any 802.11 card
on any channel. Its obviously more complicated than that and figuring
out a proper way to do this is part of our own effort to enable APs
with Linux properly and in a regulatory compliant manner.

>>> Guess it's time to go find a hack to over-ride eeprom
>>> settings :(
>>
>> Good luck with support from anyone for any further questions ;) [1].
>
> I can certainly disable the module parameter and have it bug for bug
> compatible with upstream code.  I'm not going to
> write to the eeprom or anything funny like that.

I'm just letting you know, I nor a lot of developers approve of
promoting code which goes out of regulatory compliance [1]

[1] http://wireless.kernel.org/en/developers/Regulatory/statement

Understanding the regulatory considerations and actually trying to
find decent solutions is the hard part, but I do believe solutions are
possible, they just take time. The dynamic regulatory selection thing
I think will be the future we need a tight solution covering all
grounds of the calibration and CTL process at least for Atheros cards.

>> The real solution to these issues is for regulatory agencies to start
>> warming up to the idea about dynamic regulatory selection but for this
>> you will also then need to ensure each card gets properly tested for
>> each regulatory region -- or we'd have to restrict the card to work in
>
> What kinds of things could fail in one region and not
> another?

Atheros cards are optimized to output as much power in the middle area
of a spectrum, towards the ends of the spectrum regulatory agencies
sometimes require a bit tighter power constraints and cards are
required to meet certain power curve constraints. This is one of the
reasons for the EEPROM CTLs on the Atheros cards. This is one example
of such considerations.

> Are there any known regions of the world where
> the AR9380 actually fails to function in any mode?

Huh? AR9380 will work in any region so long as its tested for that
region and the CTLs get programmed as such.

  Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/23/2011 01:59 PM, Luis R. Rodriguez wrote:
> On Mon, May 23, 2011 at 1:51 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 05/23/2011 01:25 PM, Luis R. Rodriguez wrote:
>>>
>>> On Mon, May 23, 2011 at 1:09 PM, Ben Greear<greearb@candelatech.com>
>>>   wrote:
>>>>
>>>> Makes it basically useless as a 5Ghz AP though, eh?
>>>
>>> Um yup. The card is a world roaming card... not an AP card. For AP
>>> mode of functionality vendors have to go through a regulatory test
>>> specific to 3 regions, and depending on which region they get
>>> certification for they will have then programmed in the values
>>> required for regulatory on the CTLs. The EEPROM would be configured
>>> for the region the card was being tested for.
>>
>> Well, if you have an AP on a 5Ghz channel, and associate a station
>> interface, that one channel becomes
>> usable, and then you can start hostapd, as far as I can tell.
>> You just can't use an un-used channel, which is of course
>> a pain if you want to do some 5Ghz AP testing on a clean
>> channel!
>
> You don't even need to associate, you just need to scan, that's it. It
> is a pain to test AP functionality but that is not how vendors test AP
> functionality -- remember you are using a world roaming card, the fact
> that you can even get away with beaconing modes of operation on some
> channels is actually a feature.
>
> The issue here comes from the fact that people think using AP mode of
> functionality is a freedom they are entitled to with any 802.11 card
> on any channel. Its obviously more complicated than that and figuring
> out a proper way to do this is part of our own effort to enable APs
> with Linux properly and in a regulatory compliant manner.

Do you know of any 3x3 AR9380 NICs that can be used
as 5Ghz APs w/out regdomain hacks?  Sparklan was the only NIC I found, and
I didn't notice any way to order a specific regdomain
on the NIC.

>>> The real solution to these issues is for regulatory agencies to start
>>> warming up to the idea about dynamic regulatory selection but for this
>>> you will also then need to ensure each card gets properly tested for
>>> each regulatory region -- or we'd have to restrict the card to work in
>>
>> What kinds of things could fail in one region and not
>> another?
>
> Atheros cards are optimized to output as much power in the middle area
> of a spectrum, towards the ends of the spectrum regulatory agencies
> sometimes require a bit tighter power constraints and cards are
> required to meet certain power curve constraints. This is one of the
> reasons for the EEPROM CTLs on the Atheros cards. This is one example
> of such considerations.
>
>>   Are there any known regions of the world where
>> the AR9380 actually fails to function in any mode?
>
> Huh? AR9380 will work in any region so long as its tested for that
> region and the CTLs get programmed as such.

Testing doesn't make something work, it just makes sure that it
does work.  Now, programming the CTLs sounds like something important.
Is there any way to tell if a NIC is properly programmed for a particular
region, or is each brand/revision programmed independently?

Since it *is* possible to start an AP on a channel with existing AP,
I assume that the NIC must be able to handle this properly..or is
that ability to start on a scanned channel just a bug?  (Please
don't fix it, if it is :P)

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Mon, May 23, 2011 at 2:19 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 05/23/2011 01:59 PM, Luis R. Rodriguez wrote:
>>
>> On Mon, May 23, 2011 at 1:51 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>>>
>>> On 05/23/2011 01:25 PM, Luis R. Rodriguez wrote:
>>>>
>>>> On Mon, May 23, 2011 at 1:09 PM, Ben Greear<greearb@candelatech.com>
>>>>  wrote:
>>>>>
>>>>> Makes it basically useless as a 5Ghz AP though, eh?
>>>>
>>>> Um yup. The card is a world roaming card... not an AP card. For AP
>>>> mode of functionality vendors have to go through a regulatory test
>>>> specific to 3 regions, and depending on which region they get
>>>> certification for they will have then programmed in the values
>>>> required for regulatory on the CTLs. The EEPROM would be configured
>>>> for the region the card was being tested for.
>>>
>>> Well, if you have an AP on a 5Ghz channel, and associate a station
>>> interface, that one channel becomes
>>> usable, and then you can start hostapd, as far as I can tell.
>>> You just can't use an un-used channel, which is of course
>>> a pain if you want to do some 5Ghz AP testing on a clean
>>> channel!
>>
>> You don't even need to associate, you just need to scan, that's it. It
>> is a pain to test AP functionality but that is not how vendors test AP
>> functionality -- remember you are using a world roaming card, the fact
>> that you can even get away with beaconing modes of operation on some
>> channels is actually a feature.
>>
>> The issue here comes from the fact that people think using AP mode of
>> functionality is a freedom they are entitled to with any 802.11 card
>> on any channel. Its obviously more complicated than that and figuring
>> out a proper way to do this is part of our own effort to enable APs
>> with Linux properly and in a regulatory compliant manner.
>
> Do you know of any 3x3 AR9380 NICs that can be used
> as 5Ghz APs w/out regdomain hacks?

802.11 cards that can be used as APs would be cards programmed for
certain regions, there is no way around it. You can use world roaming
cards but again, that will not get you immediate beaconing mode of
operation on certain channels unless you scan and find a beacon from
an AP.

> Sparklan was the only NIC I found, and
> I didn't notice any way to order a specific regdomain
> on the NIC.

Try calling and see if they can do the regulatory testing for you and
programming of the card's CTLs for you. Not sure what else to
recommend.

>>>> The real solution to these issues is for regulatory agencies to start
>>>> warming up to the idea about dynamic regulatory selection but for this
>>>> you will also then need to ensure each card gets properly tested for
>>>> each regulatory region -- or we'd have to restrict the card to work in
>>>
>>> What kinds of things could fail in one region and not
>>> another?
>>
>> Atheros cards are optimized to output as much power in the middle area
>> of a spectrum, towards the ends of the spectrum regulatory agencies
>> sometimes require a bit tighter power constraints and cards are
>> required to meet certain power curve constraints. This is one of the
>> reasons for the EEPROM CTLs on the Atheros cards. This is one example
>> of such considerations.
>>
>>>  Are there any known regions of the world where
>>> the AR9380 actually fails to function in any mode?
>>
>> Huh? AR9380 will work in any region so long as its tested for that
>> region and the CTLs get programmed as such.
>
> Testing doesn't make something work, it just makes sure that it
> does work.  Now, programming the CTLs sounds like something important.
> Is there any way to tell if a NIC is properly programmed for a particular
> region, or is each brand/revision programmed independently?

The card's EEPROM tells us the CTLs that can be used. So a card with a
regulatory domain for the US will be usable for APs in any other
country that also uses the CTLs for that CTL region. Some cards may be
programmed in the EEPROM with more than one CTL and the only way to
find that out is to to some inspection of the EEPROM, otherwise the
values will be high, yes high, not low. So reprogramming the EEPROM
with a new country will not simply comply, you'd have then test the
region as well and write the CTLs for that region.

> Since it *is* possible to start an AP on a channel with existing AP,
> I assume that the NIC must be able to handle this properly..or is
> that ability to start on a scanned channel just a bug?  (Please
> don't fix it, if it is :P)

It a feature, AP functionality is allowed on that channel on a world
roaming card given that no CTL is present so the lower regulatory
value, from CRDA, is used instead of the CTL value.

 Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/23/2011 02:28 PM, Luis R. Rodriguez wrote:
> On Mon, May 23, 2011 at 2:19 PM, Ben Greear<greearb@candelatech.com>  wrote:

>> Since it *is* possible to start an AP on a channel with existing AP,
>> I assume that the NIC must be able to handle this properly..or is
>> that ability to start on a scanned channel just a bug?  (Please
>> don't fix it, if it is :P)
>
> It a feature, AP functionality is allowed on that channel on a world
> roaming card given that no CTL is present so the lower regulatory
> value, from CRDA, is used instead of the CTL value.

So as long as you have a functional CRDA and do not mis-represent
your country with 'iw reg set', is there any way to
actually get the system out of spec if you use "eeprom" reg-domain of 0x0?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Mon, May 23, 2011 at 2:38 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 05/23/2011 02:28 PM, Luis R. Rodriguez wrote:
>>
>> On Mon, May 23, 2011 at 2:19 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>
>>> Since it *is* possible to start an AP on a channel with existing AP,
>>> I assume that the NIC must be able to handle this properly..or is
>>> that ability to start on a scanned channel just a bug?  (Please
>>> don't fix it, if it is :P)
>>
>> It a feature, AP functionality is allowed on that channel on a world
>> roaming card given that no CTL is present so the lower regulatory
>> value, from CRDA, is used instead of the CTL value.
>
> So as long as you have a functional CRDA and do not mis-represent
> your country with 'iw reg set',

Atheros cards have an EEPROM value for a regulatory domain which is
always used, regardless of what you tell cfg80211 with 'iw reg set',
'iw reg set' will just help compliance further.

> is there any way to
> actually get the system out of spec if you use "eeprom" reg-domain of 0x0?

No. You can only do this by trying to take the card out of compliance
purposely or unknowingly in software.

 Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Mon, May 23, 2011 at 2:42 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:

> No. You can only do this by trying to take the card out of compliance
> purposely or unknowingly in software.

Oh and my point was that "regulatory hacks" fit this description.

  Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/23/2011 02:46 PM, Luis R. Rodriguez wrote:
> On Mon, May 23, 2011 at 2:42 PM, Luis R. Rodriguez<mcgrof@gmail.com>  wrote:
>
>> No. You can only do this by trying to take the card out of compliance
>> purposely or unknowingly in software.
>
> Oh and my point was that "regulatory hacks" fit this description.

Ok.  I believe you are right in general, but I can't see how enabling
a device to work on a non-scanned channel can break something, if
it is perfectly legal and appropriate for there to be an AP on that
scanned channel.  In other words, if I change my Netgear to be on channel
48, scanned it, and then created a VAP on that channel, that is OK with
un-hacked regdomain stuff, but if instead I change regdomain to 0x0
and use channel 48 without re-configuring my Netgear, somehow that
suddenly causes issues?

At any rate, all I really wanted to do was tie-break an off the
shelf AP that appeared to cause ath9k clients to silently be
unable to ARP after a while.  I have something that appears functional
now, so back to real work.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Mon, May 23, 2011 at 2:59 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 05/23/2011 02:46 PM, Luis R. Rodriguez wrote:
>>
>> On Mon, May 23, 2011 at 2:42 PM, Luis R. Rodriguez<mcgrof@gmail.com>
>>  wrote:
>>
>>> No. You can only do this by trying to take the card out of compliance
>>> purposely or unknowingly in software.
>>
>> Oh and my point was that "regulatory hacks" fit this description.
>
> Ok.  I believe you are right in general, but I can't see how enabling
> a device to work on a non-scanned channel can break something,

If a card is world roaming, how else on earth without seeing a beacon
will you know if you can initiate radiation on that channel?

> if it is perfectly legal and appropriate for there to be an AP on that
> scanned channel.

Agreed! In fact I'd go so far as to say that if you have multiple
802.11 cards they should be able to share the same beacon hints, and
in fact -- this is what cfg80211 does ;)

> In other words, if I change my Netgear to be on channel
> 48, scanned it, and then created a VAP on that channel, that is OK with
> un-hacked regdomain stuff, but if instead I change regdomain to 0x0
> and use channel 48 without re-configuring my Netgear, somehow that
> suddenly causes issues?

For Atheros EEPROM 0x0 is designed for usage for the US:

http://wireless.kernel.org/en/users/Drivers/ath#The_0x0_regulatory_domain

This is not a world regulatory domain. Some users / customers have
believed that programming the regulatory domain to 0x0 lets people
pick their own regulatory domain in software. This is not the intent
behind this regulatory domain, if a vendor is selling 802.11 cards
they simply need to go through regulatory testing for a card and then
program both the EEPROM / CTLs for the cards, if they do something
else let them sort that out through Atheros and their own support team
but as far as end users are concerned and upstream code the 0x0
regulatory domain will always simply map the the US regulatory domain.

> At any rate, all I really wanted to do was tie-break an off the
> shelf AP that appeared to cause ath9k clients to silently be
> unable to ARP after a while.  I have something that appears functional
> now, so back to real work.

:) Cool good luck!

  Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/23/2011 03:15 PM, Luis R. Rodriguez wrote:
> On Mon, May 23, 2011 at 2:59 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 05/23/2011 02:46 PM, Luis R. Rodriguez wrote:
>>>
>>> On Mon, May 23, 2011 at 2:42 PM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>   wrote:
>>>
>>>> No. You can only do this by trying to take the card out of compliance
>>>> purposely or unknowingly in software.
>>>
>>> Oh and my point was that "regulatory hacks" fit this description.
>>
>> Ok.  I believe you are right in general, but I can't see how enabling
>> a device to work on a non-scanned channel can break something,
>
> If a card is world roaming, how else on earth without seeing a beacon
> will you know if you can initiate radiation on that channel?

I have a strong personal sense of location, and I'm 100% sure that
I'm in the US.  So, the the computer could listen to it's human
and just trust that I know WTF I am asking for!

It may currently be impossible for vendors to explicitly support
this due to regulatory domains that assume users are evil and/or
stupid and not to be trusted to know their current location,
but please don't pretend that receiving a beacon is rock solid
evidence of a channel's availability:  It only means that someone
else that set up the AP thinks it's available for use.

>> if it is perfectly legal and appropriate for there to be an AP on that
>> scanned channel.
>
> Agreed! In fact I'd go so far as to say that if you have multiple
> 802.11 cards they should be able to share the same beacon hints, and
> in fact -- this is what cfg80211 does ;)
>
>> In other words, if I change my Netgear to be on channel
>> 48, scanned it, and then created a VAP on that channel, that is OK with
>> un-hacked regdomain stuff, but if instead I change regdomain to 0x0
>> and use channel 48 without re-configuring my Netgear, somehow that
>> suddenly causes issues?
>
> For Atheros EEPROM 0x0 is designed for usage for the US:

Good..that's all I really wanted:  My NIC to support my
location w/out undue complaint or limitations.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Mon, May 23, 2011 at 9:48 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 05/23/2011 03:15 PM, Luis R. Rodriguez wrote:
>>
>> On Mon, May 23, 2011 at 2:59 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>>>
>>> On 05/23/2011 02:46 PM, Luis R. Rodriguez wrote:
>>>>
>>>> On Mon, May 23, 2011 at 2:42 PM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>>  wrote:
>>>>
>>>>> No. You can only do this by trying to take the card out of compliance
>>>>> purposely or unknowingly in software.
>>>>
>>>> Oh and my point was that "regulatory hacks" fit this description.
>>>
>>> Ok.  I believe you are right in general, but I can't see how enabling
>>> a device to work on a non-scanned channel can break something,
>>
>> If a card is world roaming, how else on earth without seeing a beacon
>> will you know if you can initiate radiation on that channel?
>
> I have a strong personal sense of location, and I'm 100% sure that
> I'm in the US.  So, the the computer could listen to it's human
> and just trust that I know WTF I am asking for!
>
> It may currently be impossible for vendors to explicitly support
> this due to regulatory domains that assume users are evil and/or
> stupid and not to be trusted to know their current location,
> but please don't pretend that receiving a beacon is rock solid
> evidence of a channel's availability:  It only means that someone
> else that set up the AP thinks it's available for use.

I agree completely but as you noted the issues are not with us, its
with regulatory agencies who have explicitly mentioned user's
intervention in location information and wanting the user out of the
equation [1]. The more tangible solution then is to work on automatic
locationing mechanisms which we can rely on and prove to regulatory
agencies are solid. Slowly that's the path I believe we should take.
One step at a time.

[1] http://wireless.kernel.org/en/developers/Regulatory/CRDA#Helping_compliance_by_allowing_to_change_regulatory_domains

>>> if it is perfectly legal and appropriate for there to be an AP on that
>>> scanned channel.
>>
>> Agreed! In fact I'd go so far as to say that if you have multiple
>> 802.11 cards they should be able to share the same beacon hints, and
>> in fact -- this is what cfg80211 does ;)
>>
>>> In other words, if I change my Netgear to be on channel
>>> 48, scanned it, and then created a VAP on that channel, that is OK with
>>> un-hacked regdomain stuff, but if instead I change regdomain to 0x0
>>> and use channel 48 without re-configuring my Netgear, somehow that
>>> suddenly causes issues?
>>
>> For Atheros EEPROM 0x0 is designed for usage for the US:
>
> Good..that's all I really wanted:  My NIC to support my
> location w/out undue complaint or limitations.

Enjoy :)

  Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Brian Prodoehl]

On Mon, May 23, 2011 at 2:52 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 05/23/2011 11:39 AM, Ben Greear wrote:
>>
>> On 05/23/2011 09:54 AM, Ben Greear wrote:
>>>
>>> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>>>>
>>>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>>>> wrote:
>>>>>
>>>>> This is on 2.6.39-wl+
>>>>>
>>>>> All the 5Ghz channels are showing as passive scanning, which
>>>>> makes them unusable for APs if nothing else.
>>>>
>>>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>>>> wireless-testing just brought the card up as station mode.
>>>
>>> Most of my systems show the same, at least most of the time.
>>>
>>>
>>>>> Any idea why this is happening?
>>>>
>>>> don't know, may be regulatory.
>>>
>>> After a reboot and an idle weekend, mine also look normal.
>>> So, it's something transient it appears.
>>
>> Err, I mis-spoke..the 9380 system still shows passive
>> scanning everywhere...
>
> Busted one:
>
> ath: EEPROM regdomain: 0x6a
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: 00
> ath: Regpair used: 0x6a
>
> cfg80211: Calling CRDA for country: US
> cfg80211: Regulatory domain changed to country: US
> cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
> cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>
>
> Bleh, seems my Sparklan 127 NIC is set to world-roam :(
>
> What a total pain in the arse!
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com


Strange.  This is what I get out of my WPEA-127N:

ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a

Here's how my 5GHz channels look:
		Frequencies:
			* 5180 MHz [36] (17.0 dBm)
			* 5200 MHz [40] (17.0 dBm)
			* 5220 MHz [44] (17.0 dBm)
			* 5240 MHz [48] (17.0 dBm)
			* 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5600 MHz [120] (disabled)
			* 5620 MHz [124] (disabled)
			* 5640 MHz [128] (disabled)
			* 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
			* 5745 MHz [149] (30.0 dBm)
			* 5765 MHz [153] (30.0 dBm)
			* 5785 MHz [157] (30.0 dBm)
			* 5805 MHz [161] (30.0 dBm)
			* 5825 MHz [165] (30.0 dBm)

This is running 2.6.37 with compat-wireless from sometime in March,
probably.  I'll try with 2.6.39 and latest compat-wireless when I get
a chance.

-Brian

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Tue, May 24, 2011 at 6:00 AM, Brian Prodoehl <bprodoehl@gmail.com> wrote:
> On Mon, May 23, 2011 at 2:52 PM, Ben Greear <greearb@candelatech.com> wrote:
>> On 05/23/2011 11:39 AM, Ben Greear wrote:
>>>
>>> On 05/23/2011 09:54 AM, Ben Greear wrote:
>>>>
>>>> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>>>>>
>>>>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>>>>> wrote:
>>>>>>
>>>>>> This is on 2.6.39-wl+
>>>>>>
>>>>>> All the 5Ghz channels are showing as passive scanning, which
>>>>>> makes them unusable for APs if nothing else.
>>>>>
>>>>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>>>>> wireless-testing just brought the card up as station mode.
>>>>
>>>> Most of my systems show the same, at least most of the time.
>>>>
>>>>
>>>>>> Any idea why this is happening?
>>>>>
>>>>> don't know, may be regulatory.
>>>>
>>>> After a reboot and an idle weekend, mine also look normal.
>>>> So, it's something transient it appears.
>>>
>>> Err, I mis-spoke..the 9380 system still shows passive
>>> scanning everywhere...
>>
>> Busted one:
>>
>> ath: EEPROM regdomain: 0x6a
>> ath: EEPROM indicates we should expect a direct regpair map
>> ath: Country alpha2 being used: 00
>> ath: Regpair used: 0x6a
>>
>> cfg80211: Calling CRDA for country: US
>> cfg80211: Regulatory domain changed to country: US
>> cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain,
>> max_eirp)
>> cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>> cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>> cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>
>>
>> Bleh, seems my Sparklan 127 NIC is set to world-roam :(
>>
>> What a total pain in the arse!
>> Ben
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>
>
> Strange.  This is what I get out of my WPEA-127N:
>
> ath: EEPROM regdomain: 0x0
> ath: EEPROM indicates default country code should be used
> ath: doing EEPROM country->regdmn map search
> ath: country maps to regdmn code: 0x3a
> ath: Country alpha2 being used: US
> ath: Regpair used: 0x3a
>
> Here's how my 5GHz channels look:
>                Frequencies:
>                        * 5180 MHz [36] (17.0 dBm)
>                        * 5200 MHz [40] (17.0 dBm)
>                        * 5220 MHz [44] (17.0 dBm)
>                        * 5240 MHz [48] (17.0 dBm)
>                        * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5600 MHz [120] (disabled)
>                        * 5620 MHz [124] (disabled)
>                        * 5640 MHz [128] (disabled)
>                        * 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5745 MHz [149] (30.0 dBm)
>                        * 5765 MHz [153] (30.0 dBm)
>                        * 5785 MHz [157] (30.0 dBm)
>                        * 5805 MHz [161] (30.0 dBm)
>                        * 5825 MHz [165] (30.0 dBm)
>
> This is running 2.6.37 with compat-wireless from sometime in March,
> probably.  I'll try with 2.6.39 and latest compat-wireless when I get
> a chance.

What's the problem? You ahve DFS requirements on the channels listed
with DFS. You can initiate radiation on the others. We lack master
support for DFS yet so you cannot initiate radiation on those
channels.

  Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Brian Prodoehl]

On Tue, May 24, 2011 at 9:11 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Tue, May 24, 2011 at 6:00 AM, Brian Prodoehl <bprodoehl@gmail.com> wrote:
>> On Mon, May 23, 2011 at 2:52 PM, Ben Greear <greearb@candelatech.com> wrote:
>>> On 05/23/2011 11:39 AM, Ben Greear wrote:
>>>>
>>>> On 05/23/2011 09:54 AM, Ben Greear wrote:
>>>>>
>>>>> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>>>>>>
>>>>>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> This is on 2.6.39-wl+
>>>>>>>
>>>>>>> All the 5Ghz channels are showing as passive scanning, which
>>>>>>> makes them unusable for APs if nothing else.
>>>>>>
>>>>>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>>>>>> wireless-testing just brought the card up as station mode.
>>>>>
>>>>> Most of my systems show the same, at least most of the time.
>>>>>
>>>>>
>>>>>>> Any idea why this is happening?
>>>>>>
>>>>>> don't know, may be regulatory.
>>>>>
>>>>> After a reboot and an idle weekend, mine also look normal.
>>>>> So, it's something transient it appears.
>>>>
>>>> Err, I mis-spoke..the 9380 system still shows passive
>>>> scanning everywhere...
>>>
>>> Busted one:
>>>
>>> ath: EEPROM regdomain: 0x6a
>>> ath: EEPROM indicates we should expect a direct regpair map
>>> ath: Country alpha2 being used: 00
>>> ath: Regpair used: 0x6a
>>>
>>> cfg80211: Calling CRDA for country: US
>>> cfg80211: Regulatory domain changed to country: US
>>> cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain,
>>> max_eirp)
>>> cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>>> cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>>> cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>>
>>>
>>> Bleh, seems my Sparklan 127 NIC is set to world-roam :(
>>>
>>> What a total pain in the arse!
>>> Ben
>>>
>>> --
>>> Ben Greear <greearb@candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>> Strange.  This is what I get out of my WPEA-127N:
>>
>> ath: EEPROM regdomain: 0x0
>> ath: EEPROM indicates default country code should be used
>> ath: doing EEPROM country->regdmn map search
>> ath: country maps to regdmn code: 0x3a
>> ath: Country alpha2 being used: US
>> ath: Regpair used: 0x3a
>>
>> Here's how my 5GHz channels look:
>>                Frequencies:
>>                        * 5180 MHz [36] (17.0 dBm)
>>                        * 5200 MHz [40] (17.0 dBm)
>>                        * 5220 MHz [44] (17.0 dBm)
>>                        * 5240 MHz [48] (17.0 dBm)
>>                        * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5600 MHz [120] (disabled)
>>                        * 5620 MHz [124] (disabled)
>>                        * 5640 MHz [128] (disabled)
>>                        * 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5745 MHz [149] (30.0 dBm)
>>                        * 5765 MHz [153] (30.0 dBm)
>>                        * 5785 MHz [157] (30.0 dBm)
>>                        * 5805 MHz [161] (30.0 dBm)
>>                        * 5825 MHz [165] (30.0 dBm)
>>
>> This is running 2.6.37 with compat-wireless from sometime in March,
>> probably.  I'll try with 2.6.39 and latest compat-wireless when I get
>> a chance.
>
> What's the problem? You ahve DFS requirements on the channels listed
> with DFS. You can initiate radiation on the others. We lack master
> support for DFS yet so you cannot initiate radiation on those
> channels.
>
>  Luis

What I'm seeing is exactly what I would expect.  What Ben is seeing,
with the same model card, is different (he has passive scanning set on
all 5GHz channels).  It looks like SparkLan changed the EEPROM
regdomain on the WPEA-127N from 0 to 0x6a (I bought my cards a month
or so before he did).

-Brian

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Luis R. Rodriguez]

On Tue, May 24, 2011 at 6:18 AM, Brian Prodoehl <bprodoehl@gmail.com> wrote:
> On Tue, May 24, 2011 at 9:11 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Tue, May 24, 2011 at 6:00 AM, Brian Prodoehl <bprodoehl@gmail.com> wrote:
>>> On Mon, May 23, 2011 at 2:52 PM, Ben Greear <greearb@candelatech.com> wrote:
>>>> On 05/23/2011 11:39 AM, Ben Greear wrote:
>>>>>
>>>>> On 05/23/2011 09:54 AM, Ben Greear wrote:
>>>>>>
>>>>>> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>>>>>>>
>>>>>>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> This is on 2.6.39-wl+
>>>>>>>>
>>>>>>>> All the 5Ghz channels are showing as passive scanning, which
>>>>>>>> makes them unusable for APs if nothing else.
>>>>>>>
>>>>>>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>>>>>>> wireless-testing just brought the card up as station mode.
>>>>>>
>>>>>> Most of my systems show the same, at least most of the time.
>>>>>>
>>>>>>
>>>>>>>> Any idea why this is happening?
>>>>>>>
>>>>>>> don't know, may be regulatory.
>>>>>>
>>>>>> After a reboot and an idle weekend, mine also look normal.
>>>>>> So, it's something transient it appears.
>>>>>
>>>>> Err, I mis-spoke..the 9380 system still shows passive
>>>>> scanning everywhere...
>>>>
>>>> Busted one:
>>>>
>>>> ath: EEPROM regdomain: 0x6a
>>>> ath: EEPROM indicates we should expect a direct regpair map
>>>> ath: Country alpha2 being used: 00
>>>> ath: Regpair used: 0x6a
>>>>
>>>> cfg80211: Calling CRDA for country: US
>>>> cfg80211: Regulatory domain changed to country: US
>>>> cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain,
>>>> max_eirp)
>>>> cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>>>> cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>>>> cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>>> cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>>> cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>>> cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>>>
>>>>
>>>> Bleh, seems my Sparklan 127 NIC is set to world-roam :(
>>>>
>>>> What a total pain in the arse!
>>>> Ben
>>>>
>>>> --
>>>> Ben Greear <greearb@candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>>
>>> Strange.  This is what I get out of my WPEA-127N:
>>>
>>> ath: EEPROM regdomain: 0x0
>>> ath: EEPROM indicates default country code should be used
>>> ath: doing EEPROM country->regdmn map search
>>> ath: country maps to regdmn code: 0x3a
>>> ath: Country alpha2 being used: US
>>> ath: Regpair used: 0x3a
>>>
>>> Here's how my 5GHz channels look:
>>>                Frequencies:
>>>                        * 5180 MHz [36] (17.0 dBm)
>>>                        * 5200 MHz [40] (17.0 dBm)
>>>                        * 5220 MHz [44] (17.0 dBm)
>>>                        * 5240 MHz [48] (17.0 dBm)
>>>                        * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5600 MHz [120] (disabled)
>>>                        * 5620 MHz [124] (disabled)
>>>                        * 5640 MHz [128] (disabled)
>>>                        * 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>>                        * 5745 MHz [149] (30.0 dBm)
>>>                        * 5765 MHz [153] (30.0 dBm)
>>>                        * 5785 MHz [157] (30.0 dBm)
>>>                        * 5805 MHz [161] (30.0 dBm)
>>>                        * 5825 MHz [165] (30.0 dBm)
>>>
>>> This is running 2.6.37 with compat-wireless from sometime in March,
>>> probably.  I'll try with 2.6.39 and latest compat-wireless when I get
>>> a chance.
>>
>> What's the problem? You ahve DFS requirements on the channels listed
>> with DFS. You can initiate radiation on the others. We lack master
>> support for DFS yet so you cannot initiate radiation on those
>> channels.
>>
>>  Luis
>
> What I'm seeing is exactly what I would expect.  What Ben is seeing,
> with the same model card, is different (he has passive scanning set on
> all 5GHz channels).  It looks like SparkLan changed the EEPROM
> regdomain on the WPEA-127N from 0 to 0x6a (I bought my cards a month
> or so before he did).

Call and complain?

  Luis

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Mohammed Shafi]

On Tue, May 24, 2011 at 6:41 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Tue, May 24, 2011 at 6:00 AM, Brian Prodoehl <bprodoehl@gmail.com> wrote:
>> On Mon, May 23, 2011 at 2:52 PM, Ben Greear <greearb@candelatech.com> wrote:
>>> On 05/23/2011 11:39 AM, Ben Greear wrote:
>>>>
>>>> On 05/23/2011 09:54 AM, Ben Greear wrote:
>>>>>
>>>>> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>>>>>>
>>>>>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> This is on 2.6.39-wl+
>>>>>>>
>>>>>>> All the 5Ghz channels are showing as passive scanning, which
>>>>>>> makes them unusable for APs if nothing else.
>>>>>>
>>>>>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>>>>>> wireless-testing just brought the card up as station mode.
>>>>>
>>>>> Most of my systems show the same, at least most of the time.
>>>>>
>>>>>
>>>>>>> Any idea why this is happening?
>>>>>>
>>>>>> don't know, may be regulatory.
>>>>>
>>>>> After a reboot and an idle weekend, mine also look normal.
>>>>> So, it's something transient it appears.
>>>>
>>>> Err, I mis-spoke..the 9380 system still shows passive
>>>> scanning everywhere...
>>>
>>> Busted one:
>>>
>>> ath: EEPROM regdomain: 0x6a
>>> ath: EEPROM indicates we should expect a direct regpair map
>>> ath: Country alpha2 being used: 00
>>> ath: Regpair used: 0x6a
>>>
>>> cfg80211: Calling CRDA for country: US
>>> cfg80211: Regulatory domain changed to country: US
>>> cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain,
>>> max_eirp)
>>> cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>>> cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>>> cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>>
>>>
>>> Bleh, seems my Sparklan 127 NIC is set to world-roam :(
>>>
>>> What a total pain in the arse!
>>> Ben
>>>
>>> --
>>> Ben Greear <greearb@candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>> Strange.  This is what I get out of my WPEA-127N:
>>
>> ath: EEPROM regdomain: 0x0
>> ath: EEPROM indicates default country code should be used
>> ath: doing EEPROM country->regdmn map search
>> ath: country maps to regdmn code: 0x3a
>> ath: Country alpha2 being used: US
>> ath: Regpair used: 0x3a
>>
>> Here's how my 5GHz channels look:
>>                Frequencies:
>>                        * 5180 MHz [36] (17.0 dBm)
>>                        * 5200 MHz [40] (17.0 dBm)
>>                        * 5220 MHz [44] (17.0 dBm)
>>                        * 5240 MHz [48] (17.0 dBm)
>>                        * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5600 MHz [120] (disabled)
>>                        * 5620 MHz [124] (disabled)
>>                        * 5640 MHz [128] (disabled)
>>                        * 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>>                        * 5745 MHz [149] (30.0 dBm)
>>                        * 5765 MHz [153] (30.0 dBm)
>>                        * 5785 MHz [157] (30.0 dBm)
>>                        * 5805 MHz [161] (30.0 dBm)
>>                        * 5825 MHz [165] (30.0 dBm)
>>
>> This is running 2.6.37 with compat-wireless from sometime in March,
>> probably.  I'll try with 2.6.39 and latest compat-wireless when I get
>> a chance.
>
> What's the problem? You ahve DFS requirements on the channels listed
> with DFS. You can initiate radiation on the others. We lack master
> support for DFS yet so you cannot initiate radiation on those
> channels.

Luis, I am also getting the same thing

[ 2500.117715] ath9k 0000:05:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 2500.117730] ath9k 0000:05:00.0: setting latency timer to 64
[ 2500.174053] ath: EEPROM regdomain: 0x0
[ 2500.174056] ath: EEPROM indicates default country code should be used
[ 2500.174057] ath: doing EEPROM country->regdmn map search
[ 2500.174059] ath: country maps to regdmn code: 0x3a
[ 2500.174061] ath: Country alpha2 being used: US
[ 2500.174062] ath: Regpair used: 0x3a




>
>  Luis
>



-- 
shafi

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Mohammed Shafi]

On Tue, May 24, 2011 at 6:30 PM, Brian Prodoehl <bprodoehl@gmail.com> wrote:
> On Mon, May 23, 2011 at 2:52 PM, Ben Greear <greearb@candelatech.com> wrote:
>> On 05/23/2011 11:39 AM, Ben Greear wrote:
>>>
>>> On 05/23/2011 09:54 AM, Ben Greear wrote:
>>>>
>>>> On 05/23/2011 04:28 AM, Mohammed Shafi wrote:
>>>>>
>>>>> On Sat, May 21, 2011 at 3:52 AM, Ben Greear<greearb@candelatech.com>
>>>>> wrote:
>>>>>>
>>>>>> This is on 2.6.39-wl+
>>>>>>
>>>>>> All the 5Ghz channels are showing as passive scanning, which
>>>>>> makes them unusable for APs if nothing else.
>>>>>
>>>>> for me channels 36,40,44,48 are ok in 5ghz. used the latest
>>>>> wireless-testing just brought the card up as station mode.
>>>>
>>>> Most of my systems show the same, at least most of the time.
>>>>
>>>>
>>>>>> Any idea why this is happening?
>>>>>
>>>>> don't know, may be regulatory.
>>>>
>>>> After a reboot and an idle weekend, mine also look normal.
>>>> So, it's something transient it appears.
>>>
>>> Err, I mis-spoke..the 9380 system still shows passive
>>> scanning everywhere...
>>
>> Busted one:
>>
>> ath: EEPROM regdomain: 0x6a
>> ath: EEPROM indicates we should expect a direct regpair map
>> ath: Country alpha2 being used: 00
>> ath: Regpair used: 0x6a
>>
>> cfg80211: Calling CRDA for country: US
>> cfg80211: Regulatory domain changed to country: US
>> cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain,
>> max_eirp)
>> cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>> cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>> cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>
>>
>> Bleh, seems my Sparklan 127 NIC is set to world-roam :(
>>
>> What a total pain in the arse!
>> Ben
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>
>
> Strange.  This is what I get out of my WPEA-127N:
>
> ath: EEPROM regdomain: 0x0
> ath: EEPROM indicates default country code should be used
> ath: doing EEPROM country->regdmn map search
> ath: country maps to regdmn code: 0x3a
> ath: Country alpha2 being used: US
> ath: Regpair used: 0x3a
>
> Here's how my 5GHz channels look:
>                Frequencies:
>                        * 5180 MHz [36] (17.0 dBm)
>                        * 5200 MHz [40] (17.0 dBm)
>                        * 5220 MHz [44] (17.0 dBm)
>                        * 5240 MHz [48] (17.0 dBm)
>                        * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5600 MHz [120] (disabled)
>                        * 5620 MHz [124] (disabled)
>                        * 5640 MHz [128] (disabled)
>                        * 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
>                        * 5745 MHz [149] (30.0 dBm)
>                        * 5765 MHz [153] (30.0 dBm)
>                        * 5785 MHz [157] (30.0 dBm)
>                        * 5805 MHz [161] (30.0 dBm)
>                        * 5825 MHz [165] (30.0 dBm)
>
> This is running 2.6.37 with compat-wireless from sometime in March,
> probably.  I'll try with 2.6.39 and latest compat-wireless when I get
> a chance.
>

I got the similar result with latest wireless testing

> -Brian
>



-- 
shafi

Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning

[Ben Greear]

On 05/24/2011 07:08 AM, Mohammed Shafi wrote:
> On Tue, May 24, 2011 at 6:30 PM, Brian Prodoehl<bprodoehl@gmail.com>  wrote:

>> This is running 2.6.37 with compat-wireless from sometime in March,
>> probably.  I'll try with 2.6.39 and latest compat-wireless when I get
>> a chance.
>>
>
> I got the similar result with latest wireless testing

I'm running wireless-testing as well.  I think the code is probably correct,
just that the NIC I bought happened to be programmed for a different regdomain
than 0x0.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com