From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mihai Moldovan Date: Tue, 31 May 2011 20:17:52 +0200 Subject: [ath9k-devel] AR9380 + hostapd + HT over 802.11a In-Reply-To: <20110531175658.30439.qmail@stuge.se> References: <4DE52724.2040300@ionic.de> <20110531175658.30439.qmail@stuge.se> Message-ID: <4DE530D0.1040601@ionic.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org * 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