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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
