Asus RT-AC66U issues connecting to 5 ghz band

[ChuckT]

I have _not_ updated the firmware on my AC66U and have not have a problem with the 5 gHz.

 

[WarpNine]

5G SSID now visable after newer firmware!

Upgrade to the latest firmware.

http://www.asus.com/ca-en/Networking/RTAC66U/HelpDesk_Download/

Thanks!

Since I uploaded new firmware a couple of weeks ago, some new firmware was out on the web site (that the "check" button in the router's GUI wasn't reporting - it insisted that I already had the latest version, so I guess I can't rely on it in the future) and it seems to fix the problem! At least I can now see the RT-AC66U's 5G SSID showing up in my external devices for the first time! I'll do more extensive testing with the 5G band and the Nvidia Shield tonight - after my son goes to bed - but it sure seems to be working for the first time!

Thanks so much for your help!

 

[L&LD]

Glad that it fixed the issue, at least superficially for now. Looking forward for your confirmation that it is fixed for good.

 

[ChuckT]

All of the discussions I see here that discuss firmware updates are making me hesitate to mess ... I mean install, a newer firmware!

 

[kmedeiros]

Spent some time today trying to further characterize the issue. I had always had the Bandwidth in 20/40/80Mhz, paying no attention to it until jeg, you mentioned your 5G setting stable at 80Mhz, which prompted me to try some things.

Here is what I found today.



Interesting that for the suspect channels (149, 153, 157, 161), that any setting above 20Mhz is unstable and turn on and off aperiodically, usually seconds at the 20/40/80 and 80 setting, and maybe up to a minute for the 40Mhz setting on those channels.

(Along with the 2.4G channels, the lower 5G channels and 165 were stable at any Bandwidth setting, although you cannot select 40Mhz or 80Mhz for channel 165)

No idea of this architecture but maybe a freq or clock multiplier or something?

Strange pattern. Probably a no-brainer for an ASUS engineer armed with the evidence, but I'm not smart enough to know firmware/nvram or an actual hardware issue.

Interested in any other thoughts, observations, experiences or tests...

I have this same exact pattern on my router from day one. Here's the thing..I have 2 other routers for testing that do NOT exhibit this behavior on those channels. This guy has an issue and I'm not sure most people even notice it. Unless we just have 2 routers with the same exact issue? :\

I also noticed that we both have the R version of the router, which makes me think maybe the others that do not have issues have the U version?

 

[kenhlan]

I'm convinced its DFS radar detection processing

Well after experiencing this, had a few things happen, including some reading and lights coming on. First I exchanged for a replacement AC66R router, and then a new AC68U The replacement Refurbished AC66R router AND the brand new AC68U router I purchased ALL did the same thing. Those odds were too much to ignore.

Well, after reading a bit, I am convinced that our routers are not broken, but are implementing some type of DFS radar interference processing.

Read here:
http://www.networkcomputing.com/wir...on-part-3-the-channel-dilemma/a/d-id/1234489?

http://www.extremenetworks.com/understanding-fccetsi-dfs-regulations-for-802-11ac-deployments

I believe our routers are switching off when they detect a radar interference in the nearby DFS frequency bands. In order to comply with the FCC certification, they need to include DFS processing. I think they are doing the radar/RF detection processing part of it and shutting down interference, but I have not seen any evidence of automatic channel reassignment, only a time out period. This is especially applicable to the channels closest (149, 153, 157 and 151) to the DFS channels/nearest the weather radar freqs, and not the lower channels, or 165, and especially when wider bandwith/channel coupling (40Mhz or 80Mhz) is selected.

The FCC is hot on aircraft safety related to TDWR radars, and are regulating wireless vendors to include DFS processing in the UNII frequency ranges.

I live near a municipal airport, a military/Naval Base, boat harbor, range tracking sensors, and am about 16 miles from Weather radar, and I am not sure which one might causing the detection (don't think it's the type (NEXGEN) of weather radar near me), but I'm pretty positive some type of required detection processing and response is what it is.

I am currently planning to run in any of the stable configurations I listed in the above graph. I'm pretty sure some type of DFS processing is the smoking gun. Would be nice if ASUS would have included some type of statement in the manual or something...

At least I know how to work around it. (until the FCC releases even more higher 5G UNII-3 channels they are discussing, which in theory will give more/higher channels to space between the DFS detection/interference regulated freqs.

http://blogs.cisco.com/wireless/winning-back-the-weather-radio-channels-adds-capacity-to-5ghz-wi-fi-spectrum

Expanding Keywords:
RT-AC66u,
can't connect to 5ghz,
no 5ghz signal,
5ghz issues
5g not visible
5g hidden
5ghz network not seen
5G Drop
5G periodic drop
5G dropping connection
5G can't connect
disappearing 5G
5G stability
5G instability
DFS
Radar Detection

 

[jegesq]

If your theory is correct, you should get the same results on the 5ghz spectrum regardless of the wireless AC router you select, since DFS is an issue for all AC routers and will affect those channels on which DFS is a requirement. In other words, it's not just your AC66U, but this same patter would occur on any AC router, of any brand.

The fairly obvious solution, at least to me, is to use the channels that are not within the most common type of DFS, i.e., to avoid channels 116 and 132 which are used for Doppler radar, and instead use only 36-48 in the lower Uni-1 band, where at least you can get enough contiguous channels for bonding to 80mhz width, or use only channels above 144, is the upper end channel for Uni-2 extended. So, for example, use channel 161 and set it to 80mhz width and see what happens (set adjacent to "auto").

It could be that I live sufficiently far from the nearest airports, but probably not far enough away that it would matter since Doppler radar has a 21 mile range. But who knows...I can say I don't experience my 5ghz shutting off randomly.

And to kmedeiros, there is absolutely zero difference between the "R" and "U" versions. None. Nada.

 

[kenhlan]

That's the fun part. I had observed the shutoff on two AC66's and my current brand new AC68U.

What the other routers may be doing, and the DFS processing allows for, is for the router to notify clients and actively switch channels.

I have not observed the ASUS actually and actively notify and switch channels. (Edit - I should clarify this statement since I have not successfully connected up a client to specifically observe/test this notify and channel change function. What I have observed using the inSSIDer/WiFi analyzer type tools is the drop off and return to the same channel and drop off again, no clients connected)

Here's the other interesting part is while there are no channel selections available within the affected DFS restricted channels, the interference processing still applies. So the first available (and default) selectable upper channel is 149.

I believe the spec calls for active interference processing if detected interference is within 30Mhz of the restricted freq.

Although 20Mhz bandwidth setting seems to me stable from 149 up, I selected 161 (at 20Mhz) for more spacing. (Btw, looks like 165 is a separate animal in the IMI band, so DFS may not apply to it, which is why it seems more 'stable'...)

What I have not tried is a further refined test at 161 at 40Mhz bandwith, which in theory pairs it with 157, if still far enough from the restricted DFS spill over, and maybe update my chart with the refined results, maybe light green/marginal, if that is the result.

 

[jegesq]

Whoaaa...You say:

"I have not observed the ASUS actually and actively notify and switch channels. (Edit - I should clarify this statement since I have not successfully connected up a client to specifically observe/test this notify and channel change function. What I have observed using the inSSIDer/WiFi analyzer type tools is the drop off and return to the same channel and drop off again, no clients connected)."

Has all of this strum und drang and general gnashing of teeth been only about signal levels that are observed to fluctuate or drop on InSSIDer or some wifi analyzer app?

Do I correctly understand from the passage above that you have not connected a client to test this that you have never actually experienced when using a connected device that it drops off during these signal fluctuations? That it loses connection? That you've not experienced any suttering or lag when streaming video, because you've never connected a client to test this theory out?

Really? Really?

Perhaps you ought to try connecting a client device to the router first and do some actual, real-life throughput testing and some high bit-rate streaming of video or some gaming in order to actually determine whether the measured signal fluctuations are going to really represent something that actually needs to be dealt with in the real world, or whether you're just dealing with something that, although measureable, has no practical implications and remains only theoretical.

Can you try to connect a device and stream or file transfer and then get back to us with information about whether your streaming and file transfers drop, lag, or are interrupted. Ok?

 

[jegesq]

BTW, on US coded routers, the only channels that you should be able to connect to in the IMI-Upper2 area are 149, 153, 157 and 161. While the band technically supports more channels, these are, if my understanding is correct, the only ones that are coded into routers sold in the U.S.

 

[kenhlan]

I hesitated to post that because it could be read like you interpreted.

So let me clarify. My wife's 5G smart phone would not connect, none of my kids iPads would connect. SSID would appear in the client list to select, then would disappear.

I tried the regulation mode d, h, d+h would not connect.

THEN I went to inSSIDer, and WiFi Analyzer type apps to SEE what was going on.

What I saw was all 2.4G channels/signals up/on and stable. I went to the 5G channels and the signals SHUT OFF (not fluctuate, not drop low) and then would reappear.

Your earlier post led me to look at not only the channels but also the bandwidth settings/combinations.

After some tests, the table posted is what I observed. Channels 149 (default), 153, 157, and 161 all shutting OFF at any Bandwidth above 20Mhz. NOT 36, 40, 44, 48, or 56, nor 165.

So when I say not testing with a client connected, that would be to characterize if any auto channel switching occurs during the shut off.

I have NO doubt they are shutting off, just need to confirm if the second part (new channel notification and switching) occurs with a client.

In theory the test would go something like: set channel 149 to 20MHz, connect a client, change the BW to something higher. If the client can reconnect at the higher B/W, wait for a shut off event. Monitor if the client reconnects after the shutoff event and observe which channel it reconnects on. If it immediately reconnects to another channel, autoswitching function confirmed. If it does not immediately reconnect, and there is a delay until the existing channel returns, then we have a interrupted/unstable/data delay situation.

The shut off is real (3 different routers), just have not tested/observed/confirmed auto channel change/reconnect.

At least I know the why, and how to adapt to it, now need to characterize user impacts (beyond unable to connect).

 

[wouterv]

The real future of fast wireless networks connections lies beyond the use of 5 GHz. 802.11AC (up to 160 MHz bandwidth with the full blown theorethical specification) suffers with the issues around DFS, making it very complex and unreliable.
Developments are focussing on new frequency bands, exclusively for fast wireless networks. Don't be disappointed, faster wireless networks come with shorter ranges. We must avoid boiling brains ;-)
The real fast thing still comes with a piece of glass (fibre optic).

 

[jegesq]

Kenhlan:

I realize you may have posted this elsewhere, and if so, I apologize, but may I inquire which firmware version your router is currently using? And just to be clear, you are using an RT-AC66U? or is it now an AC68U? I see your signature line, but is that still the current your/FW that you are using?

 

[kenhlan]

More DFS processing characterization

wrouterv - Agree. knowing what I know now. The N type spec is tried and true. The AC and its ONLY use of 5G, and reliance on wide Bandwidths to achieve its stated speeds are not quite flushed out yet, IMO, likely by the FCCs impact on OEM implementation. That said what I'm reading about the recent FCC changes (more 5G upper channels, more power on the lower channels offers some step forward.) One reason I went with AC is because of what could be, so no regrets, especially now that I know its limits, and can govern accordingly

jegs - I do thank you for the engagement here. So to be clear I originally had an A66R (refurbished) where I originally observed the phenomenon. Convinced it was the router, I sent it back, and received another AC66R (refurbished). Saw the same phenomenon. I sent it back, for exchange. Thinking pure bad luck, I went ahead (with the wife's permission) and purchased a brand new AC68U.

So to summarize observations:
AC66 - Qty 2
AC68 - Qty 1

Firmware versions tried (off my head, because my notes are everywhere):
First AC66 -
- came with older 374 series OEM
- flashed Merlin Fork -06
- flashed Merlin 374 series
- flashed latest Merlin 376
- flashed latest OEM 376
- seeing no changes, went back to Merlin Fork -06, before I finally reflashed it to the latest 376 OEM I returned it back with for exchange.

Second AC66
- came with older 374 series OEM (5517??)
- flashed with Merlin Fork -6
- flashed with latest 376 OEM
- returned it, they exchanged another.

Brand New AC68
- Came with 374 series OEM (4561??)
- Currently flashed and running with Merlin Fork -06

Cleared NVRAM via ssh/telnet, or WPS hold/power button as applicable each time.

Verified country codes (US) and TxPower, just to see.

Phenomenon observed with each f/w version.

Currently have the brand new AC68, and the last exchanged AC66 in my possession.

BTW - My latest test last night with a couple of clients Samsung GS3 and iPad. I did not see any channel switching once connected and when the signal shut off. They just lost signal. No connection. They reconnected if the same channel later came back, but the router never immediately came up on an alternate channel. What I did find interesting is that when I set it to Auto, it switched to 165. That is interesting because 149 is the typical default, and I think I recall for the spec to allow for the device to log interference channels. Maybe it 'learned' 149 had interference before (on anything above 20Mhz b/w) and did not auto-assign it?

The other thing I wanted to reconfirm for myself (and in theory) is if there was any 'better' characterization in wider bandwidth settings on the upper channels. As expected (since they are further away from the restricted DFS freq/channels), there indeed was some level of stability/continuity in 40MHz bandwidth (only) between 157 and 161 channel pairs. As noted before and reconfirmed last night, there is no continuity for me in my location on any of the upper channels set to 80Mhz (or 20/40/80), which was expected since 80Mhz bonds all four channels, including 149 nearest the regulated freqs. I probably need to update my char with the latest characterization: 40Mhz at 157 or 161 fairly stable.

 

[kenhlan]

Latest characterizations of *my channel stability*

*applicable to MY location, US, near a municipal airport, Naval Bases, Local Harbor and, nearby Range Control sensors. (not sure which one, might cause the what I believe is DFS interference processing)



another view I edited with green the legends trapezoids.



Interesting (ACI) Adjacent Channel Interference diagram I ran across. Shows relative ACI area/levels of 20Mhz, 40Mhz, and 80Mhz bandwidth spreads.

 

[jegesq]

Ken:

Remind me please: If you are able to get clear tx/rx using the lower Uni band channels 36, 40, 44 and 48, but can't get decent or stable connections (as we've discussed) on the upper band channels (149, 153, 157 and 161) due to DFS, then clearly the choice is that you must use the lower channels. Right?

Also, I'm not sure how the ACI graph depicts your particular issue. It simply appears that ACI in the 80mzh channels is double that of 40mhz, which makes sense, but how would it pertain to the DFS issue that you think is affecting your upper-band channels? Can you explain further?

 

[kenhlan]

Ken:

Remind me please: If you are able to get clear tx/rx using the lower Uni band channels 36, 40, 44 and 48, but can't get decent or stable connections (as we've discussed) on the upper band channels (149, 153, 157 and 161) due to DFS, then clearly the choice is that you must use the lower channels. Right?

Not entirely correct. Forgive me, I though my table above and the channel chart I annotated, just below it, were pretty clear that anything I've shown in GREEN is usable.

That would be:
20Mhz Bandwidth on ALL Channels, lower and upper (UN-3), and 165 ISM
40Mhz Bandwidth on all the lower channels, and only 157/161 bonded on the upper
80Mhz on the lower channels only.

I can do a channel by channel text listing if that would be more helpful.

Also, I'm not sure how the ACI graph depicts your particular issue. It simply appears that ACI in the 80mzh channels is double that of 40mhz, which makes sense, but how would it pertain to the DFS issue that you think is affecting your upper-band channels? Can you explain further?

ACI is adjacent Channel interference (the grey area extension shown on the graph), kind of a frequency side lobe effect off the main channels, is my interpretation. I'm theorizing that the sidelobe/ACI effects from the 40Mhz setting on 149/151, and the 80Mhz setting (149,151,157,161) is extending to interfere with other local radar UN-2e signals around my area and the router is instituting mandatory FCC requirement to manage the use of channels in the 5.470–5.725 GHz band to avoid interference with Terminal Doppler Weather Radar (TDWR), and other defined military or critical systems in the UN-2e bands.

 

[jegesq]

Ken, just out of curiosity, what is the transmit power on your 5ghz radio set to on your AC68U? The reason I ask is that with the 374.xx firmware (you say you are running the fork, so that's it's a variant of 374.xx), you should be able to adjust your transmit power above the "default" of 100mw, and clearly you can adjust it downward below that as well. Have you tried dropping it down to say 80mw or 60mw to see if that changes the situation you're experiencing on the Uni-II upper channels? It might be worth a try.

The reason I suggest this is that I just reviewed the FCC's booklet on the DFS regs that were first issued in 2004 (a PDF at this link), and they state that "For devices that operate with less than 200 mW e.i.r.p. the minimum detection threshold is -62 dBm." Thus, perhaps if you dropped your power to something well below the threshold (and presumably you're already under 200 mW anyway) this might help you avoid radar detection on an overlapping channel and thus avoid DFS from kicking in. Again, might be worth a try.

 

[jegesq]

Geez, the more I read about DFS and Radar, the less clear this becomes. Apparently, there are differences between how DFS works in a device coded for U.S. vs. one coded for EU. This is apparently because in the EU, Dynamic Frequency Selection (DFS) was first implemented to define a set of procedures to detect and avoid interference with Radar systems operating in UNII channels – 52-64 & 100-140 (which are used only in the EU) because there, radar clearly overlaps with those channels that are authorized for use in an EU router's 5Ghz band.

But in the U.S., different radar is employed: The U.S. uses both short and long sequence radar (which is similar to what is found in Europe) but also uses "Simulated Frequency Hopping Radar" which hops over the entire frequency range of 5250 – 5724 MHz (i.e., all 475 channels); this kind of radar hops across 475 channels in a random manner without using the same channel twice, and it does so using 100 channels per hop. So depending on where the hops are occurring, it could theoretically hit overlap with channels 48 and 149 perhaps. I just can't tell from the limited amount of research I've done (and what I am able to understand of it).

The more interesting thing is what happens when Radar is detected, i.e., what a device licensed for use in the U.S. with DFS is supposed to do and how it behaves. According to an article I found at Extreme Networking:

"...DFS requirements are complex and costly to get regulatory certification from FCC/ETSI. Following are the typical requirements for access points (AP) operating on 5GHz DFS channel:

1.Before starting operation on DFS channel, scan the channel for Radar devices for 1 minute. If radar is detected follow step 4 otherwise start operation of DFS channel.

2.Must detect non-Wi-Fi Radar devices with pulse width as small as 5us

3.When radar device are detected stop operation on the channel within 500 milliseconds. ---For AP vendors, this also means informing wireless clients to move away from this channel.

4.Do not become operational of this DFS channel for at least 30 minutes and after that go to step 1 before becoming operational again."

So, it's a circular process. Once radar is detected, the device has to shift away from the channel, and it won't become operational again for at least 30 minutes. It's not "learned" in the sense that it will always block that particular channel, but if it goes back to Step 1 and again detects radar interference, it shuts down and is supposed to switch to the nearest non-interfering channel.

Anyway, maybe Ken is on to why this is occurring in his environment with all of his AC-capable 5ghz routers. Could be.

 

[kenhlan]

The more interesting thing is what happens when Radar is detected, i.e., what a device licensed for use in the U.S. with DFS is supposed to do and how it behaves. According to an article I found at Extreme Networking:


So, it's a circular process. Once radar is detected, the device has to shift away from the channel, and it won't become operational again for at least 30 minutes. It's not "learned" in the sense that it will always block that particular channel, but if it goes back to Step 1 and again detects radar interference, it shuts down and is supposed to switch to the nearest non-interfering channel.

Which is what I was discussing on post #71 and #74, that I have not observed any active channel switching notification/action to clients, but I did observe when set to auto, it went to 165 (instead of default 149 - I assume registering internally that 149 at >40Mhz bandwidth detected interference. previously.) That said, in order to be successful the channel change order would have to change channels AND bandwidth. It would never find a clear upper UN-3 channel if the bandwidth is set to 80Mhz (all channels combined).