Bugzilla – Bug 17071
Radio does not offer full channel range in non-US Regulatory Domains
Last modified: 2012-03-15 06:14:22 UTC
The Squeezebox Radio wireless LAN dows not consistently offer the full range of channels for the country in which it is being used. Several users have reported its inconsistent behaviour - mostly defaulting to the US regulatory domain (channels 1-11), but occasionally, seemingly randomly, offering 13 or 14 channels. It is thought this may be due to it being set to "world-wide". As we understand it, in this mode the number of channels is defined by the regulatory domain of neighbouring APs, which, we guess, may or may not be correct. Since one user, at least, lives in an area with minimal neighbouring APs, all of which should have the correct regulatory domain, it may be that the driver simply does not do a good job of determining the regulatory domain during this startup phase. Another possibility is that most routers/APs are not broadcasting their regulatory domain and the driver then defaults to "US", 1-11. The inconsistent behaviour has been proven in the thread linked above. The solution is to define the regulatory domain within the wlan startup script. The amended wlan script is in the thread above.
Tested with 7.5.3 and 7.6.0 nightly (16th March). Both behave the same.
For any dev/support staff reading, let me expand a little on why I have marked this bug as "Major": - Failure to listen to/connect on channels 12-14 will stop the Radio connecting to some users APs out of the box. They will have no choice but to contact Logitech Support, who are currently unaware of the issue. - Logitech Support are currently of the view that the Radio "works world-wide" and should work on these channels. They are, at 1st line, insisting there must be some interference/channel conflict with neighbours causing the issue. If users are tech savvy enough to convince Support this is not the case (most won't be!) then 2nd line are either suspecting AP incompatibility or actually swapping out the Radios, suspecting a build fault, at significant cost! - Whilst a reasonable workaround for some might be to change AP channel - Many of those users will not even know how to change their AP channel. - This does not work if the AP is not their own, e.g. in a hotel. Here, they will simply find their Radio does not always work when they take it with them. It is presumably this desire for portability that inspired the decision to go with a world-wide REGDOM in the first place, unlike the Touch, which gets you to assign your region after factory reset. At the very least Support need to be updated as a matter of some urgency, so they can recommend changing to channels 1-11, where this is possible. To prevent significant usability issues for people during first install and when using 3rd party APs I think this bug needs to be rapidly addressed.
This is how I would go about fixing this issue for all users: - First I'd discuss with Atheros the non-deterministic results being obtained by users when the AR6000 chipset is in world-wide SKU mode. Maybe there is an updated driver that resolves the issue? This seems possible. There are a lot of globally mobile devices around these days, not least smartphones, that also need to work in a range of REGDOMs. They do not seem to have the problem the SQ radio has. -However, it is possible that the idea of an adaptive regulatory domain, based on neighbouring APs just does not work in the real world, given the way APs are being configured, or the AR6000 implementation is broken in way that cannot be fixed. If this is the case there would seem to be two solutions: 1. Simplest: Simply set the Radio's REGDOM to "Japan" and make it able to connect on all channels, 1-14. This may be acceptable as the Radio does not support ad-hoc mode, so in practice will only be able to connect to neighbouring APs, which should be operating within the channel range of the appropriate REGDOM. The REGDOM also has an impact on some other features, such as allowable TxPower, but it is not known how big an issue this would be in practice. 2. If it is not possible to fix the world-wide SKU implementation or simply set the Radio for the widest possible channel range it would be necessary to implement a method for setting the country of operation similar to that currently in the Touch. However, due to the mobile nature of the Radio this should not be implemented only following a factory reset. There should be an option on the "Advanced/Networking" screen to "Choose Country". Since it is possible to change REGDOM in the Radio by simply stopping and restarting the wireless LAN this change can be effected without the need to even reboot the Radio.
*** This bug has been confirmed by popular vote. ***
Hello David Thank you very much for the detailed bug report. I was able to recreate the situation and to see the issue. (BTW: my iPad also failed to see channel 13 in that scenario.) Talking to Atheros I learned that the WiFi driver uses the AP with the strongest signal to determine the regulatory domain to use. So we would need to ask the user to choose the regulatory domain which means an additional step. Also the switch between regulatory domains requires a restart of the WiFi driver (unlike on SB Touch where it can be set without reloading) and I found it takes up to 15 seconds after that for it to become fully functional again. So after internal discussion and talking to our support team the decision has been made not to do that and to keep the existing setup flow (at least for now). Felix
Hi Felix, Thanks very much for clearly spending significant time looking into this issue and also fully updating me on your conclusion. It is interesting to here how Atheros expect this to work. I must admit though I am surprised by the decision. It is clear the Atheros methodology is, in practice, fundamentally flawed. Anecdotally and in my own practical experience (outlined in the forum thread linked above) people take access points all over the world with them and also import them for other regdoms (esp. USA). When my Radio is set to factory default I can repeatedly check the regdom and, as shown in the thread, come up with different results, presumably based on transient signal strength. This is not very satisfactory! I can imagine it works very well in rural mid-America, but in any global city, like London, New York, L.A., Singapore, Tokyo it will cause problems. Coincidentally, they are probably where most radios are used and, as I said earlier, if someone is trying to use their radio in a hotel in a non-US location and that hotel is using a channel >11 it will not work (much of the time!) and there is NOTHING they can do about it. I wonder why you feel the need to limit the regdom at all on the radio. Since it does not support adhoc mode it will only connect on a channel >11 if there is an accessible AP which is using that channel and, by definition and design, the radio will already quite happily switch to that regdom and connect to that AP if the radio was close enough to it! The current config does not do anything to stop that regdom being used, it only makes it dependent on the transient signal strength, so is practically a worse than useless form of "protection". Setting the regdom to "Japan" by a simple one line change to the wlan file - "/lib/atheros/loadAR6000l.sh $SETMAC --setRD 96" would simply mean it would connect to any visible AP, regardless of signal strength. Surely better? David ps. interesting what you say about the iPad. I can only say that, here, my iPad and iPhone have never had an issue connecting to my AP, but not my SB Radio. :Confused:
I should add that my Radio only had problems connecting before I patched my wlan file to support channels 1-13. Since then it has been rock solid :)