Asus locking down routers to comply with new FCC rules

[S_D]

Which channels exactly do you mean when you say you have your "DFS channels"? Please elaborate.

Hello

To elaborate, I have these channels currently available:

36-64
100-116
132-140

Which is what I'd expect.

HTH

Simon

 

[jegesq]

Hello

To elaborate, I have these channels currently available:

36-64
100-116
132-140

Which is what I'd expect.

HTH

Simon

Thanks for the clarification.

I am sort of puzzled by the channels that are now exposed on your AC68. Here's why: Channels 100-116 give you 5 adjacent channels, and Channels 132-140 only give you three adjacent channels. You need 4 adjacent channels in order to get the most out of an 802.11 ac channel, i.e., to create a bonded 80mzh channel width. So 100-116 would allow you to create at least two different 80mhz channel combinations, but 132-140 gives you no chance at an 80mhz channel at all, and would only allow two different combinations of 40 MHz wide channels. So that's kind of weird. So I ask, are these the only channels in the mid and upper bands that are exposed on your router?

Assuming your channel listings above are correct, and assuming their use does implement the required DFS and TPC, please let us know how the use of those channels works for you and whether you experience any connectivity issues or performance issues.

Also, let us know if you're within 30 miles of a military base, civilian airport, or a weather radar station (if you can find out that info). Would be helpful to know if you do have any issues with using these channels in any sort of reliable way.

I'm a bit puzzled though by the "132-140" designation.


If you do use the channels at 100-116 or 132-140

 

[faria]

https://www.dropbox.com/s/xx41iifrlqg9rnv/default.png?dl=0

https://www.dropbox.com/s/0w6yu7munwb8fbt/unlocked.png?dl=0
Rtac87u
First image= default ccode EU
Second image= unlocked boot loader ccode #0

Aeroport= 6 miles
Weather tower= 1 mile.

 

[S_D]

Hello!

Thanks for the clarification.

I am sort of puzzled by the channels that are now exposed on your AC68. Here's why: Channels 100-116 give you 5 adjacent channels, and Channels 132-140 only give you three adjacent channels. You need 4 adjacent channels in order to get the most out of an 802.11 ac channel, i.e., to create a bonded 80mzh channel width. So 100-116 would allow you to create at least two different 80mhz channel combinations, but 132-140 gives you no chance at an 80mhz channel at all, and would only allow two different combinations of 40 MHz wide channels. So that's kind of weird. So I ask, are these the only channels in the mid and upper bands that are exposed on your router?

That is correct. I've just rechecked, and this are definitely the channels that are available. It's running the latest EU firmware (the absolute latest firmware is JP only so I haven't loaded that).

FWIW I've rechecked the **excellent** Wifi Nigel WhitePaper available here and it specifically mentions that channels 120-128 are oft removed from the UK due to weather radar. Although I find it interesting that my router doesn't know it's the UK, rather just the EU (the beacon received by my MacBook Pro shows DE as the country code)

Assuming your channel listings above are correct, and assuming their use does implement the required DFS and TPC, please let us know how the use of those channels works for you and whether you experience any connectivity issues or performance issues.

Well I've been running on channel 100 since setup. Again, it's recognised by my Mac as a DFS channel, and I get an 80MHz channel width and associated speeds reported. I'll try the higher channels later tonight, but FWIW at channel 100 my jperf tests show I'm getting the throughput that I should correctly at present. Also when I boot the AP it waits the 'minute' or so that it should be advertising the 5GHz channel (in comparison to the 2.4GHz channel which is available and connectable a lot quicker)

Also, let us know if you're within 30 miles of a military base, civilian airport, or a weather radar station (if you can find out that info). Would be helpful to know if you do have any issues with using these channels in any sort of reliable way.

I'm a bit puzzled though by the "132-140" designation.


If you do use the channels at 100-116 or 132-140

FWIW I'm in the Newbury area. Greenham is long since 'gone' (20 years ago!) Heathrow is over 30 miles away, and I can't think of anything else that would interfere. As far as availability goes I've noticed no 'interference' on my 5GHz connectivity, and the logs on the AC68U make no reference to having to 'shut' the radio due to interference....

I hope that answers your questions thus far?

Simon

 

[S_D]

Update

OK, I"ve tried running on each of channels 132, 136 and 140. Whilst 132 and 136 each gave me a 40MHz channel as expected, 140 just gave me a 20MHz channel (as in no channel bonding at all), which is odd, as I would've thought that the extension channel would be 136 or 132.

Anyway, HTH.

Simon

 

[jegesq]

Just a couple of comments and questions:

FWIW I've rechecked the **excellent** Wifi Nigel WhitePaper available here and it specifically mentions that channels 120-128 are oft removed from the UK due to weather radar. Although I find it interesting that my router doesn't know it's the UK, rather just the EU (the beacon received by my MacBook Pro shows DE as the country code)

There is no "UK" region, only EU. Remember, the UK is a member of the EU and Ofcom has agreed to be bound by ETSI's interpretations and implementation of the RT&T which governs all manufacturers in the EU. So your router does "know" where it is.....it's in the EU, and if radar bursts are detected, DFS will switch you to different channels and modulate your power (by turning off the channels that interfere with radar).

Well I've been running on channel 100 since setup. Again, it's recognised by my Mac as a DFS channel, and I get an 80MHz channel width and associated speeds reported. I'll try the higher channels later tonight, but FWIW at channel 100 my jperf tests show I'm getting the throughput that I should correctly at present. Also when I boot the AP it waits the 'minute' or so that it should be advertising the 5GHz channel (in comparison to the 2.4GHz channel which is available and connectable a lot quicker)

Not sure what you mean "it's recognised by my Mac as a DFS channel". I don't own a Mac, but are you saying that your's tells you in some way that a channel to which it is connecting has DFS and TPC activated and working? Also, the fact that you're able to se the channel after boot at all is probably because you're far enough away from any existing radar that you're not being switched off and to other channels by DFS/TPC. Consider yourself lucky.

 

[jegesq]

OK, I"ve tried running on each of channels 132, 136 and 140. Whilst 132 and 136 each gave me a 40MHz channel as expected, 140 just gave me a 20MHz channel (as in no channel bonding at all), which is odd, as I would've thought that the extension channel would be 136 or 132.

Anyway, HTH.

Simon

Not at all surprised that 132 and 136 bond to give you 40mhz width, but would have expected 136 and 140 to bond also at 40mhz. Obviously, it only works in one direction, so that if you choose 140, it won't bond in reverse.

 

[GoNz0]

Just a couple of comments and questions:



There is no "UK" region, only EU. Remember, the UK is a member of the EU and Ofcom has agreed to be bound by ETSI's interpretations and implementation of the RT&T which governs all manufacturers in the EU. So your router does "know" where it is.....it's in the EU, and if radar bursts are detected, DFS will switch you to different channels and modulate your power (by turning off the channels that interfere with radar).



Not sure what you mean "it's recognised by my Mac as a DFS channel". I don't own a Mac, but are you saying that your's tells you in some way that a channel to which it is connecting has DFS and TPC activated and working? Also, the fact that you're able to se the channel after boot at all is probably because you're far enough away from any existing radar that you're not being switched off and to other channels by DFS/TPC. Consider yourself lucky.

Fyi there is a UK region. Cisco list all applicable regions but Asus and most others remove the ability to set your own region and are only shipping EU and USA versions to save money http://www.cisco.com/en/US/products/ps6305/products_configuration_guide_chapter09186a00804ddd8a.html

 

[S_D]

Just a couple of comments and questions:

Not sure what you mean "it's recognised by my Mac as a DFS channel". I don't own a Mac, but are you saying that your's tells you in some way that a channel to which it is connecting has DFS and TPC activated and working? Also, the fact that you're able to se the channel after boot at all is probably because you're far enough away from any existing radar that you're not being switched off and to other channels by DFS/TPC. Consider yourself lucky.

That's exactly what I'm saying...: In my wireless info (for Mac users, hold 'alt' and click on the wireless icon):

HTH

Simon

 

[jegesq]

Fyi there is a UK region. Cisco list all applicable regions but Asus and most others remove the ability to set your own region and are only shipping EU and USA versions to save money http://www.cisco.com/en/US/products/ps6305/products_configuration_guide_chapter09186a00804ddd8a.html

Look, the ETSI rules recently enacted (mentioned elsewhere in this very long thread) require that any wireless router sold in the EU can no longer allow the end user to modify channels or power or change region coding. Period.

The fact that Cisco exposes more channels than does Asus or Netgear or other consumer-oriented wireless router manufacturers doesn't mean that Cisco is using a separate "UK" region coding. They aren't, and just because you happen to have a Cisco device that says "UK" in region coding doesn't mean that there is such a thing from a jurisdictional point of view. Just read through the thread....I'm not going to cite you chapter and verse again about the legal structure of ETSI and how it interacts with the various EU member nation's own regulatory bodies (such as Ofcom in the UK). We've been through all of that, and if you are interested, you'll just have to go back into this thread and read about it.

Cisco can call their "region coding" whatever they care to, the fact remains that it has to be compliant with EU regulations (not Ofcom's) in order for it to be sold anywhere in the EU (and that includes the UK). Cisco is just implementing DFS and TPC on those channels as they are required to do. And as S.D. points out in the last few post above, even Asus is now exposing more channels above 48 on the 5ghz band on routers sold in the UK, and are implementing DFS and TPC on those higher 5ghz channels above channel 48 as required. How that ultimately works out remains to be seen from the consumer's perspective.

But simply put, there's no such thing as a UK "region" from a regulatory, jurisdictional point of view when it comes to wireless router certification by ETSI, which is solely responsible for such certifications in the EU.

 

[GoNz0]

Stroppy bugger arnt you. Fact remains the router has such regions coded in and will change channel specs to reflect that if told to. I know all about Asus shipping a locked down router and why, I wasn't pointing that out but stating a fact about the UK having a region defined by Cisco that Asus also have coded in. OK?

 

[jegesq]

Stroppy bugger arnt you. Fact remains the router has such regions coded in and will change channel specs to reflect that if told to. I know all about Asus shipping a locked down router and why, I wasn't pointing that out but stating a fact about the UK having a region defined by Cisco that Asus also have coded in. OK?

Then I'm not sure I understand your point.

If it's that Cisco says it's a "UK region" and therefore a "UK region" code exists, that's just semantics. Cisco can call it whatever they want. It doesn't matter because whatever they call it it's still an EU region code only, and the same router, using a "Germany" region code would expose the same channels and provide exactly the same implementation of DFS and TPC as would a "French" region code or "Italy" region code. Fundamentally, under the RT&T regulations, there's no difference. And that is why I say there's really no such thing as "UK" code, because it is a meaningless term except to the extent you're flipping a setting in a router. Flip it to any EU country code and it will be the same (or it had better be under ETSI regulations).

Look, I'll take your word for it that your Cisco router has a code to set which exposes the channels that are permitted to be used everywhere in the EU, and not just in England, Ireland, Wales and Scotland (Scotland is still part of the UK?....JK) that Cisco calls "UK". Really, I'm not trying to be disagreeable, (or as you say "stroppy"....gawd I just love you Brits with words like "stroppy"). I'm only noting that there's actually no particular distinction attached to the term "UK region" notwithstanding Cisco's use of it in one of their router settings. It's really got to be the same as what in reality is an "EU" region. And while a router that is already on the market and sold prior to the latest regs restricting end-users from changing region coding or power settings may be "out in the wild" so to speak, there's no doubt in my mind that Cisco, just like every other router manufacturer out there, is no longer permitted to sell a router that can be configured to allow the end-user to change region codes or transmit power. You may therefore have such a router with that capability now, and you might be able to find one from existing stocks on hand to purchase, but Cisco isn't permitted to do that going forward.

On a more substantive note, since your Cisco does expose channels above 48 on the 5ghz band, can I inquire what your experience has been, if any, with using the upper band channels where DFS and TPC are required to be implemented? Have you experienced any of the negative impacts of DFS/TPC, such as delays in connecting, channels being switched, channels powered off when radar is detected?

I think everyone would be interested in that sort of info if you can provide it.

Thanks.

 

[GoNz0]

no delays, the kit we have installed in various retail outlets has no issues, logs show DFS detected and it will swap to a clear channel. Other than that I do not go into the general workings as I was the guy on a ladder fitting it and doing initial config + site survey.

 

[NGRhodes]

In terms of 80211 specs, country codes (I think the IEEE uses ISO/IEC 3166-1) identifies a regulatory domain which then has defined channel specs.

Multiple countries codes can point to a single regulatory domain.
For example both Canada and USA use the same North America (FCC) regulatory domain.

You can program channel specs directly against country codes (lazy way ?) or map channel specs to regulatory domains and then to country codes which avoids duplication; neither is right or wrong as long the eventual used channel specs are correct for the desired location (be it manual, preselected or automated).

 

[jegesq]

In terms of 80211 specs, country codes (I think the IEEE uses ISO/IEC 3166-1) identifies a regulatory domain which then has defined channel specs.

Multiple countries codes can point to a single regulatory domain.
For example both Canada and USA use the same North America (FCC) regulatory domain.

You can program channel specs directly against country codes (lazy way ?) or map channel specs to regulatory domains and then to country codes which avoids duplication; neither is right or wrong as long the eventual used channel specs are correct for the desired location (be it manual, preselected or automated).

Thanks for the info. And since you're mentioning country codes, this works both ways, i.e., not just from the wireless router/AP to the device, but also the other way, with the device transmitting back to the AP and deciding what region/country code it should be operating under.

Most devices sold prior to January 1, 2015 have relied on 802.11d to implement this in client-side devices. But that is no longer possible now for new devices sold after January 1, at least in the U.S. and Canada, because 802.11d use has been eliminated.

By way of background, 802.11d was an amendment to the 802.11 spec (approved in 2001) that allows a client device to automatically configure itself to the local regulatory domain. The wireless AP beacon transmits a region code, and 802.11d allows clients to select the proper region in which they operated automatically in order to achieve compliance with regional requirements as to what bands, channels and power to use.

The impetus behind the amendment in the first place was to make it easier for small countries that were not part of a larger domain (like North America or Europe) to allow clients in those other regions to configure themselves to use the correct operating bands/channels for that particular region or country. So 802.11d was often referred to as "world mode" or "world-wide" mode to distinguish it from North America, Europe or Japan.

But as of January 1, 2015, the FCC has ruled that the use of 802.11d in any devices sold after that date is not permitted. I believe from what I've also read about ETSI, that it has also followed suit (although I've not checked recently, the last RT&T decision that I read contained wording about not allowing end-users to change country codes or power that would suggest ETSI is imposing the same restrictions as well). Which is kind of odd, since the GUI picture that S.D. posted up-thread seemed to suggest that 802.11d+h was being enabled for use on those channels that were formerly not exposed by Asus (120, 124 and 128).

But in any event, if you're in North America, new client devices will no longer be able to look to the wireless AP to ensure automatic compliance, and won't "switch" depending on 802.11d beacon signals; instead, the device (and by this I mean client devices) will have to be locked to use only U.S. frequencies. Apparently, devices already out on store shelves or sold and in use (i.e., those that were certified by the FCC prior to January 1, 2015) are "grandfathered" in and can still be used, but after January 1, all new have to be preconfigured and hard-coded just to one regulatory domain.

I don't know if this applies to phones, but it certainly would apply to wireless laptop adapters, and I wonder what it will mean for international travelers who take their new locked-in laptops to Europe or Japan, or some other region where 802.11d would have automatically configured the adapter for use in that other region? The implications of this could be pretty far reaching, and clearly the trend is toward greater and greater regulatory control over how these frequency bands can be used in the future.

 

[DrTeeth]

Then I'm not sure I understand your point. <snip>

Have you seen the Cisco document that lists the different channels available for the different regions in the world*? There are some large differences between the number of channels available in different EU countries and power outputs too.

I would not mind a proper UK lockdown c.f. the four channels that are available under EU for the only reason that they are the only ones available in every EU country, i.e. they are the lowest common denominator.

Update:- Found it, uploaded to here http://g4dwv.co.uk/cisco/

Cheers

DrT

 

[bits]

Have you seen the Cisco document that lists the different channels available for the different regions in the world*? There are some large differences between the number of channels available in different EU countries and power outputs too.

I think we are again stuck in a loop.
The document you link appears extremely old, maybe over 10 years old.
There is no difference between EU countries, previously there may have been, but it is now clear all local laws are superseded by the EU definition.

 

[RMerlin]

28 pages later, and you guys are still debating about this?

<shakes head>

 

[Nullity]

Here is a link to the regulatory domain database that the Linux Kernel uses. The linked file should always be the latest version.

http://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/plain/db.txt?id=HEAD

 

[bits]

28 pages later, and you guys are still debating about this?

<shakes head>

How is your explaining of why "a manual reenter of settings is not the same as reloading a previous saved config file" going?