On Mon, Aug 17, 2009 at 1:27 PM, Simon Farnsworth<simon@xxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I'm facing problems using two ath5k miniPCI cards in a single box as a > dual-band access point. I'm using wireless-testing as of commit > d5a88a192e556a7c30f9d425bb6673b5bff5e3f3. This is a bit old now, please update. The updates won't help you regulatory wise, but for purposes of testing new patches it would be easier. > As I'm trying to use the cards for AP mode, I cannot rely on beacons with > regulatory data being present; Regulatory questions are often and I try really hard to answer them first through documentation so it seems we need to improve documentation further. To be thorough though I'd first like to ask if you have read all this: Linux regulatory docs: http://wireless.kernel.org/en/developers/Regulatory Atheros shared module documentation (ath.ko): http://wireless.kernel.org/en/users/Drivers/ath The above has specifics about how the Atheros EEPROM is designed in consideration for regulatory purposes, and what we do in Linux with regards to the new Linux regulatory infrastructure. Perhaps one aspect regarding regulatory that may need some updating is how we deal with world roaming. Let me clarify a little on that and please let me know if the documentation hasn't been crystal clear so we can improve on it. World roaming is a practice vendors use to allow customers (OEMs, etc) sell wireless devices in different regions. Typically you would expect one device sold for one particular region and building and programming the device, EEPROM or firmware for that region. Over time this has proven economically cost prohibitive but also impractical due to the dynamic nature of regulatory rules world wide so vendors tend to allow for more control for regulatory purposes to be more dynamic, one way or another. This shift is done purely for the sake of reducing cost, while also simplifying hardware and increasing the range in which customers can sell their products. What increases in complexity is software which needs to deal with this. Technically you can come up with a world wide regulatory domain which allows operation of an 802.11 device world wide. But obviously this itself can change as well, and so remains dynamic. The complexity of the considerations increases when you start to consider the different modes of operation which you can use on an 802.11 device. Addressing station mode support is the easiest as you *do* not necessarily have to initiate transmit in order to find your Access Point. If you try to address regulatory rules in consideration for dealing with initial TX your rules become more complex. Sometimes you don't have to be so restrictive on some bands (2.4 GHz or 5 GHz) for some customers shipping to only a few countries, so a world regulatory domain is pretty restrictive. When only a few countries are being used to ship products some customers may request a different regulatory domain to be created to work as the intersection between those countries and not *every* country. Sometimes some companies like to only customize a few "world regulatory domains" and only sell to customers on one of those few choices. This varies, vendor by vendor. Your most basic regulatory setting would consist of a 1-1 mapping where the device *knows* for sure it was packaged and sold and tested for only one country. For that case the rules are very clear and we can simply read the rules only for that country on some sort of database. This is however a very rare case though, at least for Atheros cards. Most Atheros cards use world regulatory domains. From a design perspective what regulatory domain an 802.11 device falls under is up to the customer, where the customer typically means an OEM, or card manufacturer. Today the end user has no say in what regulatory domain your card is designed and tested for except for the general assumption that if you purchase a laptop or wireless device in a country an assumption is made based on the targeted audience for that product. A laptop from a manufacturer who typically sells a lot to companies world wide may prefer to use a world regulatory domain to accommodate a set of countries they will market their product for, we refer to these as SKUs. At times maybe a manufacturer will see a product is not selling well in certain countries and may change their strategy and sell to some other countries. A prepared manufacturer may have foreseen this and because of it chose a world regulatory domain SKU which would fit its current target countries and also a few potential ones. What mode of operation you use is important too, but for example today laptops are *typically* not sold with the intention to support AP mode, for example, even though your hardware is completely capable of it, and we may see this change in the future. When you world roam you are typically now allowed to initiate TX on some channels, the exception today is channels 1-11 on the 2.4 GHz band as every country allows for operation on these channels. On 5 GHz though this means regulatory wise we enforce passive scanning on many world regulatory domains. This is the case of all Atheros world regulatory domains, and the Linux world regulatory domain. There are certain heuristics you can use, however, to help with this though if you do want to support AP mode on 5 GHz on some of these cards though. An example here is if you detect a beacon from an AP on a 5 GHz channel you could then assume you can also initiate TX. This assumption works well right on 5 GHz except for channels which require DFS. We take advantage of this assumption in Linux and enable initiating TX (beaconing) when we see an AP around us on non-DFS channels. Typical practice in the industry is user input is not used for regulatory compliance. Truth is user input could in fact be very valuable and we do take advantage of it on Linux to *help* regulatory compliance. An example here is a user purchases a device from Japan and moves to the US and wants to disable usage of channels 13 and 14 which are not allowed in the US. If a user informs the kernel the user is in the US we can disable scanning on channels 13 and 14 and therefore improve scan time and roaming time. Now, although some optimizations may be welcomed like world roaming enhancements, and user input could in fact be valuable information to help regulatory compliance, one thing still remains true: devices sold today are not designed with user input in mind for regulatory compliance. The extent to which we make use of certain optimizations in Linux are purely practical in nature, but care must be taken to note that laws must still be respected. Because regulatory laws vary but do not make it clear explicit user input is welcomed manufacturers still do need to be careful to not over step the boundaries of what is allowed and what may make perfect sense to some developers and users may not be necessarily agreeable currently to current regulatory agencies. I do believe this shall change though, it is inevitable, but we're not there yet. Until then please do understand that current regulatory framework exist to aid vendors primarily with regulatory compliance and user input is used only as optimizations. As such also take into consideration that although the "US" regulatory domain can be well defined, not all vendors use it even if they do sell devices in the US. Vendors may also have custom world regulatory domains if they choose to not want to just use the intersection between all countries, the default. Now with all that said and with you having read the documentation, lets move on :) > instead, I have modprobe configured to run > "iw reg set GB" after cfg80211 is loaded, How do you have modprove configured to do that? Are you using ieee80211_regdom module parameter? If so please consider just using 'iw' or hostapd configured as you have below. > and hostapd.conf files containing > the line "country_code=GB". You only need one of those. For Atheros devices this is an example of a user helping compliance. > My cards both have a regdomain in the EEPROM of 0x0, This is something that the manufacturer would have decided on. > which my vendor assures > me is the correct regdomain for cards which don't claim any particular > regulatory compliance, Who exactly did you speak to? Atheros uses 0x0 for a default mapping to the US. > and which rely on the host OS getting regulatory > compliance right. The driver does indeed map 0x0 to "US". > I am seeing two problems; firstly, the regulatory > infrastructure insists that I'm in the United States, Bingo, its not the Linux regulatory infrastructure doing this, it is the ath.ko shared module which is used as a helper to share code between ath5k, ath9k, ar9170 and soon ar9271. Atheros' EEPROM was designed with specific regulatory considerations, its engineered so that the device's EEPROM indicates what regulatory domain should be used. As I explained above, what regulatory domain your card is programmed with is not up to you, it is up to the manufacturer. While I agree this may be silly, its for a reason and until regulatory rules change this will be the case. > thus preventing legal > use of the WiFi bands, but allowing me illegal use. This is no different than considering the case of when you ship an access point from JP to the US and you start beaconing on channel 13. You are violating local US regulatory laws if your configuration was to beacon on channel 13. If you take a US AP to the JP you then are prevented from usage of the allowed channel 13. I realize it may seem silly, and in fact I agree, but that is the law. If you were to bring an AP from JP to the US *with* a regulatory domain which matches the JP SKUs and therefore are allowed to beacon on channel 13 we give you the flexibility in Linux to enhance compliance and indicate you are on in the US and disable channel 13. Now, as much as I would love for it to be the case that the other way around should be enabled it is not, and although technically it is feasible, it is just not something agreeable to current regulatory agencies. Maybe one day it will be for 802.11, who knows. Anyway in your case since the device sends a regulatory hint for "US" first, and then you say "GB" the card will *always* respect first "US", and "GB" is just used to further help compliance. > Secondly, I'm seeing different regulatory settings on each card. "iw list" > shows me that in the 2GHz band, phy1 is being allowed to use 27.0 dBm on > channels 1-11, whereas I'm only allowed to use 20.0 dBm, but I'm allowed > channels 1-13. I did not understand the last part, can you rephrase this again? > In the 5GHz band, phy1 is allowed 17.0 dBm on channels 36-48, > to my local regulation's 20.0 dBm, reduced power in the (unusable as yet due > to driver limitations) DFS-only channels between 5.490 GHz and 5.710 GHz, > and 30 dBm in the illegal channels for my region of 149 to 165. OK, first lets review US and GB regulatory domain: country GB: (2402 - 2482 @ 40), (N/A, 20) (5170 - 5250 @ 40), (N/A, 20) (5250 - 5330 @ 40), (N/A, 20), DFS (5490 - 5710 @ 40), (N/A, 27), DFS country US: (2402 - 2472 @ 40), (3, 27) (5170 - 5250 @ 40), (3, 17) (5250 - 5330 @ 40), (3, 20), DFS (5490 - 5710 @ 40), (3, 20), DFS (5735 - 5835 @ 40), (3, 30) Now here is what an intersection yields for me between US and GB: mcgrof@tux ~/devel/crda (git::master)$ sudo ./intersect ../wireless-regdb/regulatory.bin GB (4) intersect US (5) ==> 4 rules Only one intersection completed == World regulatory domain: == country 99: (2402.000 - 2472.000 @ 40.000), (N/A, 20.00) (5170.000 - 5250.000 @ 40.000), (N/A, 17.00) (5250.000 - 5330.000 @ 40.000), (N/A, 20.00), DFS (5490.000 - 5710.000 @ 40.000), (N/A, 20.00), DFS So since your card is programmed for the "US" that information is *always* respected. GB info is only used to further help compliance. This means whatever channels are not allowed by the "US" regulatory domain will never be allowed on your card even if you say you are in "GB". > On phy0, I see that I'm being permitted 20.0 dBm in the 2GHz band (but still > only channels 1-11, and no beaconing permitted in the 5GHz band. Interesting, consider that phy0 is the first device detected, its regulatory hint would have first listened to, since both devices have the same regulatory domain according to what you are indicating they would agree. And instead of reading your interpretation of what is allowed or not can you please instead provide the 'iw list' output? > How do I persuade the Atheros drivers that, since I'm using AP mode, the > user-set regulatory domain is correct, You cannot. But information from the user to help compliance is certainly welcomed. > and that the domain it selects for > EEPROM regdomain 0x0 is wrong? Its not wrong per se, it was designed that way and you do disagree with it. There is also a lot of historical and legal history behind how you ended up with a "US" card in "GB". I hope to have clarified that. > Ideally, I would expect both cards to have the same regulatory rules > applied; Indeed, this does seems like a bug. > I would further expect to be able to select a different country's > regulations to the ones selected by default, Yeah typically that's what users expect but that's not the case. Granted there are devices in Linux for which the device has no regulatory information at all. In those cases the user does have final say on the device. If the vendor does know better though that information is respected. > without losing the card's > calibration settings (which I believe are stored in a way that depends on > the EEPROM regdomain setting). Spot on -- calibration is actually very important for device functionality, it is actually also used for regulatory conformance on what we call 'Conformance Test Limits'. Now this is very Atheros specific but the idea is the same between vendors, to respect max EIRP on band edges very carefully. The CTL info *also* does provide regulatory limits for max EIPR in-band, and not just band edges. This information is used to conform to the device's calibrated regulatory domain. > I should note that I'm happy to run a > privately patched kernel, if that's the only way to do what I want, but I'm > still concerned about the differing regulatory rules between the two cards. I recommend to help resolve your issues by reporting the issues as you have but with detailed logs. Sure you can hack up ath5k and ath9k to do weird things, maybe even sing, but I advise against it unless you know what you are doing. We do have good support upstream for ath9k and ath5k for regulatory and calibration purposes. The point is to help you use your device as was intended, we can't help you if you take your device out of intended regulatory domain due to the differences in calibration settings and because it may make the device use settings which could potentially damage it. Things are they way they are for a reason, except if there is a bug and I do think you have found one. > The relevant chunk of dmesg follows, and I can provide any other needed > information upon request: > > [ 1.857433] cfg80211: Calling CRDA to update world regulatory domain > [ 1.891579] cfg80211: Calling CRDA for country: GB This probably came from the modprobe thing you have, whatever that was. This indicates userspace is being kicked to call /sbin/crda so that crda sends the GB regulatory domain to cfg80211. Notice how cfg80211 hasn't yet replied though, or maybe it has but cfg80211 hasn't yet processed anything until later after the other regulatory_hint()s. > [ 2.015975] ath5k 0000:02:04.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > [ 2.016204] ath5k 0000:02:04.0: registered as 'phy0' > [ 2.152564] ath: EEPROM regdomain: 0x0 OK first device has 0x0. > [ 2.152574] ath: EEPROM indicates default country code should be used > [ 2.152580] ath: doing EEPROM country->regdmn map search > [ 2.152589] ath: country maps to regdmn code: 0x3a > [ 2.152595] ath: Country alpha2 being used: US and it maps the US. > [ 2.152601] ath: Regpair used: 0x3a > [ 2.264328] phy0: Selected rate control algorithm 'minstrel' > [ 2.264822] ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61) > [ 2.265041] alloc irq_desc for 17 on node -1 > [ 2.265048] alloc kstat_irqs on node -1 > [ 2.265066] ath5k 0000:02:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > [ 2.265276] ath5k 0000:02:08.0: registered as 'phy1' > [ 2.400795] ath: EEPROM regdomain: 0x0 Here is the second device and it also has 0x0, ok good. > [ 2.400805] ath: EEPROM indicates default country code should be used > [ 2.400812] ath: doing EEPROM country->regdmn map search > [ 2.400821] ath: country maps to regdmn code: 0x3a > [ 2.400827] ath: Country alpha2 being used: US And again "US" is picked up. > [ 2.400832] ath: Regpair used: 0x3a > [ 2.400924] cfg80211: Calling CRDA for country: US This is the first regulatory_hint() being processed by cfg80211 module. Eventually userspace udev will kick /sbin/crda and crda will send the "US" regulatory domain to cfg80211. > [ 2.403133] phy1: Selected rate control algorithm 'minstrel' > [ 2.403636] ath5k phy1: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61) > [ 2.403867] cfg80211: Calling CRDA for country: US Here is the second regulatory_hint() being processed. At this point userspace is expected to have run twice and the kernel should have received the "US" regulatory domain twice. Now notice the timestamps below in comparison to the one above: > [ 3.076972] cfg80211: Current regulatory domain intersected: > [ 3.077089] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) > [ 3.077277] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > [ 3.077386] (2457000 KHz - 2472000 KHz @ 15000 KHz), (300 mBi, 2000 mBm) > [ 3.077494] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) > [ 3.077602] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Lets compare this against the intersection I ran in userspace: (2402.000 - 2472.000 @ 40.000), (N/A, 20.00) (5170.000 - 5250.000 @ 40.000), (N/A, 17.00) (5250.000 - 5330.000 @ 40.000), (N/A, 20.00), DFS (5490.000 - 5710.000 @ 40.000), (N/A, 20.00), DFS A few observations: * Notice how the 2457000 KHz - 2472000 KHz is present on your ouput but not on mine. * Notice how you have 15000 KHz bandwidth allowed for your 2457000 KHz - 2472000 KHz frequency range. That bandwidth is there because 2472000 minus 2457000 yields 15000, but why the rule is there is not clear to me as I am not sure what regulatory domains are being intersected here. * The 2472000 - 2457000 frequency rule is good example of overlapping rules which could probably be avoided if we formalize regulatory definitions more as Johannes had proved a while ago. * My intersection yielded 5250.000 - 5330.000 but you do not have this at all * You have 5735000 KHz - 5835000 KHz but should not. We can debug all this further but first I'd like to see your full log. To be clearer I'll also recommend for now for you to not have something to trigger a regulatory hint from userspace early, either through the ieee80211_regdom module parameter, which you have not indicated you have used but I do suspect you did use, or through some script upon cfg80211 loading. I don't expect a script to have triggered a regulatory hint prior to ath5k loading so I am curious how you accomplished this. What is very curious here is cfg80211 indicates it is already intersecting. This to me indicates you have either forgotten to add more dmesg info from the initial regulatory domain setting *or* there is a bug here between cfg80211 believing it already has processed GB. Either way you are certainly right that something is fishy here. Can you just post your full dmesg log? > [ 3.082954] cfg80211: Current regulatory domain intersected: > [ 3.083078] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) > [ 3.083278] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > [ 3.083392] (2457000 KHz - 2472000 KHz @ 15000 KHz), (300 mBi, 2000 mBm) > [ 3.083504] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) > [ 3.083616] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) This listing is identical as the one above. What is even fishier is once you have an intersected regulatory domain IIRC we don't let much through anymore. Please enable in your kernel CONFIG_CFG80211_REG_DEBUG=y Also please ensure to disable CONFIG_WIRELESS_OLD_REGULATORY and please tell me if you had this set or not. Thank you for taking the time to report this. 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
