What's new

5GHz, 802.11ac and 802.11h in UK and EU

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

aircoreboy

Regular Contributor
Over the last couple of months, my 5GHz wifi has become practically unusable with an 80 MHz channel width (to achieve full speed on the ac bridge in the bedroom) which I have recently discovered is because of interference from the Wii U gamepad which uses the four lower channels of the 5GHz band that are obviously all in use since the 80MHz channel width covers all four of the lower bands. This is not good since 5GHz devices are going to become more numerous and on what I assume is a non-DFS supported router, the AC66U, I have no access to channels higher up the band since in the UK and I assume the rest of Europe, all channels above 48 require DFS, rendering my ac network unusable and basically reducing my AC66 to an N66. I have also recently discovered that the standard for implementing DFS and TPC is 802.11h which the AC66U does make use of on the 5GHz band, at least with Rmerlin firmware, and this left me with a few questions,

1. Why implement 802.11h regulation mode on 5GHz when the AC66U can only access the four non-DFS channels?,

2. If 802.11h is properly implemented, why are channels above 48 not accessable?,

3. Is 802.11h properly implemented?,

4. If 802.11h is not properly implemented, could this be having an effect on the four lower 5GHz channels?,

5. If 802.11d+h is being used, then as per the 802.11d standard, the router should advertise what jurisdiction it is operating in (removing the need for manufacturers to release jurisdiction specific models) and with 802.11h, offer access to all available channels within advertised jurisdiction, why is this not happening? (incidentally, "As of January 1st, 2015, the U.S. FCC banned the use of 802.11d within the U.S.", it would be interesting to see if USA users had access to regulation mode 802.11d)



Ref: http://en.wikipedia.org/wiki/IEEE_802.11h-2003

Ref: https://docs.google.com/file/d/0ByA6tWZXOSXuZThyOUxVY2UxZmM/edit?pli=1

Ref: http://www.digitalairwireless.com/wireless-blog/t-5ghz/quick-guide-to-5ghz-uk-part-1.html

Ref: http://www.digitalairwireless.com/wireless-blog/t-5ghz/quick-guide-to-5ghz-uk-part-2.html

Ref: http://en.wikipedia.org/wiki/IEEE_802.11d-2001
 
Last edited:
that's odd - you should have access to both the UNII-1 and UNII-2 channels (UK A/B bands in 5GHz)

802.11h support is there in the SW and chipset drivers, but in the past, some of the Asus gear might not have the right NV items enabled

Telnet/SSH into the router and check the following commands:

nvram set wl0_reg_mode=h
nvram set wl1_reg_mode=h
nvram commit
reboot

See what happens there....

As far as 802.11d - FCC has grandfathered in devices that were already certified, but moving forward post 1/1/2015, new devices (or permissive change submissions for legacy certs), 802.11d support must be explicitly removed. Not really a big deal in any event.
 
that's odd - you should have access to both the UNII-1 and UNII-2 channels (UK A/B bands in 5GHz)

802.11h support is there in the SW and chipset drivers, but in the past, some of the Asus gear might not have the right NV items enabled

Telnet/SSH into the router and check the following commands:

nvram set wl0_reg_mode=h
nvram set wl1_reg_mode=h
nvram commit
reboot

See what happens there....

As far as 802.11d - FCC has grandfathered in devices that were already certified, but moving forward post 1/1/2015, new devices (or permissive change submissions for legacy certs), 802.11d support must be explicitly removed. Not really a big deal in any event.


Done, but still only access to four lower channels even if channel selection set to auto,

nvram get wl0_reg_mode=h
nvram get wl1_reg_mode=h

cat /dev/mtd0 | grep ccode=
pci/1/1/ccode=US
pci/2/1/ccode=US

cat /dev/mtd0 | grep regrev=
pci/1/1/regrev=13
pci/2/1/regrev=13

cat /dev/mtd0 | grep model=
model=RT-AC66U

cat /dev/mtd0 | grep version=
hw_version=1.5
bl_version=1.0.1.4

nvram show | grep ccode=
pci/2/1/ccode=GB
pci/1/1/ccode=GB
size: 45451 bytes (20085 left)

nvram show | grep regrev=
pci/1/1/regrev=13
pci/2/1/regrev=13
size: 45451 bytes (20085 left)

nvram show | grep bl_version=
bl_version=1.0.1.4
size: 45451 bytes (20085 left)
 
Over the last couple of months, my 5GHz wifi has become practically unusable with an 80 MHz channel width (to achieve full speed on the ac bridge in the bedroom) which I have recently discovered is because of interference from the Wii U gamepad which uses the four lower channels of the 5GHz band that are obviously all in use since the 80MHz channel width covers all four of the lower bands. This is not good since 5GHz devices are going to become more numerous and on what I assume is a non-DFS supported router, the AC66U, I have no access to channels higher up the band since in the UK and I assume the rest of Europe, all channels above 48 require DFS, rendering my ac network unusable and basically reducing my AC66 to an N66. I have also recently discovered that the standard for implementing DFS and TPC is 802.11h which the AC66U does make use of on the 5GHz band, at least with Rmerlin firmware, and this left me with a few questions,

1. Why implement 802.11h regulation mode on 5GHz when the AC66U can only access the four non-DFS channels?,

2. If 802.11h is properly implemented, why are channels above 48 not accessable?,

3. Is 802.11h properly implemented?,

4. If 802.11h is not properly implemented, could this be having an effect on the four lower 5GHz channels?,

5. If 802.11d+h is being used, then as per the 802.11d standard, the router should advertise what jurisdiction it is operating in (removing the need for manufacturers to release jurisdiction specific models) and with 802.11h, offer access to all available channels within advertised jurisdiction, why is this not happening? (incidentally, "As of January 1st, 2015, the U.S. FCC banned the use of 802.11d within the U.S.", it would be interesting to see if USA users had access to regulation mode 802.11d)



Ref: http://en.wikipedia.org/wiki/IEEE_802.11h-2003

Ref: https://docs.google.com/file/d/0ByA6tWZXOSXuZThyOUxVY2UxZmM/edit?pli=1

Ref: http://www.digitalairwireless.com/wireless-blog/t-5ghz/quick-guide-to-5ghz-uk-part-1.html

Ref: http://www.digitalairwireless.com/wireless-blog/t-5ghz/quick-guide-to-5ghz-uk-part-2.html

Ref: http://en.wikipedia.org/wiki/IEEE_802.11d-2001

There is a very long thread here at SNB discussing DFS and TPC requirements in both the U.S. and EU that will answer most of your questions. See: http://www.snbforums.com/threads/asus-locking-down-routers-to-comply-with-new-fcc-rules.18762/

In the meantime, I would suggest you read this PDF from the WiFi Alliance (it's from 2007, but will give you all the info you ever wanted, and more, about DFS, TPC and the various types of radar in both the US, Canada and the EU): Spectrum Sharing in the 5ghz Band, DFS Best Practices.

My understanding is that the Wii U gamepad uses an unencrypted 5ghz connection between the console and the game pad unit, which does use one of the 5ghz lower UNI band channels (36-48). The range of the Wii game pad is only about 6 feet though, so if you're experiencing issues with your AC66 not being able to hold an 80mhz channel width (i.e., true "AC"), then you might want to consider using the Wii somewhere more distant from your router.
In short what you're seeing has nothing to do with DFS/TPC, but instead has to do with the contention and coexistence routines that are part of 802.11 protocol. As in the 2.4ghz band, co-existence and contention protections will cause your channel width's to drop down from 80mhz to either 40mhz or 20mhz when other networks are nearby. Thus, if the Wii is using one of the same channels that is in use in your 80mhz width, your router drops down to either a 40mhz or 20mhz width. Not much you can do about it other than move the Wii so it's connection between the gamepad and the base unit is far enough away from your router that it won't interfere with your router's channels.

With regard to DFS and TPC and 802.11h, yes, .11h is the protocol that tells your router when a radar channel is detected to switch channels. You are also correct that in the EU (and the UK, which is bound to follow ETSI and not any local requirements), the lower UNI band (channels 36-48) does not require DFS and TPC to be implemented. So why doesn't your AC66U also make available the upper band channels that do require DFS/TPC? Because it's a legacy device on which Asus didn't enable any of the upper band channels. Newer devices sold by Asus in the EU do enable channels in the upper bands. Why does your router firmware (presumably some version of Merlin's FW) then show that both 802.11d and 802.11h (or just 802.11h) is being implemented? Well, actually in Merlin's FW, if you go into the "Professional" tab for 5ghz, you can adjust regulation mode so that if you're only using the lower band, non-radar channels, you can turn off both .11d and .11h. If you're using the upper band channels where implementation of DFS/TPC is manadatory, .11h should be implemented.

And as for .11d, what SFX2000 said. The FCC's mandate though has nothing to do with the EU and it really has nothing to do with AP's either. ETSI enacted regulations that govern country codes in client devices (.11d has to do with clients, not with AP's). In the EU a of Jan. 1 2014, both routers and client devices must have fixed region codes and these are not permitted sold in the EU if the end user can change the device's (AP or client) region coding.
.11d is a protocol that allows clients (not AP's) to automatically configure themselves; the client radio scans for a beacon from the AP to find the country code that the AP is using and thereby to configure itself to use the region coding that is being broadcast. Since AP's can only now (under both FCC and ETSI) be configured for the region they are sold in (for example, a device sold in the U.S. can only be set for U.S. region coding by the manufacturer), .11d is no longer needed. Same for the EU under ETSI regulations.

Your AC66U is obviously a device that was sold prior to the changes in regulations. If you're trying to achieve an 80mhz channel width in the EU (or UK) and there are any other AP's nearby (close enough to be detected by your router), because of co-existence and contention routines built into 802.11, you won't be able to use 80mhz reliably. This is just a fact of life with .11ac in areas where others are using the same channels.
 
Last edited:
Thanks sfx and jegesq for the clarification and advice. jegesq, I was aware of the thread you mention, I even posted to it early on but could not bring myself to go through the whole thing without first ingesting some kind of controlled substance, I hadn't realised it contained any useful, varifiable information.

Incidentally there is no longer the option to turn off regulation mode on 5GHz, I believe on Rmerlin or Asus, which seems odd, since with no access to DFS channels on the AC66, why is it needed, may just be an artefact of asuswrt being cross-model. Anyway, thanks again, will try moving the router first, but will probably invest in a new one quite soon, since as you say, the AC66 is a legacy device now.

Edit: Just had a read of the pdf you mention and found this quite intersting:


9.4.1 Access Point with Clients:
Here the Access Point acts as the Master device and does the DFS (radar detection) on
behalf of all the (associated) devices within its vicinity. The implications are that:

a) If a client device loses connection to the access point, it may not use active
scanning to associate itself again to this or to another access point unless it does
its own radar detection. Passive scanning obviously is allowed as the client only
listens in this mode.


Since asuswrt (and Rmerlin-asuswrt) now default to 802.11h (DFS) on the AC66 5GHz with no option of turning it off, could this be the cause of any of the problems I am having, even though only non-DFS channels are being used. The fact that 11d is no longer needed and also that the AC66 cannot be localised retro-actively, I'm assuming is the reason Asus locked down the router to only the lower four channels, it therefore seems that implementing a complex standard as 802.11h (DFS) is on a device where it is not needed is just that, not necessary, and potentially problem causing.
 
Last edited:
Asus has never bothered adding support for any channel apart from 36-48 on uk models
i advise you hack your bootloader to #a and forget about it

also regulation mode is still there for me on 378.52


Untitled.jpg
 
Asus has never bothered adding support for any channel apart from 36-48 on uk models
i advise you hack your bootloader to #a and forget about it

also regulation mode is still there for me on 378.52


Untitled.jpg

That's odd because I only have 11h or 11d+h, I was considering the hack which is why I was enquiring whether the AC66 will use DFS once the upper channels are opened up.
 
Just get it over and done with and forget about it

It used to bug the crap out of me having no channels
I hacked the bootloader around a year ago and have been running on channel 120 since

I advise you use the us bootloader that's the same revsion as yours edited to #a
make sure you take a backup of yours
and take your time editing it making sure you havnt missed anything

I get an extra bar on us bootloader 5ghz #a compared to my eu bootloader edited to #a
 
Well, this sure took me down a rathole of research... but I'll share what I've found:

1) The Wii U Gamepad to Wii U - it uses a modified version of Miracast - WiFi Direct to attach, and they have some special sauce to do the peering and authentication - it's WPS for the most part, but how they handle the pairwise keys is Nintendo specific...

2) As the OP suggested, the Gamepad connection is 5GHz - the Wii U basestation advertises a BSS SSID with a null SSID (it's not cloaked, it's null)

3) When you go to pair them up - the Wii U displays 4 characters - Spade (0), Heart (1), Diamond (2), and Club (3) - it uses this along with a fixed constant of 5678 - so of you see Spade, Spade, Diamond, Club, the WPS key is 00235678 - cute, and clever by too far...

4) If you're playing around with Wireshark, the RSN suites to consider

Pairwise - a4:c0:e1
Group - same as above
Auth Key Management - same as above

Special Nintendo sauce here - they take the standard pairwise CCM, and rotate the PTK three bytes to the left.. Take Nintendo and make it tendoNin and you're on the right track

This is one part of the Proprietary Stuff I mention above...

5) So.. WiFi Direct in 5GHz, some special nintendo keying/obfuscation on the WPA2

6) Upper Layer stuff - mostly Miracast as a transport, and does some more clever hackage there...

7) Video Streams - pretty much standard h264 from the WiiU to the Gamepad and from the Gamepad back to the WiiU for the Web Camera - clever hack here is that Nintendo uses the AP beacon Timestamps to sync the streams for Video and Audio - neat stuff! and removes dependency on the Gamepad to have a rather precise clock - one can also use "back to the future" from the AP timestamps to get things synced up again.

Pretty fun... anyways, where this takes us back to the original issue...

The Gamepad uses a WiFi Direct connection to the Wii U basestation - it's a single stream 802.11n wide channel, starting at Ch 36 (I haven't seen anything that suggests otherwise, but I don't have a Wii U to confirm this). This makes sense as Ch 36 is a low power channel and one that is generally available and acceptable on a global basis..

Based on Specs, it's pretty low power - my guess is around 16 dBm at best, considering the use case and battery power constraints - the Gamepad has more gubbins inside than just the WiFi chipset (Broadcom BTW..)

I would think that a Router/AP would interfere more with the Wii U/Gamepad - rather than the other way around - worst case, if one has to live in the lower channels, set the AP to Ch 36, and 11ac and the 11n Gamepad/Wii U should live together just fine...

HTH...

sfx
 
My understanding is that the Wii U gamepad uses an unencrypted 5ghz connection between the console and the game pad unit, which does use one of the 5ghz lower UNI band channels (36-48). The range of the Wii game pad is only about 6 feet though, so if you're experiencing issues with your AC66 not being able to hold an 80mhz channel width (i.e., true "AC"), then you might want to consider using the Wii somewhere more distant from your router.

See my notes above - it's WPA2 with WPS on a WIFi Direct connection between the base and the gamepad - camps on Ch 36 from what I've found..

So setting the AP to 36 is actually the best approach if no other Options are available - The WiiU should yield time to the Router/AP, but they need to be aware - the Channel in the AP also sets the 20MHz channel for the Beacon Frames for the AP - beacon frames are always 20MHz so that any STA's can see them - 11a/b/g/n/ac
 
Last edited:
Thanks sfx and jegesq for the clarification and advice. jegesq, I was aware of the thread you mention, I even posted to it early on but could not bring myself to go through the whole thing without first ingesting some kind of controlled substance, I hadn't realised it contained any useful, varifiable information.

<snip>

Since asuswrt (and Rmerlin-asuswrt) now default to 802.11h (DFS) on the AC66 5GHz with no option of turning it off, could this be the cause of any of the problems I am having, even though only non-DFS channels are being used. The fact that 11d is no longer needed and also that the AC66 cannot be localised retro-actively, I'm assuming is the reason Asus locked down the router to only the lower four channels, it therefore seems that implementing a complex standard as 802.11h (DFS) is on a device where it is not needed is just that, not necessary, and potentially problem causing.

Perhaps it's just a bum AP? If it's been working ok, and recently started having issues...

My research this afternoon on how the Wii U works, it really shouldn't impact your WLAN connections to the AP...

sfx
 
Thanks for helping me narrow this down, you fella's have gone above and beyond here, thanks for all the useful info, your time and help is very much appreciated!
 
My UK RT-N66U with EU mode has always had 20/40MHz available in bands 100-140 -is the OPs problem that he has "US" in some fields in CFE, or is it just an AC66 problem?

I did upgrade the CFE from bl_version=1.0.1.3 to 1.0.1.9 just to enable cpu overclocking, but didn't deliberately change those vars
 
My UK RT-N66U with EU mode has always had 20/40MHz available in bands 100-140 -is the OPs problem that he has "US" in some fields in CFE, or is it just an AC66 problem?

I did upgrade the CFE from bl_version=1.0.1.3 to 1.0.1.9 just to enable cpu overclocking, but didn't deliberately change those vars

Tried various F/Ws over the last couple of days with factory reset and minimal setup, but am having connection issues with 5GHz with both 40 and 80MHz widths, so I'm thinking my AC66 has bit the dust, was about to invest in an 87u but am now waiting to see if the 3200 is or becomes available in the UK!
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top