iwlagn + Ad-Hoc + 5Ghz

iwlagn + Ad-Hoc + 5Ghz

[Jeremy Moles]

Hello all! I have a group of machine here with an app that needs to set
up an ad-hoc network in 5Ghz+ range. The machines themselves are all
different (a Panasonic, a Dell, and a Lenovo) but they are all using
5100 cards, a 2.6.31 kernel, and the 2.6.31-rc7 driver from the website.

Using the command "iw list" I can get a lot of helpful info, but I see
"no IBSS" on any channel over 11, and I'm beginning to think that this
just isn't supported on these cards yet. Am I right here, or is it in
fact supported and I am just missing something? Could the hardware,
perhaps, be configured on a very low level to not allow something like
this?

Thanks in advance. :)

Re: iwlagn + Ad-Hoc + 5Ghz

[Luis R. Rodriguez]

On Fri, Nov 20, 2009 at 2:37 PM, Jeremy Moles <jeremy@emperorlinux.com> wrote:
>
> Hello all! I have a group of machine here with an app that needs to set
> up an ad-hoc network in 5Ghz+ range. The machines themselves are all
> different (a Panasonic, a Dell, and a Lenovo) but they are all using
> 5100 cards, a 2.6.31 kernel, and the 2.6.31-rc7 driver from the website.
>
> Using the command "iw list" I can get a lot of helpful info, but I see
> "no IBSS" on any channel over 11, and I'm beginning to think that this
> just isn't supported on these cards yet.

No, this has nothing to do not supporting IBSS but instead you should
read "no IBSS" more as a regulatory rule that implies you cannot use a
mode of operation that can beacon. We should at least rename this on
iw for now to make thins clearer.

What you see should be part of the default rules embedded on the
device's EEPROM. Beaconing is allowed on channel 11 even on the most
restrictive regulatory domain and this is why the world regulatory
domain allows 1-11 to beacon too.

You should enable debugging on the driver upon load to confirm whether
this rule is coming from the EEPROM. Do you have
CONFIG_WIRELESS_OLD_REGULATORY? I think even that (by default it used
the US) enabled beaconing. Drivers can overrule things though if their
EEPROM mandates this.

  Luis

Re: iwlagn + Ad-Hoc + 5Ghz

[Benoit PAPILLAULT]

Luis R. Rodriguez a écrit :
> On Fri, Nov 20, 2009 at 2:37 PM, Jeremy Moles <jeremy@emperorlinux.com> wrote:
>> Hello all! I have a group of machine here with an app that needs to set
>> up an ad-hoc network in 5Ghz+ range. The machines themselves are all
>> different (a Panasonic, a Dell, and a Lenovo) but they are all using
>> 5100 cards, a 2.6.31 kernel, and the 2.6.31-rc7 driver from the website.
>>
>> Using the command "iw list" I can get a lot of helpful info, but I see
>> "no IBSS" on any channel over 11, and I'm beginning to think that this
>> just isn't supported on these cards yet.
> 
> No, this has nothing to do not supporting IBSS but instead you should
> read "no IBSS" more as a regulatory rule that implies you cannot use a
> mode of operation that can beacon. We should at least rename this on
> iw for now to make thins clearer.
> 
> What you see should be part of the default rules embedded on the
> device's EEPROM. Beaconing is allowed on channel 11 even on the most
> restrictive regulatory domain and this is why the world regulatory
> domain allows 1-11 to beacon too.
> 
> You should enable debugging on the driver upon load to confirm whether
> this rule is coming from the EEPROM. Do you have
> CONFIG_WIRELESS_OLD_REGULATORY? I think even that (by default it used
> the US) enabled beaconing. Drivers can overrule things though if their
> EEPROM mandates this.
> 
>   Luis

Hello,

I got the same problem with Intel 4965 and Intel 5350 since those cards
are using the same drivers. Like Luis mentionned, "no IBSS" should be
read as "no beaconing authorized by local regulation". However, I think
the iwlagn interpretation is a bit broad and such restrictions should be
done by the CRDA framework instead of the driver itself.

Here in France, IBSS is authorized on all channels. So I made a small
patch to enable the EEPROM_CHANNEL_IBSS flag everywhere (in iwl-core.c
and iwl-dev.h) and it just works.

Will try to post the patch on Monday.

Regards,
Benoit

Re: iwlagn + Ad-Hoc + 5Ghz

[Patrick Grimm]

Am Samstag, 21. November 2009 09:51:04 schrieb Benoit PAPILLAULT:
> Hello,
> 
> I got the same problem with Intel 4965 and Intel 5350 since those cards
> are using the same drivers. Like Luis mentionned, "no IBSS" should be
> read as "no beaconing authorized by local regulation". However, I think
> the iwlagn interpretation is a bit broad and such restrictions should be
> done by the CRDA framework instead of the driver itself.
> 
> Here in France, IBSS is authorized on all channels. So I made a small
> patch to enable the EEPROM_CHANNEL_IBSS flag everywhere (in iwl-core.c
> and iwl-dev.h) and it just works.
> 
> Will try to post the patch on Monday.
Hi

I have set iw reg DE and the channel 12 and 13 have also the "no IBSS" Flag.
Fix your Patch this too?

Greetings
                       Patrick

Re: iwlagn + Ad-Hoc + 5Ghz

[Luis R. Rodriguez]

On Sat, Nov 21, 2009 at 12:51 AM, Benoit PAPILLAULT
<benoit.papillault@free.fr> wrote:
> Luis R. Rodriguez a écrit :
>> On Fri, Nov 20, 2009 at 2:37 PM, Jeremy Moles <jeremy@emperorlinux.com> wrote:
>>> Hello all! I have a group of machine here with an app that needs to set
>>> up an ad-hoc network in 5Ghz+ range. The machines themselves are all
>>> different (a Panasonic, a Dell, and a Lenovo) but they are all using
>>> 5100 cards, a 2.6.31 kernel, and the 2.6.31-rc7 driver from the website.
>>>
>>> Using the command "iw list" I can get a lot of helpful info, but I see
>>> "no IBSS" on any channel over 11, and I'm beginning to think that this
>>> just isn't supported on these cards yet.
>>
>> No, this has nothing to do not supporting IBSS but instead you should
>> read "no IBSS" more as a regulatory rule that implies you cannot use a
>> mode of operation that can beacon. We should at least rename this on
>> iw for now to make thins clearer.
>>
>> What you see should be part of the default rules embedded on the
>> device's EEPROM. Beaconing is allowed on channel 11 even on the most
>> restrictive regulatory domain and this is why the world regulatory
>> domain allows 1-11 to beacon too.
>>
>> You should enable debugging on the driver upon load to confirm whether
>> this rule is coming from the EEPROM. Do you have
>> CONFIG_WIRELESS_OLD_REGULATORY? I think even that (by default it used
>> the US) enabled beaconing. Drivers can overrule things though if their
>> EEPROM mandates this.
>>
>>   Luis
>
> Hello,
>
> I got the same problem with Intel 4965 and Intel 5350 since those cards
> are using the same drivers. Like Luis mentionned, "no IBSS" should be
> read as "no beaconing authorized by local regulation".

That's the case for the cfg80211 / CRDA db regulatory no-ibss flag.

> However, I think
> the iwlagn interpretation is a bit broad and such restrictions should be
> done by the CRDA framework instead of the driver itself.

Its my understanding such a change would require a firmware change,
its not so simple for iwl.

> Here in France, IBSS is authorized on all channels. So I made a small
> patch to enable the EEPROM_CHANNEL_IBSS flag

This may or may not mean no-beaconing, you'd need documentation or
confirmation from someone. Or manual testing against AP / Mesh modes
too.

> everywhere (in iwl-core.c and iwl-dev.h) and it just works.

I'm surprised it works without issues, it is likely you will run into
an issue. I could be wrong though. You may want to test against older
supported firmware as well.

The driver is always giving the last say with regards to regulatory.
Although a savvy technical user may indeed know better current
legislation does not allow for blindly trusting the user and in fact
can potentially penalize for it. As an example you can read the recent
clarification by the FCC regarding selecting your regulatory domain
[1].

So although your change may work your are not considering the fact
that iwl card world roam into different regions and as such they
cannot choose a country or extract it from the card and therefore
cannot just allow everything and let the user select a regulatory
domain. If regulatory agencies start shifting responsibility of
regulatory compliance down to the user then things would be easier,
but we're simply not there yet.

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

  Luis