EINVAL when setting 802.11a channel in Ad-Hoc mode

EINVAL when setting 802.11a channel in Ad-Hoc mode

[Josh Triplett]

We're trying to run 802.11a in Ad-Hoc mode.  However, when we get to the
point of setting the channel, we almost always get EINVAL back from the
kernel.  We ran the following series of commands:

wlan=wlan3
iwconfig $wlan mode Ad-Hoc
ifconfig $wlan up
iwconfig $wlan essid PSAS-flight-computer
iwconfig $wlan channel 36

The channel command almost always got back an EINVAL.  This occurred on
three different wifi chipsets: a USB ar9170 (with either carl9170 or the
older ar9170usb driver), a USB rt2800usb, and iwlwifi with a Lenovo
X220.  In the former two cases, it occurs on both x86 (the
aforementioned X220) and powerpc (an MPC5200).

More strangely, the channel command would *sometimes* successfully set
the channel without error.

Have we done something wrong with the sequence of commands above?  Why
might we get EINVAL when setting a valid channel?  What next steps
should we take to debug this?

Currently about to compile in function_graph tracing and start walking
through the execution of SIOCSIWFREQ looking for what generates the
EINVAL.

- Josh Triplett

Re: EINVAL when setting 802.11a channel in Ad-Hoc mode

[Josh Triplett]

On Tue, Aug 16, 2011 at 07:51:42PM -0700, Josh Triplett wrote:
> We're trying to run 802.11a in Ad-Hoc mode.  However, when we get to the
> point of setting the channel, we almost always get EINVAL back from the
> kernel.  We ran the following series of commands:
> 
> wlan=wlan3
> iwconfig $wlan mode Ad-Hoc
> ifconfig $wlan up
> iwconfig $wlan essid PSAS-flight-computer
> iwconfig $wlan channel 36
> 
> The channel command almost always got back an EINVAL.  This occurred on
> three different wifi chipsets: a USB ar9170 (with either carl9170 or the
> older ar9170usb driver), a USB rt2800usb, and iwlwifi with a Lenovo
> X220.  In the former two cases, it occurs on both x86 (the
> aforementioned X220) and powerpc (an MPC5200).
> 
> More strangely, the channel command would *sometimes* successfully set
> the channel without error.
> 
> Have we done something wrong with the sequence of commands above?  Why
> might we get EINVAL when setting a valid channel?  What next steps
> should we take to debug this?
> 
> Currently about to compile in function_graph tracing and start walking
> through the execution of SIOCSIWFREQ looking for what generates the
> EINVAL.

Having done that, I managed to track down the source of the problem.
Note that in the script above, I used channel 36 as an example; however,
we tried a couple of other channels that should theoretically work in
the US, such as 136, but those apparently have additional requirements
to use, and it looks like Linux just gives a blanket "no".

As it turns out, we want to use channel 36 anyway, so it doesn't matter
that 136 doesn't work.

- Josh Triplett