On Wed, Feb 23, 2011 at 06:20:27AM -0800, crocket wrote: > ath9k supports AP mode for all chipsets, but according to people > evidences, AP mode support for AR5xxx chipsets ceases to work several > minutes after the chipsets are turned into AP mode. > Below is the amazon review of AR9280.( > http://www.amazon.com/PCI-Express-Mini-Card-802-11n-Atheros-AR9280/dp/B00383YKQ6/ref=cm_cr_pr_product_top > ) > > This review is from: WLAN PCI-Express Mini-Card 802.11n/a/b/g 300 Mbps > / Atheros AR9280 / 2Tx2R MIMO > > "I purchased this adapter for a custom built router/AP. The Linux > drivers would not allow the use of the 5ghz bands limiting the speed > to 130mbit. > > The reason for this is the regulatory domain stored on the card does > not contain valid settings for any region. The Linux drivers respond > by disabling this functionality.
This is false, the *truth* that some cards are programmed by the OEM / ODM with a world regulatory domain [1] in the EEPROM. By design these are for world roaming, so the only thing you can do on 5 GHz is to do passive scan upon intialization. This means you won't be able to beacon because we do not know where we are. However, cfg80211 has this thing called beacon hints [2] which we use to lift passive scan and no-ibss (no beaconing) flags from a device which is world roaming on some channels (non-DFS 5 GHz channels). This information however will be cleared upon disassociation given that when you disassociate you may be in another country. ath9k supports a notion called virtual wiphy [3] but new patches removed this from our current development tree given the complexity required to support it. Our goal is to eventually address something similar but for all drivers through cfg80211 / mac80211. I believe 2.6.38 will be the last kernel with the specific ath9k virtual wiphy stuff so you can likely use that to propagate learned beacon hints from one STA wiphy to another AP wiphy. cfg80211's beacon hint learning is propagated to *all* devices, even other drivers present. Unfortunately due to regulatory considerations which have also come under recent stress [4] we cannot feature-wise let users overwrite their own EEPROM, even if they know better. This is simply the state of affairs today, but hopefully would change. The way I see it, we should be dynamicaly figuring out our location using GPS / other trusted feeds and propagate this to 802.11 devices but current regulatory rules prohibit this. Given that ath9k virtual wiphy is gone, you can use either 2.6.38 as I noted or verify the EEPROM contents of a card you purchase to ensure it fits your own country. [1] http://wireless.kernel.org/en/users/Drivers/ath#EEPROM_world_regulatory_domain [2] http://wireless.kernel.org/en/developers/Regulatory/processing_rules#Beacon_hints [3] http://wireless.kernel.org/en/users/Drivers/ath9k/debug#wiphy [4] http://wireless.kernel.org/en/developers/Regulatory/CRDA#Helping_compliance_by_allowing_to_change_regulatory_domains Luis _______________________________________________ ath9k-devel mailing list [email protected] https://lists.ath9k.org/mailman/listinfo/ath9k-devel
