5Ghz Stops Broadcasting on Merlin 380.68_2 and above - AC3100

[jim769]

Yes right now but i have used all the Merlin builds as well. No issues with any of them as far as wifi not working or shutting down. I set mine to 80 mhz on all of them. Kinda a moot point to have a high end AC router and have to limit it to N rates by only using 40 mhz. This may fix your issue but in my opinion it is no fix.

 

[bnhf]

Just thought I'd throw this out there for those of you having problems with 5GHz WiFi:

Several of us were having very similar problems on the RT-AC66U and RT-AC68U a month or more ago. Like many of you, I was convinced the problem was related to specific versions of AsusWRT-Merlin. I was going back and forth between Asus stock and Merlin, and my testing seemed to point to Merlin firmware. Only 5GHz would drop out, 2.4GHz was always rock-solid.

Ultimately, however, this turned out to be a power supply problem. The power supply I was using had a slightly loose fitting connector on the router side. Once I switched power supplies, the problem disappeared! Obviously, no guarantee that this is the issue for a few of you on the AC3100 -- but it's certainly worth eliminating as a possibility. I'm attaching a previous thread where you can see this problem was solved for people on the other Asus models I mentioned.

https://www.snbforums.com/threads/ac66u-5ghz-radio-death.41025/#post-347656

I hope at least one of you has, or is planning to try a different power supply! I know it doesn't seem entirely logical for everything else on the router to be working fine with the exception of 5GHz due to a problem power cord/supply, but I can tell you this worked like magic on the RT-AC66U and RT-AC68U units with disappearing 5GHz. Best guess is that it's something on the DC Negative (Ground) side, since in my case having a tighter fitting barrel connector made the difference.

 

[ScottW]

That's awesome... good work narrowing it down to that specific item. Now the question becomes, why is 40MHz fixed the solution? We'll see if Merlin has any ideas.

When I was testing this back in May (discussed in separate thread), I eventually realized the 5GHz shutdown always (and only) occurred within minutes of a particular 80MHz-capable client (a Lenovo laptop) being powered up. While that isn't 100% conclusive, it did lead me to suspect the problem was triggered during "negotiation" of 80MHz operation by that client -- or perhaps the switching between 40MHz and 80MHz operation, or operation of that client in conjunction with other clients. In any case, once I found that setting the router to 40MHz eliminated the issue, I stopped testing further because I simply don't need 80MHz bandwidth.

My point here is that someone without any 80MHz-capable clients may never see the problem, regardless of the setting. I could also speculate it may be limited to specific brand clients or client chipsets/drivers, i.e., something the client driver does incorrectly in negotiation and the router or router's wireless driver code doesn't properly protect against that illegitimate client request. In that event, people without clients that use that particular client chipset/driver would never see a problem even with the 20/40/80 or 80 setting.

All I know for sure is that with my AC88U, across multiple versions of stock and merlin firmware, I never got more than 6 days without a complete 5GHz shutdown when set to 80 or 20/40/80 bandwidth. After setting it to fixed 40MHz, I haven't had a single 5GHz problem of any kind -- even when the router has been up, untouched, for periods exceeding 60 days.

I'm very happy with my AC88U despite having to turn off 80MHz to get stable operation. In all other respects, its great. But if I really needed/wanted 80MHz operation, I would have had to return it and get a different model -- because (at least with my client set) it was not stable at the 20/40/80 or 80 settings.

 

[webgrease]

When I was testing this back in May (discussed in separate thread), I eventually realized the 5GHz shutdown always (and only) occurred within minutes of a particular 80MHz-capable client (a Lenovo laptop) being powered up. While that isn't 100% conclusive, it did lead me to suspect the problem was triggered during "negotiation" of 80MHz operation by that client -- or perhaps the switching between 40MHz and 80MHz operation, or operation of that client in conjunction with other clients. In any case, once I found that setting the router to 40MHz eliminated the issue, I stopped testing further because I simply don't need 80MHz bandwidth.

My point here is that someone without any 80MHz-capable clients may never see the problem, regardless of the setting. I could also speculate it may be limited to specific brand clients or client chipsets/drivers, i.e., something the client driver does incorrectly in negotiation and the router or router's wireless driver code doesn't properly protect against that illegitimate client request. In that event, people without clients that use that particular client chipset/driver would never see a problem even with the 20/40/80 or 80 setting.

All I know for sure is that with my AC88U, across multiple versions of stock and merlin firmware, I never got more than 6 days without a complete 5GHz shutdown when set to 80 or 20/40/80 bandwidth. After setting it to fixed 40MHz, I haven't had a single 5GHz problem of any kind -- even when the router has been up, untouched, for periods exceeding 60 days.

I'm very happy with my AC88U despite having to turn off 80MHz to get stable operation. In all other respects, its great. But if I really needed/wanted 80MHz operation, I would have had to return it and get a different model -- because (at least with my client set) it was not stable at the 20/40/80 or 80 settings.

That is, return it OR run official Asus firmware Excellent addition to the thread with this info.

 

[webgrease]

I hope at least one of you has, or is planning to try a different power supply! I know it doesn't seem entirely logical for everything else on the router to be working fine with the exception of 5GHz due to a problem power cord/supply, but I can tell you this worked like magic on the RT-AC66U and RT-AC68U units with disappearing 5GHz. Best guess is that it's something on the DC Negative (Ground) side, since in my case having a tighter fitting barrel connector made the difference.

How would a power supply issue explain previous Merlin builds or official Asus firmware working for months with no issues, as well as reproducible conditions on Merlin builds identified as having this issue earlier in this thread? What test and control conditions did you have in place and what evidence was gathered to support your conclusion?

 

[ScottW]

That is, return it OR run official Asus firmware Excellent addition to the thread with this info.

The stock firmware (at least back in May) exhibited the same problem for me. It happened "out of the box" with 380.7266, and upgrading to 380.7378 did not help. I also saw same problem with RMerlin 380.65_2, 380.65_4, and 380.66_beta4.

I can't say whether one of the newer (later than 380.7378) stock firmwares fixed it, because I haven't tried them. I'm using too many RMerlin features to go back to stock!

 

[DAVIZINHO]

Now im runing in 40mhz bandwitch and all ok, not drops on 5ghz.
Next weekend i will downgrade and try to test it.
But the problem is obviously with the 80mhz bandwitch :-(
maybe the problem are the devices. i use in 5ghz a microsoft surface pro3 and 2 xiaomi mi5s phones. no more

 

[bnhf]

How would a power supply issue explain previous Merlin builds or official Asus firmware working for months with no issues, as well as reproducible conditions on Merlin builds identified as having this issue earlier in this thread? What test and control conditions did you have in place and what evidence was gathered to support your conclusion?

I understand your skepticism, it was far from the first thing I tried to fix the issue. I also found that moving back to stock Asus builds and previous Merlin builds appeared to fix the problem. And I realize that you have a different router model. But the problem you're reporting is so similar -- I thought I'd offer a solution that worked for me and a few others. Hopefully one of you battling this issue has a compatible power supply and can give it a try. We've all been guilty of letting our preconceptions get in the way of a possible solution at one time or another. Good luck!

 

[ScottW]

Now im runing in 40mhz bandwitch and all ok, not drops on 5ghz.
Next weekend i will downgrade and try to test it.
But the problem is obviously with the 80mhz bandwitch :-(
maybe the problem are the devices. i use in 5ghz a microsoft surface pro3 and 2 xiaomi mi5s phones. no more

I agree. I am 100% certain that -- in my environment, with my clients -- setting fixed 40Mhz eliminates the problem. But I also suspect the problem not just 80MHz operation, but 80MHz operation in combination with something else -- like a particular type of client or client chipset, particular combination of clients, or even something external like interference. That's the only way I can explain some people not having any problem when set to 20/40/80.

Everyone's environment and client combination is unique. And with mobile clients that "come and go" as family members come and go, or turn devices on/off, it is sometimes tough to know exactly what events coincide with the 5GHz failing - or if it is indeed random.

 

[jim769]

That's the only way I can explain some people not having any problem when set to 20/40/80.

Don't set it to 20/40/80 simply set it to 80 mhz. This how i have always done it with never a issue.

 

[ScottW]

Don't set it to 20/40/80 simply set it to 80 mhz. This how i have always done it with never a issue.

If 80MHz works for you, I absolutely support you using it. But I tried the 80MHz setting (I've never been a fan of any "auto" setting) before moving down to 40MHz, and it did NOT work for me. Same problem as with 20/40/80; a complete 5GHz failure within a few hours.

Again, based on all the reports (here and several other threads), I suspect the problem is 80MHz operation in combination with a specific client or mix of clients that use 80MHz width. That would easily explain why the behavior is slightly different for us. I also suspect most people have relatively few 80MHz capable clients, while some have none at all.

With 20/40/80 or 80, mine consistently failed and never made it more than 6 days. I was being very methodical, making ONE setting change at a time, then waiting for a failure -- then making ONE change and waiting again.... It has been 5 months since I changed to 40MHz -- and there hasn't been a single loss of 5GHz.

 

[bsdsource]

When I was testing this back in May (discussed in separate thread), I eventually realized the 5GHz shutdown always (and only) occurred within minutes of a particular 80MHz-capable client (a Lenovo laptop) being powered up.

ScottW, is seems in your case you narrowed down the wireless problem to a specific Lenovo laptop with 80MHz capability which was triggering the 5GHz failure. If you can find the time to test your router again specially with that laptop and can reproduce the failure it would be great to share what specific wireless network card/adapter that laptop is using. Maybe others with the same hardware will be able to reproduce your finding and ASUS will be able to fix this issue for good.

I'm still not having any issues with mine. Although I use asuswrt-merlin source code for the most part I use Asus's stock firmware web asp logs since I prefer them over RMerlin's. Here's what my wireless log reports minus the station's list (clients):

SSID: "SECTION_8"
RSSI: 0 dBm    SNR: 0 dB    noise: -88 dBm    Channel: 6
BSSID: 00:00:00:00:00:00    Capability: ESS ShortSlot
Supported Rates: [ 1(b) 2(b) 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
VHT Capable:
    Chanspec: 2.4GHz channel 6 20MHz (0x1006)
    Primary channel: 6
    HT Capabilities:
    Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ]
    VHT Capabilities:
    Supported VHT (tx) Rates:
        NSS: 1 MCS: 0-11
        NSS: 2 MCS: 0-11
        NSS: 3 MCS: 0-11
        NSS: 4 MCS: 0-11
    Supported VHT (rx) Rates:
        NSS: 1 MCS: 0-11
        NSS: 2 MCS: 0-11
        NSS: 3 MCS: 0-11
        NSS: 4 MCS: 0-11

Mode    : AP Only


SSID: "SECTION_9"
RSSI: 0 dBm    SNR: 0 dB    noise: -89 dBm    Channel: 153/80
BSSID: 00:00:00:00:00:00    Capability: ESS
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
VHT Capable:
    Chanspec: 5GHz channel 155 80MHz (0xe19b)
    Primary channel: 153
    HT Capabilities:
    Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ]
    VHT Capabilities:
    Supported VHT (tx) Rates:
        NSS: 1 MCS: 0-11
        NSS: 2 MCS: 0-11
        NSS: 3 MCS: 0-11
        NSS: 4 MCS: 0-11
    Supported VHT (rx) Rates:
        NSS: 1 MCS: 0-11
        NSS: 2 MCS: 0-11
        NSS: 3 MCS: 0-11
        NSS: 4 MCS: 0-11

Mode    : AP Only

 

[ScottW]

ScottW, is seems in your case you narrowed down the wireless problem to a specific Lenovo laptop with 80MHz capability which was triggering the 5GHz failure. If you can find the time to test your router again specially with that laptop and can reproduce the failure it would be great to share what specific wireless network card/adapter that laptop is using. Maybe others with the same hardware will be able to reproduce your finding and ASUS will be able to fix this issue for good.

That’s an excellent suggestion. I will inspect that laptop and report what the embedded WiFi hardware and driver are. If others having the same problem have devices in their households using the same chipset/driver, it may be significant.

Unfortunately the laptop is offsite at the moment - but I think it will be here tomorrow and I will report back once I get my hands on it.

 

[RMerlin]

I didn't see any response to the issue in other threads from @RMerlin

I simply don't have anything to add to the discussion. The entire wireless code is closed source, and therefore outside of my control, with all the components coming directly from Asus' own GPL releases. That means the entire wireless stack is coming from Asus' GPL releases. If people are seeing different behaviour, then it would mean the components included in Asus's GPL do not match those used by their released firmware. Which, once again, is totally outside of my control.

Beyond that, my RT-AC88U recently reached 17 days of uptime with zero wifi issues for any of my devices (Lenovo Yoga with an Intel 7265AC, Zenpad with a Mediatek chip, Nexus 5X with Qualcomm chip). The uptime was reset as I needed to do some development stuff on the AC88U (so I temporarily swapped it for an RT-AC68 C1).

I've already made the only recommendations I could make (disable beamforming, MU-MIMO and Airtime Fairness, use a fixed channel, and don't use DFS channels).

Over the past year or so, the only wifi issues I ever encountered were one caused by a buggy Intel driver (upgrading from 19.50 to 19.51 fixed its low throughput), and the Zenpad's crappy Mediatek that's unstable when using U-NII-3 channels - 100% stable after switching to U-NII-1. Both cases caused by the client, not by the router.

 

[ScottW]

. That means the entire wireless stack is coming from Asus' GPL releases. If people are seeing different behaviour, then it would mean the components included in Asus's GPL do not match those used by their released firmware. Which, once again, is totally outside of my control.

I agree, and will restate that I have seen NO difference in this problem between Asus and Rmerlin. I have had exactly the same issues with multiple versions of Asus and Rmerlin, so have concluded that the problem is in the wireless driver or other closed source Asus components.

I have seen different behaviors reported by different owners. Other settings (airtime fairness, beamforming, etc.) have been ruled out for this particular issue, so it seems most likely it is triggered by specific clients or environmental conditions. A misbehaving client or interference should never result in complete shutdown of the 5G radio - so ultimately the real problem resides in the Asus or Broadcom closed sources.

Until there is a way to reliably replicate the issue on demand, and perhaps not even then, I cannot be optimistic that Asus will recognize or fix the problem.

 

[webgrease]

I agree, and will restate that I have seen NO difference in this problem between Asus and Rmerlin. I have had exactly the same issues with multiple versions of Asus and Rmerlin, so have concluded that the problem is in the wireless driver or other closed source Asus components.

I have seen different behaviors reported by different owners. Other settings (airtime fairness, beamforming, etc.) have been ruled out for this particular issue, so it seems most likely it is triggered by specific clients or environmental conditions. A misbehaving client or interference should never result in complete shutdown of the 5G radio - so ultimately the real problem resides in the Asus or Broadcom closed sources.

Until there is a way to reliably replicate the issue on demand, and perhaps not even then, I cannot be optimistic that Asus will recognize or fix the problem.

While I know this would be a huge PITA, it would be very interesting to see what happens if you flashed to official Asus RT-AC3100_3.0.0.4_382_15852 and left the setting defaulted to 20/40/80, as well as the default settings for the rest of the ones tested in this thread. For me, this resolved the issue, and at least provides a glimmer of hope that when AM382.xx is released, it will be fixed.

Since I am not able to reproduce the issue with the official Asus firmware, I wouldn't be able to open a ticket with Asus to get them to look at the issue.

 

[Kruegs]

That's a great point on the new code base and the official Asus FW. I had the same experience before I reached out to Asus with the recommendations on page one of this thread... not a single 5Ghz drop on their latest FW. Guess we'll see once Merlin releases the new goods based on 382....

 

[ScottW]

While I know this would be a huge PITA, it would be very interesting to see what happens if you flashed to official Asus RT-AC3100_3.0.0.4_382_15852 and left the setting defaulted to 20/40/80, as well as the default settings for the rest of the ones tested in this thread.

I agree -- that would be a huge PITA. Sorry, but I'm currently satisfied with having stable operation (albeit without 80MHz bandwidth), particularly because the family has stopped complaining about all the untimely disruptions. As well, I have multiple scripts that rely on the Rmerlin firmware.

So I am more inclined to wait for Eric to release a 382 build for AC88U -- I think that and 3100 are the next place he intends to work once he is satisfied with how it works on AC86U. Hopefully your experience with the stock 382_15852 means the problem has been addressed by Asus and that will flow into RMerlin's 382 releases!

 

[ScottW]

ScottW, is seems in your case you narrowed down the wireless problem to a specific Lenovo laptop with 80MHz capability which was triggering the 5GHz failure. If you can find the time to test your router again specially with that laptop and can reproduce the failure it would be great to share what specific wireless network card/adapter that laptop is using. Maybe others with the same hardware will be able to reproduce your finding and ASUS will be able to fix this issue for good.

The "suspect" laptop triggering the 5GHz failure here is a Lenovo Z70. The wireless is reported as "Qualcomm Atheros QCA61x4", with driver version 12.0.0.278. Based on the PCI ID, the specific model is QCA6174.

I continue to say "suspect" because I eventually noticed that the last few 5GHz shutdowns occurred within moments of this laptop connecting to the network. I can't say every previous failure occurred coincident with this, but the last few definitely did. Of course there are other devices (including some 80MHz capable devices, like late-model iPads) that are always online, so it could also be a combination of those 80MHz devices *and* this laptop negotiating 80MHz. Much more testing would be required for me to isolate this laptop as the sole trigger in my environment, but anecdotal evidence did make me suspect it.

As indicated earlier, I stopped researching further once I found that setting fixed 40MHz bandwidth eliminated the 5GHz shutdowns. All household members (me most of all) were really frustrated with the disruptions, and giving up 80MHz was a super-easy choice to gain stable operation.

Given that I saw the issue in multiple versions of both Stock and RMerlin firmware, and that it is a complete shutdown of the 5GHz radio, I concluded (guessed) it was likely a wireless driver problem. I am encouraged by posts in this thread saying the newest stock firmware doesn't have the issue, because if that is the case, then the upstream fix -- whatever it is -- will hopefully flow into the upcoming AM382.

 

[RMerlin]

So I am more inclined to wait for Eric to release a 382 build for 3100/AC88U -- I think that is the next platform he intends to work on once he is satisfied with how it works on AC86U.

The RT-AC88U implementation is almost done, but everything is currently stalled as there seems to be a problem with the GPL release for that model. Even when I compile the straight GPL code, the router gets stuck at boot time when launching the acsd daemon. I already reached out to Asus about it, makes me suspect that the GPL release contains the incorrect binary blobs. Taiwan was on a national holiday this past weekend, so we have to wait for them to get back in the office to look into it.

As for the RT-AC3100, not having one, I cannot test it and therefore cannot tell if that one has working binary blobs or not. Seing the AC88U issues with 382_15850, I don't want to chance it for now.