No need to be cryptic about it. Those who disable DFS, or use channels that do not have DFS implemented are the "boneheads". So are the manufacturers who have put devices out into the market that allow their devices be modified by end-users who can switch on and off DFS, or who can expose channels for use that require DFS but where their routers don't properly implement it, or who can change country codes/regions to defeat DFS (even if that it's the primary objective of the end-user).
Asus locking down routers to comply with new FCC rules
- Thread starter mromero
- Start date
No need to be cryptic about it. Those who disable DFS, or use channels that do not have DFS implemented are the "boneheads". So are the manufacturers who have put devices out into the market that allow their devices be modified by end-users who can switch on and off DFS, or who can expose channels for use that require DFS but where their routers don't properly implement it, or who can change country codes/regions to defeat DFS (even if that it's the primary objective of the end-user).
Whilst I find the people who decided to allocate a frequency range to home routers that wasnt even properly available "boneheads"
Do you own a radar station or something?
Have you been reading this thread? I mean from the beginning? Just the title of the thread alone should give you an idea of why I used the word "boneheads". If you've been paying attention from the start, then you'll appreciate that there is a significant number of folks who refuse to acknowledge that we all must share the frequencies we use. What else, other than "boneheaded" would you say about those who vociferously advocate that "nothing is illegal until you get caught"? Who see nothing wrong with boosting their wireless transmit power to ridiculous and unneeded levels so they can blast out their neighbors? Who suggest that this is perfectly acceptable behavior because they can do as they wish with "their" channels and that the "government" or manufacturers are engaged in some sort of conspiracy to deny them the right to do what they want in their homes (and who gratuitously throw in the occasional anti-Semitic or racist comments to emphasize just how boneheaded they truly are(see this one for example just as one example where you'll find this gem:
Chrysalis, I certainly don't put you in the same category as the bonehead who posted the quoted passage above. You've been a pretty reasonable person, albeit stubborn as hell, about your views of EU regulations, but at least you've been civil, engaged in the discussion in good faith, and in the end, acknowledged as you must, the legal and legislative framework that Ofcom and the EU work with and in which these issues of shared frequencies exist. But there are so many others who have posted in this and other similar threads who haven't and won't do so, and who are engaging in precisely the sorts of activities that Merlin has expressed such deep concern about, i.e., those things like unlocking regions to use channels that aren't even permitted (e.g., using Channel 14 in the U.S.), modifying bootloaders, changing country codes, boosting power to silly levels, etc.. These are the "boneheaded" things that are likely to result in manufacturers requiring signed keys for firmware, locked down devices that will spell the end of all third party firmware. Those are the boneheads I had in mind. I certainly can't speak about who DJJHawk had in mind when he titled his post in which he cited the two EU reports he linked to, but I know who I had in mind.
Chrysalis, I certainly don't put you in the same category as the bonehead who posted the quoted passage above. You've been a pretty reasonable person, albeit stubborn as hell, about your views of EU regulations, but at least you've been civil, engaged in the discussion in good faith, and in the end, acknowledged as you must, the legal and legislative framework that Ofcom and the EU work with and in which these issues of shared frequencies exist. But there are so many others who have posted in this and other similar threads who haven't and won't do so, and who are engaging in precisely the sorts of activities that Merlin has expressed such deep concern about, i.e., those things like unlocking regions to use channels that aren't even permitted (e.g., using Channel 14 in the U.S.), modifying bootloaders, changing country codes, boosting power to silly levels, etc.. These are the "boneheaded" things that are likely to result in manufacturers requiring signed keys for firmware, locked down devices that will spell the end of all third party firmware. Those are the boneheads I had in mind. I certainly can't speak about who DJJHawk had in mind when he titled his post in which he cited the two EU reports he linked to, but I know who I had in mind.
Last edited:
Ok yeah.
I will report back if ofcom reply with anything interesting.
What I proposed to ofcom was instead of having a pause when connecting on the radar frequencies, instead have the router check whilst the connection is active and then disconnect if a conflict is detected, and logging to the log of course so end user knows the reason why. Because in most areas not near a radar the current guidelines are complete overkill.
I will report back if ofcom reply with anything interesting.
What I proposed to ofcom was instead of having a pause when connecting on the radar frequencies, instead have the router check whilst the connection is active and then disconnect if a conflict is detected, and logging to the log of course so end user knows the reason why. Because in most areas not near a radar the current guidelines are complete overkill.
pirx73
Senior Member
I would also add enforcing 40MHz-wide channels on 2.4GHz band so they can get "more" at the expense of totally trashing 2.4GHz band for others.
If you live anywhere close to any other people who also use 2.4ghz, it's almost a guarantee that you'll almost never have a 40mhz channel width on 2.4ghz. That's just a fact of life with the coexistence and collision avoidance required to be used in routers as part of 802.11 in the ISM band.
You need to be using your channel when no one else is, in order to be able to use 40mhz on 2.4. You can always get 40mhz width on 5ghz, but the challenge is to consistently get 80mhz widths, particularly in the EU where, as we've been discussing, some manufacturers only expose a single set of frequencies that can be used for one such channel width.
You need to be using your channel when no one else is, in order to be able to use 40mhz on 2.4. You can always get 40mhz width on 5ghz, but the challenge is to consistently get 80mhz widths, particularly in the EU where, as we've been discussing, some manufacturers only expose a single set of frequencies that can be used for one such channel width.
Last edited:
I can setup 40mhz on the router no problem, likewise my old laptop can use that 40mhz no problem. But all modern devices I own will refuse to operate in 40mhz on 2.4ghz so I always leave my 2.4ghz in 20mhz mode now.
The sad thing is 20mhz is decent enough anyway if devices have 2x2 mimo, but so many manufacturers are cheap and only do 1x1 mimo.
In my area is 14 routers now on 5ghz, this is because isp supplied routers now enable 5ghz by default. Plenty of interference on the low 5ghz channels. They not using 80mhz wide channels tho, but 40, still the asus range on 5ghz only allows 2 non conflicting 40mhz channels.
The sad thing is 20mhz is decent enough anyway if devices have 2x2 mimo, but so many manufacturers are cheap and only do 1x1 mimo.
In my area is 14 routers now on 5ghz, this is because isp supplied routers now enable 5ghz by default. Plenty of interference on the low 5ghz channels. They not using 80mhz wide channels tho, but 40, still the asus range on 5ghz only allows 2 non conflicting 40mhz channels.
DFS
I think you may be confusing "user selectable" with "availability". The change Asus made to their firmware was to eliminate the user's ability to turn off DFS, as a result of EU & U.S. mandates. When DFS is turned on the user cannot manually select a channel from the DFS pool. If it were allowed, it would defeat the whole purpose of DFS as well as ruin DFS functionality for everyone else operating a RLAN in the area.
Asus routers sold in Europe support DFS on channels 52-64 and 100-140. However, a lot of clients only support DFS on channels 52-64. Often it is a matter of not only the hardware but the version of the driver for the client that determines its operating channel range. So it pays to make sure clients are loading the latest drivers.
The 4/20MHz or 2/40MHz channels (36-48) you are referring to are outside of the DFS channel pool. I would imagine these channels experience a lot of congestion. The same is probably true for 52-64 when choosing to use DFS due to the client side issues. It would pay to make sure any devices purchased from here on out are capable of operating on channels 100-140. Any new devices should conform to the new standards but I would still confirm regardless.
Eventually DFS will be locked down and people will begin realize DFS performs as well as manually selecting a single channel, that is if no one else in the area is violating the DFS compliance standards. I'm not sure there are a lot of people that really understand how DFS works. When it is disabled and a channel is selected that falls within the frequency bandwidth of a radar, the RLAN signal level can be as much as 30 dB above the radar receiver threshold. Even adjacent channel operations without DFS can impact the radar.
DFS not only provides dynamic channel selection but it also uses spreading codes much like spread spectrum technology. The energy of the RLAN's signal is spread across the noise floor of the RLAN and thereby reduced below the radar receiver threshold level when the RLAN is positioned in the first side-lobe of the radar antenna. This is the mechanism that allows the RLAN to sense the radar signal without disturbing the radar's receiver.
It also allows the RLAN time to switch channels before the main beam of the radar antenna is pointed directly at the RLAN. There are some detection issues with smaller pulse widths and the lack of consistency is what drove the extended RLAN timeout period (30-minutes). Once those issues are worked out and implemented, one would expect to see some relief in the timeout period. Dayum, NE kicked the Colts butt!
I think you may be confusing "user selectable" with "availability". The change Asus made to their firmware was to eliminate the user's ability to turn off DFS, as a result of EU & U.S. mandates. When DFS is turned on the user cannot manually select a channel from the DFS pool. If it were allowed, it would defeat the whole purpose of DFS as well as ruin DFS functionality for everyone else operating a RLAN in the area.
Asus routers sold in Europe support DFS on channels 52-64 and 100-140. However, a lot of clients only support DFS on channels 52-64. Often it is a matter of not only the hardware but the version of the driver for the client that determines its operating channel range. So it pays to make sure clients are loading the latest drivers.
The 4/20MHz or 2/40MHz channels (36-48) you are referring to are outside of the DFS channel pool. I would imagine these channels experience a lot of congestion. The same is probably true for 52-64 when choosing to use DFS due to the client side issues. It would pay to make sure any devices purchased from here on out are capable of operating on channels 100-140. Any new devices should conform to the new standards but I would still confirm regardless.
Eventually DFS will be locked down and people will begin realize DFS performs as well as manually selecting a single channel, that is if no one else in the area is violating the DFS compliance standards. I'm not sure there are a lot of people that really understand how DFS works. When it is disabled and a channel is selected that falls within the frequency bandwidth of a radar, the RLAN signal level can be as much as 30 dB above the radar receiver threshold. Even adjacent channel operations without DFS can impact the radar.
DFS not only provides dynamic channel selection but it also uses spreading codes much like spread spectrum technology. The energy of the RLAN's signal is spread across the noise floor of the RLAN and thereby reduced below the radar receiver threshold level when the RLAN is positioned in the first side-lobe of the radar antenna. This is the mechanism that allows the RLAN to sense the radar signal without disturbing the radar's receiver.
It also allows the RLAN time to switch channels before the main beam of the radar antenna is pointed directly at the RLAN. There are some detection issues with smaller pulse widths and the lack of consistency is what drove the extended RLAN timeout period (30-minutes). Once those issues are worked out and implemented, one would expect to see some relief in the timeout period. Dayum, NE kicked the Colts butt!
Last edited:
I read here and there and I couldn't find an answer to this. Are EU routers affected by the same new power cap as US routers? Is there any difference between the two?
Thanks.
D
Deleted member 22229
Guest
As far as i know Asus has locked all routers no matter were you live down to 80mw max output.
Hey! You seem to know a lot about this so you're probably the right person to ask.
I bought an R7000 last week but may send it back as one or two things are annoying me. The question is, if I were to buy an Asus Router (say 68U) tomorrow, and updated to the latest official (or Merlin - I understand it should be the same in this regard) firmware (I'm in the UK so would select 'EU'), would I get the DFS channels selectable or not? The 80mW thing is fine for me - I realise the sums that means that's the 200mW limit broadcasting in the EU...
But would I get the channels from say 100 upwards?
TIA!
Simon
Unfortunately you might find the ASUS and the Nighthawk might be similar.
I've read that manufacturers can have a few approaches to the FCC DFS issue. They can make the DFS channels or those near them unselectable in the GUI.
Even if the channels are or are not selectable, the FCC (and I assume the same in the EU FCC equivalent) still require the routers to implement some type of interference processing and shut down channels that it detects as interfering with 'nearby' DFS channels.
On my router I could select 149, but my router detected nearby interference and shut it off. I could not select 149 at 20 or 40mhz without shutoff, or any of the higher channels at 80mhz.
I posted my experience in MY geographic location in another thread.
http://forums.smallnetbuilder.com/showthread.php?t=7742&page=8
There is also a long discussion on DFS I think in an all regions, all channels thread...
I've read that manufacturers can have a few approaches to the FCC DFS issue. They can make the DFS channels or those near them unselectable in the GUI.
Even if the channels are or are not selectable, the FCC (and I assume the same in the EU FCC equivalent) still require the routers to implement some type of interference processing and shut down channels that it detects as interfering with 'nearby' DFS channels.
On my router I could select 149, but my router detected nearby interference and shut it off. I could not select 149 at 20 or 40mhz without shutoff, or any of the higher channels at 80mhz.
I posted my experience in MY geographic location in another thread.
http://forums.smallnetbuilder.com/showthread.php?t=7742&page=8
There is also a long discussion on DFS I think in an all regions, all channels thread...
Last edited:
Man, this is the thread that refuses to die.....
In answer to SD's question to djjhawk, I'm going to chime in here with my two cents:
Older versions of Asus stock firmware coded for the EU will only expose channels 32-46 in the 5ghz band. So no, you wouldn't be able to see any of the channels in the mid to upper frequencies in the 5ghz band that require implementation of DFS and TPC in the EU. That is what a lot of the EU folks here were complaining about, i.e., that they could only see 4 channels on the 5ghz band, and they were complaining that Asus was locking them out of the other channels which they all argued could be legally used in their countries. But the issue then was whether or not DFS and TPC were actually being implemented in the higher channels on those routers.
And with all due respect to djjhawk, who has a deep knowledge and background in the area of how DFS and TPC were developed and why in the EU within ETSI, when he says that all Asus routers "support DFS and TPC" on those higher channels, I am not certain that is a completely correct statement.
I have seen a newer version of Asus firmware designed I believe for the 87U that appear to have a setting that allows other 5ghz channels to be displayed and which also provides a setting to enable DFS and TPC as is required by ETSI. But I'm not certain and I could be mistaking that version of firmware for the AC3200 simulator version that Asus has up and running on the web (and which is loaded on the AC3200), and if that's the case, it wouldn't be available anyway in the EU for a good long while.
So at the moment, I'm not actually aware of any Asus or Merlin FW that allows you to expose any more than the 4 channels at the lower end of the 5ghz frequency spectrum.
To answer Ken's questions/statements, in the EU, ETSI (which is the functional equivalent of the FCC in the EU) requires that routers cannot be modified by the end-user to either change region/country codes nor can they allow the end user to modify transmit power beyond what the manufacturer has enabled as a maximum. So what this means for all Asus routers that are currently sold in the EU is, again, only channels 32-46 are available to end-users because those channels do not require implementation of DFS and TPC.
The reasons why Asus routers, even if capable of implementing DFS and TPC do not has been the subject of a lot of discussion in this and other threads, but the bottom line is that it costs money for a router manufacturer to get its device certified, and DFS and TPC present so many issues, including the issue that customer's routers will be disabled for a minimum of 30 minutes and possibly as long as a day when radar bursts are detected, that the manufacturers like Asus have decided simply to not make those other channels available to end users. So Asus sort of accomplishes two goals: They spend a lot less to have their routers certified for sale in the EU, and they avoid consumer complaints about the routers "not working" (when in fact DFS and TPC, if working correctly are what disables the channels), so they avoid all the consumer complaint headaches.
With all due respect Ken, your issue which we discussed at length, is really a little different than what these folks in the EU countries are experiencing. The real issue they face is that with only four 5ghz frequencies available (32-46), it means they really only have a single channel at 80mhz width, and if there's any adjacent interference from another user who also has his or her router set to 80mhz channel width, no one will get the full benefit of an 802.11ac channel speed and throughput, because everything will drop down to 40mhz channels (or 20mhz). And it also means that unless there's some other solution besides DFS and TPC (which as we all know actually disables the wireless router's use of channels for a minimum of 30 minutes when radar is detected), when 160mhz channel width devices become available, the EU is going to be out of luck, because they won't have the necessary number of channels to even get to 160mhz. We in the U.S. at least have 15 channels avaialbe in the upper 5ghz frequencies that we'll be able to work with to bond 8 channels for super fast 11ac speeds.
I'd love to hear from djjhawk on these questions as well, so hopefully he'll stop back in here and drop some wisdom on us all again.
In answer to SD's question to djjhawk, I'm going to chime in here with my two cents:
Older versions of Asus stock firmware coded for the EU will only expose channels 32-46 in the 5ghz band. So no, you wouldn't be able to see any of the channels in the mid to upper frequencies in the 5ghz band that require implementation of DFS and TPC in the EU. That is what a lot of the EU folks here were complaining about, i.e., that they could only see 4 channels on the 5ghz band, and they were complaining that Asus was locking them out of the other channels which they all argued could be legally used in their countries. But the issue then was whether or not DFS and TPC were actually being implemented in the higher channels on those routers.
And with all due respect to djjhawk, who has a deep knowledge and background in the area of how DFS and TPC were developed and why in the EU within ETSI, when he says that all Asus routers "support DFS and TPC" on those higher channels, I am not certain that is a completely correct statement.
I have seen a newer version of Asus firmware designed I believe for the 87U that appear to have a setting that allows other 5ghz channels to be displayed and which also provides a setting to enable DFS and TPC as is required by ETSI. But I'm not certain and I could be mistaking that version of firmware for the AC3200 simulator version that Asus has up and running on the web (and which is loaded on the AC3200), and if that's the case, it wouldn't be available anyway in the EU for a good long while.
So at the moment, I'm not actually aware of any Asus or Merlin FW that allows you to expose any more than the 4 channels at the lower end of the 5ghz frequency spectrum.
To answer Ken's questions/statements, in the EU, ETSI (which is the functional equivalent of the FCC in the EU) requires that routers cannot be modified by the end-user to either change region/country codes nor can they allow the end user to modify transmit power beyond what the manufacturer has enabled as a maximum. So what this means for all Asus routers that are currently sold in the EU is, again, only channels 32-46 are available to end-users because those channels do not require implementation of DFS and TPC.
The reasons why Asus routers, even if capable of implementing DFS and TPC do not has been the subject of a lot of discussion in this and other threads, but the bottom line is that it costs money for a router manufacturer to get its device certified, and DFS and TPC present so many issues, including the issue that customer's routers will be disabled for a minimum of 30 minutes and possibly as long as a day when radar bursts are detected, that the manufacturers like Asus have decided simply to not make those other channels available to end users. So Asus sort of accomplishes two goals: They spend a lot less to have their routers certified for sale in the EU, and they avoid consumer complaints about the routers "not working" (when in fact DFS and TPC, if working correctly are what disables the channels), so they avoid all the consumer complaint headaches.
With all due respect Ken, your issue which we discussed at length, is really a little different than what these folks in the EU countries are experiencing. The real issue they face is that with only four 5ghz frequencies available (32-46), it means they really only have a single channel at 80mhz width, and if there's any adjacent interference from another user who also has his or her router set to 80mhz channel width, no one will get the full benefit of an 802.11ac channel speed and throughput, because everything will drop down to 40mhz channels (or 20mhz). And it also means that unless there's some other solution besides DFS and TPC (which as we all know actually disables the wireless router's use of channels for a minimum of 30 minutes when radar is detected), when 160mhz channel width devices become available, the EU is going to be out of luck, because they won't have the necessary number of channels to even get to 160mhz. We in the U.S. at least have 15 channels avaialbe in the upper 5ghz frequencies that we'll be able to work with to bond 8 channels for super fast 11ac speeds.
I'd love to hear from djjhawk on these questions as well, so hopefully he'll stop back in here and drop some wisdom on us all again.
Last edited:
Thanks to the kind folks who've replied so far.
For what its worth I spoke with Netgear support who tell me that they have no date or timeline for when DFS channels are coming to the r7000 in the EU, if at all. I realise they were available in a beta firmware mentioned on their forums, and also in the Japan regulatory domain in the firmware, but I just want to remain legal and 'original'. For what its worth I have tested extensively and do seem to get a lot higher speeds on channel 100 on dd-wrt than on 36, when tested using iperf on a 3x3 client through a couple of brick wallz, which is odd as the power limits for 36 and 100 are the same... (200mw)
I await with interest other user's experiences of dfs in the EU with official and merlin firmware. (Not interested in modding CFE myself)
TIA
Simon
For what its worth I spoke with Netgear support who tell me that they have no date or timeline for when DFS channels are coming to the r7000 in the EU, if at all. I realise they were available in a beta firmware mentioned on their forums, and also in the Japan regulatory domain in the firmware, but I just want to remain legal and 'original'. For what its worth I have tested extensively and do seem to get a lot higher speeds on channel 100 on dd-wrt than on 36, when tested using iperf on a 3x3 client through a couple of brick wallz, which is odd as the power limits for 36 and 100 are the same... (200mw)
I await with interest other user's experiences of dfs in the EU with official and merlin firmware. (Not interested in modding CFE myself)
TIA
Simon
http://en.wikipedia.org/wiki/List_of_WLAN_channels#5.C2.A0GHz_.28802.11a.2Fh.2Fj.2Fn.2Fac.29.5B17.5D
But this affects also lower channels, at least in EU RT-N66U. I know, because my laptops wifi card (Intel) don't like 802.11d+h, drops it and 5GHz wlan disappears, no matter if I use lower or higher channels. With #a region it defaults off and I don't have problems.
Channels 36-48 in the EU do not require DFS and TPC, and radar bursts should not effect them, and this is why those are the channels commonly exposed by router manufacturers in their EU region-coded routers.
What your Intel wifi card "prefers" is to connect without having to deal with detecting or scanning for radar bursts, which is why you definitely do NOT want to have it's properties set to use "802.11d+h" mode. If you do, it will, quite independently of anything your router is doing, scan periodically for radar bursts and if they are detected, it will cause issues that you will perceive as connectivity problems.
But that's beside the issue of what settings an EU region-coded router should use that only has channels 36-48 available on the 5ghz band.
802.11d is an "add-on" mode to 802.11 which itself enables TPC, which in turn is required for 802.11h, which implements DFS. Hence "802.11d+h".
As was made clear from other posts in this thread, the only frequencies that require using DFS/TPC in the EU are those operating in the 5250 – 5350 MHz and 5470 – 5725 MHz bands. These are channels 52-64, and channels 100-140.
I'd suggest you take another look at this article (or read it for the first time if you've missed the rest of this thread): Dynamic Frequency Selection and the 5ghz Unlicensed Frequency Band. The article explains pretty simply and clearly so anyone can understand how DFS and TPC are implemented in the EU and which channels are affected. Which is why I asked the poster SD to let us know which channels he was referring to when he said that his new router showed the "DFS channels."
Your laptop's wireless adapter should definitely NOT have 802.11d+h set to be implemented if you're not using channels other than 36-48 in the EU; if it does have 802.11d+h set, the adapter will be continually and periodically scanning to detect radar bursts on channels you aren't using, and when it does detect radar, this can result in disconnects and other issues even if you're not using those DFS/TPC channels. So don't use it unless you must, and then only if you're using those specific channels on which DFS and TPC are required for your region.
Similar threads
Similar threads
Similar threads
-
So sorry if this has been asked before but is this how you revert back to asus stock firmware?
- Started by Thelastone
- Replies: 5
-
-
-
ASUS VPN Fusion Wireguard client not setting up route(s) on connection
- Started by SonoranWoody
- Replies: 1
-
-
BIG issue with ASUS routers killing network with upload flood
- Started by Armand28
- Replies: 11
-
-
-
-
Latest threads
-
-
ASUS RT-AC86U Firmware version 3.0.0.4.386_51955 (2024/11/08)
- Started by lepicane
- Replies: 0
-
iPhone 16 Pro w/ GT-Be98 Pro & BQ16
- Started by Jadehsn
- Replies: 0
-
-
Release ASUS ZenWiFi Pro ET12 Firmware version 3.0.0.4.З88_24610 (2024/11/08)- Started by rudoyeugene
- Replies: 0
Support SNBForums w/ Amazon
If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!