* [ath9k-devel] AR9380 + hostapd + HT over 802.11a @ 2011-05-31 17:36 Mihai Moldovan 2011-05-31 17:56 ` Peter Stuge 2011-05-31 18:06 ` Ben Greear 0 siblings, 2 replies; 16+ messages in thread From: Mihai Moldovan @ 2011-05-31 17:36 UTC (permalink / raw) To: ath9k-devel Hey all, I'm having a "problem" again. ;) Today I got my AR9380 card and wanted to set it up on 802.11a (5GHz) with HT40 (802.11n). Although enabling 802.11d and setting the regulatory domain to "DE" (Germany), I wasn't able to bring up the card on any 5GHz channel in AP mode. Finding some "patch" for ath9k which disabled NO_IBSS, RADAR_SCANNING and PASSIVE_SCAN, I was able to bring the card up on 5GHz with HT (and finally get 300MBit max rate.) I feel that's the wrong approach and would like to ask how to really do this kind of stuff. Also: as the card is currently running on 5GHz, I'd like to put another card up running on 2.4GHz for legacy hardware not capable of 802.11a (for instance my Android phone.) Is there anything I should pay attention to? For instance using another ESSID and (naturally) using some 2.4GHz channel. In my experience, running two cards on the same ESSID on different channels doesn't work well and confuses STAs, leading to connection drops and unrecoverable states. Any help is highly appreciated. Best regards, Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110531/0b618272/attachment.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 17:36 [ath9k-devel] AR9380 + hostapd + HT over 802.11a Mihai Moldovan @ 2011-05-31 17:56 ` Peter Stuge 2011-05-31 18:17 ` Mihai Moldovan 2011-05-31 18:06 ` Ben Greear 1 sibling, 1 reply; 16+ messages in thread From: Peter Stuge @ 2011-05-31 17:56 UTC (permalink / raw) To: ath9k-devel Mihai Moldovan wrote: > Although enabling 802.11d and setting the regulatory domain to "DE" > (Germany), I wasn't able to bring up the card on any 5GHz channel in AP > mode. If the card has a regdomain which requires passive scanning set in it's EEPROM then setting regdomain in userspace will not change that. Setting regdomain in userspace will only ever limit capabilites further, never increase capabilities. > Finding some "patch" for ath9k which disabled NO_IBSS, RADAR_SCANNING and > PASSIVE_SCAN, I was able to bring the card up on 5GHz with HT (and finally > get 300MBit max rate.) > > I feel that's the wrong approach and would like to ask how to really do > this kind of stuff. If you ask Atheros they (have to) say you should buy a card with the appropriate regdomain in EEPROM. In practise that's of course not possible so the only realistic choice left is to change the regdomain in the EEPROM. You can reverse engineer ath9k to find out how. If you do, please publish the tool. :) > I'd like to put another card up running on 2.4GHz for legacy > hardware not capable of 802.11a (for instance my Android phone.) > > Is there anything I should pay attention to? For instance using > another ESSID This one is not so easy. Everyone should use 5GHz, but as you have noticed most if not all STAs have utterly useless algorithms for selecting the access point if several are in range on different channels. In theory the correct thing is IMO to use the same ESSID for 5GHz and 2.4GHz since it is in fact exactly the same network. There is plenty of information for hardware and driver stacks to make semi-intelligent decisions about what to tune to. Unfortunately this is not noticeable in reality with many devices. So by having different ESSID you allow the user to take control, she can select in her machine that only the 5GHz network should ever be used. It has significantly worse usability, because the user is now forced to do a menial task which the machine already has ample information to carry out, so it is absurdly degrading to push the task onto the user. Alas it may still be neccessary. (Just remember that it is in fact a workaround for shitty STAs.) //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110531/2afe6a5e/attachment-0001.pgp ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 17:56 ` Peter Stuge @ 2011-05-31 18:17 ` Mihai Moldovan 0 siblings, 0 replies; 16+ messages in thread From: Mihai Moldovan @ 2011-05-31 18:17 UTC (permalink / raw) To: ath9k-devel * On 31.05.2011 07:56 PM, Peter Stuge wrote: > If the card has a regdomain which requires passive scanning set in > it's EEPROM then setting regdomain in userspace will not change that. True... the regdomain seems to be set to "0x30" and the alpha2 country to "00" according to the Kernel messages: [ 4924.583159] ath: EEPROM regdomain: 0x6a [ 4924.583160] ath: EEPROM indicates we should expect a direct regpair map [ 4924.583162] ath: Country alpha2 being used: 00 [ 4924.583163] ath: Regpair used: 0x6a 0x6A is some custom Atheros World Regulatory Domain, too restrictive I guess. But I can neither blame the card manufacturer nor the guy who imported it. > Setting regdomain in userspace will only ever limit capabilites > further, never increase capabilities. Yep, read that while installing CRDA. ;) > This one is not so easy. Everyone should use 5GHz, but as you have > noticed most if not all STAs have utterly useless algorithms for > selecting the access point if several are in range on different > channels. Signed. It's even worse on the same channel. ;) So, to keep my Laptop from jumping from one channel to another and possibly also confuse itself to death, I'll go for that ESSID++ solution, although... > In theory the correct thing is IMO to use the same ESSID for 5GHz and > 2.4GHz since it is in fact exactly the same network. ... logically, one should be using the same ESSID. Legacy devices not capable of 5GHz won't care, but any newer card/STA will handle this badly (as I found out some years ago whilst playing with this sort of stuff.) Thanks you! Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110531/b72a165f/attachment.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 17:36 [ath9k-devel] AR9380 + hostapd + HT over 802.11a Mihai Moldovan 2011-05-31 17:56 ` Peter Stuge @ 2011-05-31 18:06 ` Ben Greear 2011-05-31 18:29 ` Mihai Moldovan 1 sibling, 1 reply; 16+ messages in thread From: Ben Greear @ 2011-05-31 18:06 UTC (permalink / raw) To: ath9k-devel On 05/31/2011 10:36 AM, Mihai Moldovan wrote: > Hey all, > > I'm having a "problem" again. ;) > > Today I got my AR9380 card and wanted to set it up on 802.11a (5GHz) > with HT40 (802.11n). > > Although enabling 802.11d and setting the regulatory domain to "DE" > (Germany), I wasn't able to bring up the card on any 5GHz channel in AP > mode. > > Finding some "patch" for ath9k which disabled NO_IBSS, RADAR_SCANNING > and PASSIVE_SCAN, I was able to bring the card up on 5GHz with HT (and > finally get 300MBit max rate.) > > I feel that's the wrong approach and would like to ask how to really do > this kind of stuff. > > Also: as the card is currently running on 5GHz, I'd like to put another > card up running on 2.4GHz for legacy hardware not capable of 802.11a > (for instance my Android phone.) > > Is there anything I should pay attention to? For instance using another > ESSID and (naturally) using some 2.4GHz channel. In my experience, > running two cards on the same ESSID on different channels doesn't work > well and confuses STAs, leading to connection drops and unrecoverable > states. > > Any help is highly appreciated. Probably your NIC is in regdomain 0x6a or similar. If you see something like this in your logs that is the problem: ath: EEPROM regdomain: 0x6a ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x6a cfg80211: Calling CRDA for country: US cfg80211: Regulatory domain changed to country: US cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) You can over-ride this with a patch similar to this one: http://patches.aircrack-ng.org/ath9k_regdomain_override.patch (That patch may not apply to your kernel, but it's not too hard to make it work.) Find your domain for DE and just use that. I used 0x0, which evidently is basically US (here in the USA) to get some of the 5Ghz channels working in AP mode). Note that you may lose 'official' support by doing this, but as far as I can tell, as long as you use the correct domain with 'iw reg set' you will still be in regulatory compliance as it chooses the minimal set of features supported by the NIC and whatever 'iw reg set' does. If you use 0x0 and 'iw set US' then you are likely out of compliance in Germany, for instance. Thanks, Ben > > Best regards, > > > Mihai > > > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 18:06 ` Ben Greear @ 2011-05-31 18:29 ` Mihai Moldovan 2011-05-31 18:33 ` Ben Greear 0 siblings, 1 reply; 16+ messages in thread From: Mihai Moldovan @ 2011-05-31 18:29 UTC (permalink / raw) To: ath9k-devel * On 31.05.2011 08:06 PM, Ben Greear wrote: > Probably your NIC is in regdomain 0x6a or similar. Exactly, see the last message. > If you see something like this in your logs that is the problem: > > > ath: EEPROM regdomain: 0x6a > ath: EEPROM indicates we should expect a direct regpair map > ath: Country alpha2 being used: 00 > ath: Regpair used: 0x6a > > cfg80211: Calling CRDA for country: US > cfg80211: Regulatory domain changed to country: US > cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) > cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) > cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) > cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Interestingly, I'm not seeing those messages, even when changing the domain via iw set reg DE or sorta. The only message I get is following: [ 16.719918] cfg80211: Calling CRDA to update world regulatory domain I installed crda just recently without rebooting, maybe that's the cause. udev was restarted manually after installing crda, but who knows what else magic is required. I'll power cycle the machine to see whether I can get more information. Oh, and enabling CONFIG_CFG80211_REG_DEBUG may not be the worst idea either. %) > You can over-ride this with a patch similar to this one: > http://patches.aircrack-ng.org/ath9k_regdomain_override.patch Thanks, I'll rather try this than blindly enabling all channels in ath's regd.c > Note that you may lose 'official' support by doing this, but as far > as I can tell, as long as you use the correct domain with 'iw reg set' > you will still be in regulatory compliance as it chooses the minimal > set of features supported by the NIC and whatever 'iw reg set' does. Chances are AP mode on 5Ghz haven't been tested with this card and the channels are thus disabled, but I'll have a look nonetheless. Thanks again. :) Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110531/c2fb1240/attachment-0001.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 18:29 ` Mihai Moldovan @ 2011-05-31 18:33 ` Ben Greear 2011-05-31 18:38 ` Mihai Moldovan 0 siblings, 1 reply; 16+ messages in thread From: Ben Greear @ 2011-05-31 18:33 UTC (permalink / raw) To: ath9k-devel On 05/31/2011 11:29 AM, Mihai Moldovan wrote: > * On 31.05.2011 08:06 PM, Ben Greear wrote: >> Probably your NIC is in regdomain 0x6a or similar. >> cfg80211: Calling CRDA for country: US >> cfg80211: Regulatory domain changed to country: US >> cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, >> max_eirp) >> cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) >> cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) >> cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) >> cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) >> cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) >> cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) > > Interestingly, I'm not seeing those messages, even when changing the > domain via iw set reg DE or sorta. > The only message I get is following: > > [ 16.719918] cfg80211: Calling CRDA to update world regulatory domain > > I installed crda just recently without rebooting, maybe that's the > cause. udev was restarted manually after installing crda, but who knows > what else magic is required. I'll power cycle the machine to see whether > I can get more information. I'm just using Fedora 14 with whatever it comes with, though using 'iw' and hostapd etc from recent git repos. > > Oh, and enabling CONFIG_CFG80211_REG_DEBUG may not be the worst idea > either. %) > >> You can over-ride this with a patch similar to this one: >> http://patches.aircrack-ng.org/ath9k_regdomain_override.patch > > Thanks, I'll rather try this than blindly enabling all channels in ath's > regd.c >> Note that you may lose 'official' support by doing this, but as far >> as I can tell, as long as you use the correct domain with 'iw reg set' >> you will still be in regulatory compliance as it chooses the minimal >> set of features supported by the NIC and whatever 'iw reg set' does. > > Chances are AP mode on 5Ghz haven't been tested with this card and the > channels are thus disabled, but I'll have a look nonetheless. What NIC? I had this problem with the Sparklan 127 using the AR9380 chipset... It worked fine in 5Ghz after I 'fixed' the regdomain... Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 18:33 ` Ben Greear @ 2011-05-31 18:38 ` Mihai Moldovan 2011-05-31 18:39 ` Mihai Moldovan 2011-05-31 19:36 ` Mihai Moldovan 0 siblings, 2 replies; 16+ messages in thread From: Mihai Moldovan @ 2011-05-31 18:38 UTC (permalink / raw) To: ath9k-devel * On 31.05.2011 08:33 PM, Ben Greear wrote: > I'm just using Fedora 14 with whatever it comes with, though using > 'iw' and hostapd etc from recent git repos. Gentoo here :) Rebuilding the Kernel soon... well as soon as I revert the regd.c patch. :) > What NIC? I had this problem with the Sparklan 127 using the AR9380 > chipset... SparkLAN WPEA-127NI... ;) Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110531/59f6daca/attachment.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 18:38 ` Mihai Moldovan @ 2011-05-31 18:39 ` Mihai Moldovan 2011-05-31 19:36 ` Mihai Moldovan 1 sibling, 0 replies; 16+ messages in thread From: Mihai Moldovan @ 2011-05-31 18:39 UTC (permalink / raw) To: ath9k-devel * On 31.05.2011 08:38 PM, Mihai Moldovan wrote: > SparkLAN WPEA-127NI... ;) Fail, sorry. SparkLAN WPEA-127N (NI is 9390.) Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110531/69882adb/attachment.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 18:38 ` Mihai Moldovan 2011-05-31 18:39 ` Mihai Moldovan @ 2011-05-31 19:36 ` Mihai Moldovan 2011-05-31 19:48 ` Ben Greear 1 sibling, 1 reply; 16+ messages in thread From: Mihai Moldovan @ 2011-05-31 19:36 UTC (permalink / raw) To: ath9k-devel * On 31.05.2011 08:38 PM, Mihai Moldovan wrote: > Rebuilding the Kernel soon... well as soon as I revert the regd.c patch. :) Hmm, new patch, but also some bad news: all 5Ghz channels are AP-locked when using German regdomain, most of them even disabled. iw list: Frequencies: * 5180 MHz [36] (18.0 dBm) (passive scanning, no IBSS) * 5200 MHz [40] (18.0 dBm) (passive scanning, no IBSS) * 5220 MHz [44] (18.0 dBm) (passive scanning, no IBSS) * 5240 MHz [48] (18.0 dBm) (passive scanning, no IBSS) * 5260 MHz [52] (disabled) * 5280 MHz [56] (disabled) * 5300 MHz [60] (disabled) * 5320 MHz [64] (disabled) * 5500 MHz [100] (disabled) * 5520 MHz [104] (disabled) * 5540 MHz [108] (disabled) * 5560 MHz [112] (disabled) * 5580 MHz [116] (disabled) * 5600 MHz [120] (disabled) * 5620 MHz [124] (disabled) * 5640 MHz [128] (disabled) * 5660 MHz [132] (disabled) * 5680 MHz [136] (disabled) * 5700 MHz [140] (disabled) * 5745 MHz [149] (18.0 dBm) (passive scanning, no IBSS) * 5765 MHz [153] (18.0 dBm) (passive scanning, no IBSS) * 5785 MHz [157] (18.0 dBm) (passive scanning, no IBSS) * 5805 MHz [161] (18.0 dBm) (passive scanning, no IBSS) * 5825 MHz [165] (18.0 dBm) (passive scanning, no IBSS) That's weird, as we do have 802.11n up to 300MBit/s routers here, so I can't believe it's locked due to legal regulations. My university is running some of those WLAN APs, for instance. Adapted patch against 2.6.38.6: diff -uhr linux-2.6.38.6-orig/drivers/net/wireless/ath/ath9k/init.c linux-2.6.38.6/drivers/net/wireless/ath/ath9k/init.c --- linux-2.6.38.6-orig/drivers/net/wireless/ath/ath9k/init.c 2011-05-10 00:16:23.000000000 +0200 +++ linux-2.6.38.6/drivers/net/wireless/ath/ath9k/init.c 2011-05-31 21:01:51.253906201 +0200 @@ -33,6 +33,11 @@ module_param_named(nohwcrypt, ath9k_modparam_nohwcrypt, int, 0444); MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption"); +static int modparam_override_eeprom_regdomain = -1; +module_param_named(override_eeprom_regdomain, + modparam_override_eeprom_regdomain, int, S_IRUGO); +MODULE_PARM_DESC(override_eeprom_regdomain, "Override regdomain hardcoded in EEPROM with this value (DANGEROUS)."); + int led_blink; module_param_named(blink, led_blink, int, 0444); MODULE_PARM_DESC(blink, "Enable LED blink on activity"); @@ -635,6 +640,7 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw) { struct ath_common *common = ath9k_hw_common(sc->sc_ah); + struct ath_regulatory *regulatory = ath9k_hw_regulatory(sc->sc_ah); hw->flags = IEEE80211_HW_RX_INCLUDES_FCS | IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING | @@ -688,6 +694,14 @@ setup_ht_cap(sc, &sc->sbands[IEEE80211_BAND_5GHZ].ht_cap); } + if (modparam_override_eeprom_regdomain != -1) { + printk(KERN_ERR "ath9k: DANGER! You're overriding EEPROM-defined regulatory domain.\n"); + printk(KERN_ERR "ath9k: Your card was not certified to operate on the domain you choosed.\n"); + printk(KERN_ERR "ath9k: This might result in a violation of your local regulatory rules.\n"); + printk(KERN_ERR "ath9k: Do not ever do that unless you really know what you do!\n"); + regulatory->current_rd = modparam_override_eeprom_regdomain; + } + SET_IEEE80211_PERM_ADDR(hw, common->macaddr); } I guess -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110531/5d530e26/attachment-0001.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 19:36 ` Mihai Moldovan @ 2011-05-31 19:48 ` Ben Greear 2011-05-31 20:00 ` Mihai Moldovan 0 siblings, 1 reply; 16+ messages in thread From: Ben Greear @ 2011-05-31 19:48 UTC (permalink / raw) To: ath9k-devel On 05/31/2011 12:36 PM, Mihai Moldovan wrote: > * On 31.05.2011 08:38 PM, Mihai Moldovan wrote: >> Rebuilding the Kernel soon... well as soon as I revert the regd.c >> patch. :) > > Hmm, new patch, but also some bad news: all 5Ghz channels are AP-locked > when using German regdomain, most of them even disabled. iw list: > > Frequencies: > * 5180 MHz [36] (18.0 dBm) (passive scanning, no IBSS) > * 5200 MHz [40] (18.0 dBm) (passive scanning, no IBSS) > * 5220 MHz [44] (18.0 dBm) (passive scanning, no IBSS) > * 5240 MHz [48] (18.0 dBm) (passive scanning, no IBSS) What does your regdomain related kernel logs look like? Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 19:48 ` Ben Greear @ 2011-05-31 20:00 ` Mihai Moldovan 2011-06-01 7:01 ` Mihai Moldovan 2011-06-01 17:53 ` Ben Greear 0 siblings, 2 replies; 16+ messages in thread From: Mihai Moldovan @ 2011-05-31 20:00 UTC (permalink / raw) To: ath9k-devel * On 31.05.2011 09:48 PM, Ben Greear wrote: > On 05/31/2011 12:36 PM, Mihai Moldovan wrote: >> Frequencies: >> * 5180 MHz [36] (18.0 dBm) (passive scanning, no IBSS) >> * 5200 MHz [40] (18.0 dBm) (passive scanning, no IBSS) >> * 5220 MHz [44] (18.0 dBm) (passive scanning, no IBSS) >> * 5240 MHz [48] (18.0 dBm) (passive scanning, no IBSS) > > What does your regdomain related kernel logs look like? Uh, there is a lot. [ 14.502395] cfg80211: Calling CRDA to update world regulatory domain [ 14.780098] ath9k: Do not ever do that unless you really know what you do! [ 14.780100] ath: EEPROM regdomain: 0x8114 [ 14.780101] ath: EEPROM indicates we should expect a country code [ 14.780102] ath: doing EEPROM country->regdmn map search [ 14.780104] ath: country maps to regdmn code: 0x37 [ 14.780105] ath: Country alpha2 being used: DE [ 14.780106] ath: Regpair used: 0x37 [ 14.780109] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule: [ 14.780111] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780112] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule: [ 14.780114] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780116] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule: [ 14.780118] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780120] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule: [ 14.780122] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780124] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule: [ 14.780126] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780128] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule: [ 14.780130] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780131] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule: [ 14.780133] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780135] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule: [ 14.780137] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780139] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule: [ 14.780141] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780143] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule: [ 14.780145] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780146] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule: [ 14.780149] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 mBm) [ 14.780150] cfg80211: Disabling freq 2467 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780152] cfg80211: Disabling freq 2472 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780154] cfg80211: Disabling freq 2484 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780156] cfg80211: Updating information on frequency 5180 MHz for a 20 MHz width channel with regulatory rule: [ 14.780158] cfg80211: 5140000 KHz - 5360000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780160] cfg80211: Updating information on frequency 5200 MHz for a 20 MHz width channel with regulatory rule: [ 14.780162] cfg80211: 5140000 KHz - 5360000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780163] cfg80211: Updating information on frequency 5220 MHz for a 20 MHz width channel with regulatory rule: [ 14.780165] cfg80211: 5140000 KHz - 5360000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780167] cfg80211: Updating information on frequency 5240 MHz for a 20 MHz width channel with regulatory rule: [ 14.780169] cfg80211: 5140000 KHz - 5360000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780171] cfg80211: Updating information on frequency 5260 MHz for a 20 MHz width channel with regulatory rule: [ 14.780173] cfg80211: 5140000 KHz - 5360000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780175] cfg80211: Updating information on frequency 5280 MHz for a 20 MHz width channel with regulatory rule: [ 14.780177] cfg80211: 5140000 KHz - 5360000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780178] cfg80211: Updating information on frequency 5300 MHz for a 20 MHz width channel with regulatory rule: [ 14.780180] cfg80211: 5140000 KHz - 5360000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780182] cfg80211: Updating information on frequency 5320 MHz for a 20 MHz width channel with regulatory rule: [ 14.780184] cfg80211: 5140000 KHz - 5360000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780186] cfg80211: Disabling freq 5500 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780188] cfg80211: Disabling freq 5520 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780189] cfg80211: Disabling freq 5540 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780191] cfg80211: Disabling freq 5560 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780193] cfg80211: Disabling freq 5580 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780195] cfg80211: Disabling freq 5600 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780197] cfg80211: Disabling freq 5620 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780199] cfg80211: Disabling freq 5640 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780200] cfg80211: Disabling freq 5660 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780202] cfg80211: Disabling freq 5680 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780204] cfg80211: Disabling freq 5700 MHz as custom regd has no rule that fits a 20 MHz wide channel [ 14.780206] cfg80211: Updating information on frequency 5745 MHz for a 20 MHz width channel with regulatory rule: [ 14.780208] cfg80211: 5715000 KHz - 5860000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780210] cfg80211: Updating information on frequency 5765 MHz for a 20 MHz width channel with regulatory rule: [ 14.780212] cfg80211: 5715000 KHz - 5860000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780213] cfg80211: Updating information on frequency 5785 MHz for a 20 MHz width channel with regulatory rule: [ 14.780215] cfg80211: 5715000 KHz - 5860000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780217] cfg80211: Updating information on frequency 5805 MHz for a 20 MHz width channel with regulatory rule: [ 14.780219] cfg80211: 5715000 KHz - 5860000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.780221] cfg80211: Updating information on frequency 5825 MHz for a 20 MHz width channel with regulatory rule: [ 14.780223] cfg80211: 5715000 KHz - 5860000 KHz @ KHz), (N/A mBi, 3000 mBm) [ 14.782249] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule: [ 14.782252] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782254] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule: [ 14.782256] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782258] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule: [ 14.782260] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782261] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule: [ 14.782263] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782265] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule: [ 14.782267] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782269] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule: [ 14.782271] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782273] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule: [ 14.782275] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782277] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule: [ 14.782279] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782281] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule: [ 14.782283] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782285] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule: [ 14.782287] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782289] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule: [ 14.782291] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782292] cfg80211: Updating information on frequency 2467 MHz for a 20 MHz width channel with regulatory rule: [ 14.782294] cfg80211: 2457000 KHz - 2482000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782296] cfg80211: Updating information on frequency 2472 MHz for a 20 MHz width channel with regulatory rule: [ 14.782298] cfg80211: 2457000 KHz - 2482000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782300] cfg80211: Updating information on frequency 2484 MHz for a 20 MHz width channel with regulatory rule: [ 14.782302] cfg80211: 2474000 KHz - 2494000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782304] cfg80211: Updating information on frequency 5180 MHz for a 20 MHz width channel with regulatory rule: [ 14.782306] cfg80211: 5170000 KHz - 5250000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782308] cfg80211: Updating information on frequency 5200 MHz for a 20 MHz width channel with regulatory rule: [ 14.782310] cfg80211: 5170000 KHz - 5250000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782312] cfg80211: Updating information on frequency 5220 MHz for a 20 MHz width channel with regulatory rule: [ 14.782314] cfg80211: 5170000 KHz - 5250000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782316] cfg80211: Updating information on frequency 5240 MHz for a 20 MHz width channel with regulatory rule: [ 14.782318] cfg80211: 5170000 KHz - 5250000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782319] cfg80211: Disabling freq 5260 MHz [ 14.782320] cfg80211: Disabling freq 5280 MHz [ 14.782322] cfg80211: Disabling freq 5300 MHz [ 14.782323] cfg80211: Disabling freq 5320 MHz [ 14.782324] cfg80211: Disabling freq 5500 MHz [ 14.782325] cfg80211: Disabling freq 5520 MHz [ 14.782326] cfg80211: Disabling freq 5540 MHz [ 14.782327] cfg80211: Disabling freq 5560 MHz [ 14.782329] cfg80211: Disabling freq 5580 MHz [ 14.782330] cfg80211: Disabling freq 5600 MHz [ 14.782331] cfg80211: Disabling freq 5620 MHz [ 14.782332] cfg80211: Disabling freq 5640 MHz [ 14.782333] cfg80211: Disabling freq 5660 MHz [ 14.782334] cfg80211: Disabling freq 5680 MHz [ 14.782336] cfg80211: Disabling freq 5700 MHz [ 14.782337] cfg80211: Updating information on frequency 5745 MHz for a 20 MHz width channel with regulatory rule: [ 14.782339] cfg80211: 5735000 KHz - 5835000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782341] cfg80211: Updating information on frequency 5765 MHz for a 20 MHz width channel with regulatory rule: [ 14.782343] cfg80211: 5735000 KHz - 5835000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782345] cfg80211: Updating information on frequency 5785 MHz for a 20 MHz width channel with regulatory rule: [ 14.782347] cfg80211: 5735000 KHz - 5835000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782349] cfg80211: Updating information on frequency 5805 MHz for a 20 MHz width channel with regulatory rule: [ 14.782351] cfg80211: 5735000 KHz - 5835000 KHz @ KHz), (600 mBi, 2000 mBm) [ 14.782352] cfg80211: Updating information on frequency 5825 MHz for a 20 MHz width channel with regulatory rule: [ 14.782354] cfg80211: 5735000 KHz - 5835000 KHz @ KHz), (600 mBi, 2000 mBm) The disabled freqs are fine, but I guess the passive scan/no ibss frequencies are overridden by the driver (ath/regd.c). Getting rid of this unlocks the channels, but still... Best regards, Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110531/ff18cd51/attachment.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 20:00 ` Mihai Moldovan @ 2011-06-01 7:01 ` Mihai Moldovan 2011-06-01 14:31 ` Mihai Moldovan 2011-06-01 17:53 ` Ben Greear 1 sibling, 1 reply; 16+ messages in thread From: Mihai Moldovan @ 2011-06-01 7:01 UTC (permalink / raw) To: ath9k-devel * On 31.05.2011 10:00 PM, Mihai Moldovan wrote: > * On 31.05.2011 09:48 PM, Ben Greear wrote: >> On 05/31/2011 12:36 PM, Mihai Moldovan wrote: >>> Frequencies: >>> * 5180 MHz [36] (18.0 dBm) (passive scanning, no IBSS) >>> * 5200 MHz [40] (18.0 dBm) (passive scanning, no IBSS) >>> * 5220 MHz [44] (18.0 dBm) (passive scanning, no IBSS) >>> * 5240 MHz [48] (18.0 dBm) (passive scanning, no IBSS) Weird indeed, as... regdbdump (2011-11-24): country DE: (2400.000 - 2483.500 @ 40.000), (N/A, 20.00) (5150.000 - 5250.000 @ 40.000), (N/A, 20.00), NO-OUTDOOR (5250.000 - 5350.000 @ 40.000), (N/A, 20.00), NO-OUTDOOR, DFS (5470.000 - 5725.000 @ 40.000), (N/A, 26.98), DFS At least the 5150 - 5250 MHz band (a few channels) should work. No idea what NO-OUTDOOR does, but it shouldn't kill beaconing, I guess. Though, iw reg get says: country 00: (2402 - 2472 @ 40), (6, 20) (2457 - 2482 @ 20), (6, 20), PASSIVE-SCAN, NO-IBSS (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS (5170 - 5250 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS (5735 - 5835 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS which STILL is the world regulatory domain! Setting iw reg set DE does nothing, but prints such a message in the Kernel log: [37975.036703] cfg80211: Pending regulatory request, waiting for it to be processed... It never returns something like "success" or even a message that the new regdomain has been set, and what regdomain exactly. Also, querying the regdomain via iw reg get produces the same output (country 00 - world) as before. This may also explain why forcing another regdomain doesn't work so well. I suspect a Kernel bug somewhere, interesting. Best regards, Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110601/701ca083/attachment.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-06-01 7:01 ` Mihai Moldovan @ 2011-06-01 14:31 ` Mihai Moldovan 2011-06-01 14:45 ` Mihai Moldovan 0 siblings, 1 reply; 16+ messages in thread From: Mihai Moldovan @ 2011-06-01 14:31 UTC (permalink / raw) To: ath9k-devel Ok, some more information. Kernel: 2.6.38.6 I first thought of a race condition, as the cfg80211 subsystem tries to get an updated world entry of the regdb pretty early. However, at that time udev was already started: [ 14.319904] udev: starting version 151 [ 14.319960] udevd (2041): /proc/2041/oom_adj is deprecated, please use /proc/2041/oom_score_adj instead. [ 14.613461] md2: unknown partition table [ 14.617229] cfg80211: Calling CRDA to update world regulatory domain [ 14.645768] e1000e: Intel(R) PRO/1000 Network Driver - 1.2.20-k2 [ 14.645771] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. ... Interestingly, cfg80211 wants to update the world regdom right before loading another network interface module (e1000e), which is a wired interface. Could this cause problems? This call obviously never returns, as regdomain changes afterwards are all queued but will never be acted upon: [ 18.262657] cfg80211: Pending regulatory request, waiting for it to be processed... (and several other of those messages) In order to see whether udev gets a regulatory change event, I enabled udevadm monitoring and came to this conclusion: KERNEL[1306936946.968633] add /module/cfg80211 (module) UDEV_LOG=3 ACTION=add DEVPATH=/module/cfg80211 SUBSYSTEM=module SEQNUM=2849 KERNEL[1306936946.968645] add /class/ieee80211 (class) UDEV_LOG=3 ACTION=add DEVPATH=/class/ieee80211 SUBSYSTEM=class SEQNUM=2850 KERNEL[1306936946.968711] add /devices/platform/regulatory.0 (platform) UDEV_LOG=3 ACTION=add DEVPATH=/devices/platform/regulatory.0 SUBSYSTEM=platform MODALIAS=platform:regulatory SEQNUM=2851 KERNEL[1306936946.968750] change /devices/platform/regulatory.0 (platform) UDEV_LOG=3 ACTION=change DEVPATH=/devices/platform/regulatory.0 SUBSYSTEM=platform COUNTRY=00 MODALIAS=platform:regulatory SEQNUM=2852 UDEV [1306936946.968830] add /module/cfg80211 (module) UDEV_LOG=3 STARTUP=1 ACTION=add DEVPATH=/module/cfg80211 SUBSYSTEM=module SEQNUM=2849 UDEV [1306936946.968902] add /class/ieee80211 (class) UDEV_LOG=3 STARTUP=1 ACTION=add DEVPATH=/class/ieee80211 SUBSYSTEM=class SEQNUM=2850 UDEV [1306936946.969934] add /devices/platform/regulatory.0 (platform) UDEV_LOG=3 STARTUP=1 ACTION=add DEVPATH=/devices/platform/regulatory.0 SUBSYSTEM=platform MODALIAS=platform:regulatory SEQNUM=2851 So, yep, udev is getting the change requests (two actually, as both ath9k cards are added to the system.) The rule should work fine too: KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda" Nothing broken here. One last thing I'll try is removing one ath9k card to see whether it works with one card only. Maybe ath9k or cfg80211 is broken here when using multiple cards at the same time. Other than that, I'm out of ideas. As far as I know, Luis is good with this CRDA stuff, so I'll CC him, just to make sure I'm not missing anything. I tried crda versions 1.0.1, 1.1.1 and git, though the behavior was the same throughout all versions. Posting results with one card only soon. Best regards and thanks, Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110601/ad7e5d68/attachment.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-06-01 14:31 ` Mihai Moldovan @ 2011-06-01 14:45 ` Mihai Moldovan 0 siblings, 0 replies; 16+ messages in thread From: Mihai Moldovan @ 2011-06-01 14:45 UTC (permalink / raw) To: ath9k-devel * On 01.06.2011 04:31 PM, Mihai Moldovan wrote: > One last thing I'll try is removing one ath9k card to see whether it > works with one card only. Maybe ath9k or cfg80211 is broken here when > using multiple cards at the same time. Nope, same problem with one Atheros WiFi card only. Now I'm out of ideas. :/ Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110601/970856a2/attachment-0001.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-05-31 20:00 ` Mihai Moldovan 2011-06-01 7:01 ` Mihai Moldovan @ 2011-06-01 17:53 ` Ben Greear 2011-06-01 18:37 ` Mihai Moldovan 1 sibling, 1 reply; 16+ messages in thread From: Ben Greear @ 2011-06-01 17:53 UTC (permalink / raw) To: ath9k-devel On 05/31/2011 01:00 PM, Mihai Moldovan wrote: > * On 31.05.2011 09:48 PM, Ben Greear wrote: >> On 05/31/2011 12:36 PM, Mihai Moldovan wrote: >>> Frequencies: >>> * 5180 MHz [36] (18.0 dBm) (passive scanning, no IBSS) >>> * 5200 MHz [40] (18.0 dBm) (passive scanning, no IBSS) >>> * 5220 MHz [44] (18.0 dBm) (passive scanning, no IBSS) >>> * 5240 MHz [48] (18.0 dBm) (passive scanning, no IBSS) >> >> What does your regdomain related kernel logs look like? > > Uh, there is a lot. > > [ 14.502395] cfg80211: Calling CRDA to update world regulatory domain > [ 14.780098] ath9k: Do not ever do that unless you really know what you do! > [ 14.780100] ath: EEPROM regdomain: 0x8114 > [ 14.780101] ath: EEPROM indicates we should expect a country code > [ 14.780102] ath: doing EEPROM country->regdmn map search > [ 14.780104] ath: country maps to regdmn code: 0x37 > [ 14.780105] ath: Country alpha2 being used: DE > [ 14.780106] ath: Regpair used: 0x37 > [ 14.780109] cfg80211: Updating information on frequency 2412 MHz for a > 20 MHz width channel with regulatory rule: > [ 14.780111] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A mBi, 2000 ... > The disabled freqs are fine, but I guess the passive scan/no ibss > frequencies are overridden by the driver (ath/regd.c). Maybe the ath/regd.c just needs fixing to support DE regdomains? I haven't actually looked at the code.... Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] AR9380 + hostapd + HT over 802.11a 2011-06-01 17:53 ` Ben Greear @ 2011-06-01 18:37 ` Mihai Moldovan 0 siblings, 0 replies; 16+ messages in thread From: Mihai Moldovan @ 2011-06-01 18:37 UTC (permalink / raw) To: ath9k-devel Hi Ben, * On 01.06.2011 07:53 PM, Ben Greear wrote: > Maybe the ath/regd.c just needs fixing to support DE regdomains? Nope, something's broken in/with CRDA and the Kernel. Compiling the regdb statically into the Kernel works fine, on both 3.6.38.6 and 3.6.39 (though 3.6.39 is panicing after a few seconds somewhere in tcpmss_xxx.c... yeah... sounds like another bug report...) Both cards are working now, one on 5GHz with German regdom. I still wonder why CRDA doesn't work, but debugging this is pretty difficult. Thanks, Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110601/f6207c13/attachment.bin ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-06-01 18:37 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-05-31 17:36 [ath9k-devel] AR9380 + hostapd + HT over 802.11a Mihai Moldovan 2011-05-31 17:56 ` Peter Stuge 2011-05-31 18:17 ` Mihai Moldovan 2011-05-31 18:06 ` Ben Greear 2011-05-31 18:29 ` Mihai Moldovan 2011-05-31 18:33 ` Ben Greear 2011-05-31 18:38 ` Mihai Moldovan 2011-05-31 18:39 ` Mihai Moldovan 2011-05-31 19:36 ` Mihai Moldovan 2011-05-31 19:48 ` Ben Greear 2011-05-31 20:00 ` Mihai Moldovan 2011-06-01 7:01 ` Mihai Moldovan 2011-06-01 14:31 ` Mihai Moldovan 2011-06-01 14:45 ` Mihai Moldovan 2011-06-01 17:53 ` Ben Greear 2011-06-01 18:37 ` Mihai Moldovan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.