All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@gmail.com>
To: Ben Greear <greearb@candelatech.com>
Cc: Mohammed Shafi <shafi.wireless@gmail.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: ath9k 9380: All 5Ghz channels flagged as passive-scanning
Date: Mon, 23 May 2011 14:28:31 -0700	[thread overview]
Message-ID: <BANLkTikSb-6Uh5jnEUD4wrGCKUNmrF3Zow@mail.gmail.com> (raw)
In-Reply-To: <4DDACF56.9070403@candelatech.com>

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

  reply	other threads:[~2011-05-23 21:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20 22:22 ath9k 9380: All 5Ghz channels flagged as passive-scanning Ben Greear
2011-05-23 11:28 ` Mohammed Shafi
2011-05-23 16:54   ` Ben Greear
2011-05-23 18:39     ` Ben Greear
2011-05-23 18:52       ` Ben Greear
2011-05-23 19:26         ` Luis R. Rodriguez
2011-05-23 20:09           ` Ben Greear
2011-05-23 20:25             ` Luis R. Rodriguez
2011-05-23 20:51               ` Ben Greear
2011-05-23 20:59                 ` Luis R. Rodriguez
2011-05-23 21:19                   ` Ben Greear
2011-05-23 21:28                     ` Luis R. Rodriguez [this message]
2011-05-23 21:38                       ` Ben Greear
2011-05-23 21:42                         ` Luis R. Rodriguez
2011-05-23 21:46                           ` Luis R. Rodriguez
2011-05-23 21:59                             ` Ben Greear
2011-05-23 22:15                               ` Luis R. Rodriguez
2011-05-24  4:48                                 ` Ben Greear
2011-05-24 11:33                                   ` Luis R. Rodriguez
2011-05-24 13:00         ` Brian Prodoehl
2011-05-24 13:11           ` Luis R. Rodriguez
2011-05-24 13:18             ` Brian Prodoehl
2011-05-24 21:39               ` Luis R. Rodriguez
2011-05-24 14:06             ` Mohammed Shafi
2011-05-24 14:08           ` Mohammed Shafi
2011-05-24 15:05             ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTikSb-6Uh5jnEUD4wrGCKUNmrF3Zow@mail.gmail.com \
    --to=mcgrof@gmail.com \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=shafi.wireless@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.