Adding custom channels to ath5k for researching purposes

Adding custom channels to ath5k for researching purposes

[Vadim]

Hello all! I have some problems using ath5k driver with Atheros (AR5414)
DCMA-86P2 mini-PCI modules.
I am developing DSRC/WAVE system for car to car communication based on 802.11p
standard.
DCMA-86P2 modules are designed to operate at 5GHz dedicated band (5,86-5,92GHz)

The first problem is that Linux shows that hardware works in 802.11a mode.
And "iw list"' shows only 802.11a allowed channels at frequencies: 5180-5825MHz.

By following Linux-wireless manual I installed latest kernel, kernel headers,
wireless-tools, iw, CRDA and verified that ath5k module is running.

I need to enable 802.11p standard frequencies. How can I accomplish this? I
found that CRDA is responsible for allowed channels. So, where can I get binary
frequency/channel database to use my hardware for researching purposes ? Is
there an alternative method to enable 802.11p frequencies by modifying ath5k
driver ?

Re: Adding custom channels to ath5k for researching purposes

[Bob Copeland]

On Thu, Nov 4, 2010 at 9:03 AM, Vadim <Vadims.Kurmis@gmail.com> wrote:
> I need to enable 802.11p standard frequencies. How can I accomplish this? I
> found that CRDA is responsible for allowed channels.

Partially -- the channel list is exported by the driver but CRDA
adds additional regulatory restrictions.  The driver also imposes
certain regulatory restrictions based on the EEPROM data.

> So, where can I get binary
> frequency/channel database to use my hardware for researching purposes ?

You can create your own database, but you may need to modify the driver to
disregard the EEPROM settings, with the usual disclaimers: we won't support
it and if it breaks you get to keep both pieces.

Also note that ath5k only advertises a partial channel list; you can
get more via all_channels=1 modparam.  We don't do this by default
because they make scanning take forever and exceed channel list limits
in netlink.

-- 
Bob Copeland %% www.bobcopeland.com

Re: Adding custom channels to ath5k for researching purposes

[wangqinlong]

I have the same problem ，I just want know how do you deal with it now，is it
works？
thanks~

Re: Adding custom channels to ath5k for researching purposes

[Luis R. Rodriguez]

On Thu, Nov 4, 2010 at 7:47 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Thu, Nov 4, 2010 at 9:03 AM, Vadim <Vadims.Kurmis@gmail.com> wrote:
>> I need to enable 802.11p standard frequencies. How can I accomplish this? I
>> found that CRDA is responsible for allowed channels.
>
> Partially -- the channel list is exported by the driver but CRDA
> adds additional regulatory restrictions.  The driver also imposes
> certain regulatory restrictions based on the EEPROM data.
>
>> So, where can I get binary
>> frequency/channel database to use my hardware for researching purposes ?
>
> You can create your own database, but you may need to modify the driver to
> disregard the EEPROM settings, with the usual disclaimers: we won't support
> it and if it breaks you get to keep both pieces.
>
> Also note that ath5k only advertises a partial channel list; you can
> get more via all_channels=1 modparam.  We don't do this by default
> because they make scanning take forever and exceed channel list limits
> in netlink.

I'm thinking it may make sense to add CONFIG_WIRELESS_EXPERT where we
can stuff some of this stuff under. It may be useful for other
regulatory testing / certification stuff.

  Luis

Re: Adding custom channels to ath5k for researching purposes

[Richard Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/08/12 10:50, Luis R. Rodriguez wrote:
> On Thu, Nov 4, 2010 at 7:47 AM, Bob Copeland <me@bobcopeland.com> wrote:
>> On Thu, Nov 4, 2010 at 9:03 AM, Vadim <Vadims.Kurmis@gmail.com> wrote:
>>> I need to enable 802.11p standard frequencies. How can I accomplish this? I
>>> found that CRDA is responsible for allowed channels.
>>
>> Partially -- the channel list is exported by the driver but CRDA
>> adds additional regulatory restrictions.  The driver also imposes
>> certain regulatory restrictions based on the EEPROM data.
>>
>>> So, where can I get binary
>>> frequency/channel database to use my hardware for researching purposes ?
>>
>> You can create your own database, but you may need to modify the driver to
>> disregard the EEPROM settings, with the usual disclaimers: we won't support
>> it and if it breaks you get to keep both pieces.
>>
>> Also note that ath5k only advertises a partial channel list; you can
>> get more via all_channels=1 modparam.  We don't do this by default
>> because they make scanning take forever and exceed channel list limits
>> in netlink.
> 
> I'm thinking it may make sense to add CONFIG_WIRELESS_EXPERT where we
> can stuff some of this stuff under. It may be useful for other
> regulatory testing / certification stuff.

+1

In my personal opinion an option like that which enables ONLY crda (or
obviously firmware for those intel guys) to enforce regulatory
compliance it would then be trivial for people who needed other
frequencies to modify their own personal wireless regdb.  Also this
keeps some manner of sanity as with an unmodified wireless regdb nothing
bad happens.

Anyway, my 0.02$

Thanks,
Rick

> 
>   Luis
> --
> 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPqTUvAAoJEKXdFCfdEflKMAAP/ReW3KZEv+ABsWmf2E+iLSex
E10zB2Nmr7lE7I9duECYfWxe9ahm6DFwp6FMD9AJkuxPa8n0K96fKe9PrfRJWi/R
40A78VsW4zTUSfM07IHdTk7ACjrP3G0z+9Wfyd8QcWesHfAhqWzyr3lh9XV0g3hk
LOQcFIwEU8vSTki9QiyVLqltBgtPkPfwQ6KsYdqb9TK2SmSjisKHS63myNHEPTQH
3Y7FO6drRsbCLsNXmMcSZITmFRSXHtYunH9gXwKtQEYH0coS7bdBAETeFHOo9xcO
7xG66ftILniMQ1fAUpASHATP1uT+qQaSX7eTNlerVTBNmF5zLJq+8obrYipvL4gn
0uy3ZOgeG1tUidYTLBUeCbozkkPYrnH6338WQyjHA145Jv9pjkv+TWG9DTwjIVXE
UNjZPG3GbQLx5rGFlFKKumxqHDM3RgwhfEwjIyHX0mJr/Ae9oypwR5TjFbGFazMN
vQBSZE60OcnoPKV2EqpCP5/IINGUjtNWCxeLSefHaO1nDzComH5wR2cbbBGWTJ8P
6v7N7unfexhybGQifWHDWgXrwvh+RQNDo+zaXmWU1Yys34ByhVShU2j5YmzbARav
9byhrxgY/ABIFOc/r86tDwRqZJpVpFKpP1/uUbAQYkMpYfsUajIJFq/piigCYNKs
X9pGsDRw9vpH//uGpCzT
=bfUG
-----END PGP SIGNATURE-----

Re: Adding custom channels to ath5k for researching purposes

[Bob Copeland]

On Tue, May 08, 2012 at 07:50:06AM -0700, Luis R. Rodriguez wrote:
> I'm thinking it may make sense to add CONFIG_WIRELESS_EXPERT where we
> can stuff some of this stuff under. It may be useful for other
> regulatory testing / certification stuff.

No objection here, so long as this kind of config opt wouldn't become
a dumping ground (cf. CONFIG_EMBEDDED).  "EXPERT" could mean different
things to different people.

I still like the idea of exporting more stuff to userspace and letting
CRDA handle the card-based restrictions, but ISTR you had reasons that
didn't work for everything.

-- 
Bob Copeland %% www.bobcopeland.com

Re: Adding custom channels to ath5k for researching purposes

[Luis R. Rodriguez]

On Tue, May 8, 2012 at 9:30 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Tue, May 08, 2012 at 07:50:06AM -0700, Luis R. Rodriguez wrote:
>> I'm thinking it may make sense to add CONFIG_WIRELESS_EXPERT where we
>> can stuff some of this stuff under. It may be useful for other
>> regulatory testing / certification stuff.
>
> No objection here, so long as this kind of config opt wouldn't become
> a dumping ground (cf. CONFIG_EMBEDDED).  "EXPERT" could mean different
> things to different people.

Well it should depend on CONFIG_EXPERT but yeah -- I was surprised to
learn recently even Ubuntu is shipping with CONFIG_EXPERT, so WTF.
Localizing the expert config to wireless might make more sense.

> I still like the idea of exporting more stuff to userspace and letting
> CRDA handle the card-based restrictions, but ISTR you had reasons that
> didn't work for everything.

What do you mean?

  Luis

Re: Adding custom channels to ath5k for researching purposes

[Bob Copeland]

On Tue, May 08, 2012 at 09:49:22AM -0700, Luis R. Rodriguez wrote:
> > I still like the idea of exporting more stuff to userspace and letting
> > CRDA handle the card-based restrictions, but ISTR you had reasons that
> > didn't work for everything.
> 
> What do you mean?

/me digs in the archives...

http://marc.info/?l=linux-wireless&m=125752855010045&w=2

I guess I "still" liked it back then :)

So with that setup people who want to fiddle with the card in 'expert'
mode could override the card's eeprom reg domain stuff by suitably
changing crda db instead of recompiling the kernel.

But if I read your follow-ups correctly, going that way wasn't actually
a big win.  I didn't then (much less now) have the time to explore it
in actual code.

That doesn't cover the person who wanted to use all_channels, but at
least that is exported by a modparam today.  There are probably other
things that an 'expert' would want to do beyond these two, though.

-- 
Bob Copeland %% www.bobcopeland.com

Re: Adding custom channels to ath5k for researching purposes

[Luis R. Rodriguez]

On Tue, May 8, 2012 at 10:55 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Tue, May 08, 2012 at 09:49:22AM -0700, Luis R. Rodriguez wrote:
>> > I still like the idea of exporting more stuff to userspace and letting
>> > CRDA handle the card-based restrictions, but ISTR you had reasons that
>> > didn't work for everything.
>>
>> What do you mean?
>
> /me digs in the archives...
>
> http://marc.info/?l=linux-wireless&m=125752855010045&w=2
>
> I guess I "still" liked it back then :)
>
> So with that setup people who want to fiddle with the card in 'expert'
> mode could override the card's eeprom reg domain stuff by suitably
> changing crda db instead of recompiling the kernel.
>
> But if I read your follow-ups correctly, going that way wasn't actually
> a big win.  I didn't then (much less now) have the time to explore it
> in actual code.
>
> That doesn't cover the person who wanted to use all_channels, but at
> least that is exported by a modparam today.  There are probably other
> things that an 'expert' would want to do beyond these two, though.

I don't think at that point the idea of CONFIG_EXPERT went through my
mind, I think its reasonable now to start considering this. For
example we could start off first with replacing that module parameter
under a CONFIG_WIRELESS_EXPERT. The goal of such flag is to not have
everyone enabling it and by everyone I mean every Linux distribution.
If we can work toward that I think this is a win given that there is
code we can add that otherwise is introduced by crap module parameters
or crap external patches.

  Luis