On Mon, May 23, 2011 at 1:51 PM, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > On 05/23/2011 01:25 PM, Luis R. Rodriguez wrote: >> >> On Mon, May 23, 2011 at 1:09 PM, Ben Greear<greearb@xxxxxxxxxxxxxxx> >> Â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. >>> Guess it's time to go find a hack to over-ride eeprom >>> settings :( >> >> Good luck with support from anyone for any further questions ;) [1]. > > I can certainly disable the module parameter and have it bug for bug > compatible with upstream code. ÂI'm not going to > write to the eeprom or anything funny like that. I'm just letting you know, I nor a lot of developers approve of promoting code which goes out of regulatory compliance [1] [1] http://wireless.kernel.org/en/developers/Regulatory/statement Understanding the regulatory considerations and actually trying to find decent solutions is the hard part, but I do believe solutions are possible, they just take time. The dynamic regulatory selection thing I think will be the future we need a tight solution covering all grounds of the calibration and CTL process at least for Atheros cards. >> 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. Luis -- 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
