Release ASUS RT-AX86U Firmware version 3.0.0.4.386_49447 (2022/06/20)

[tommie]

Asus added line 9 to the release notes today, the firmware version number remains the same.
OP is updated.

Added line:
9. Fixed anomalous 802.11 frame issues.
Thanks to Kari Hulkko and Tuomo Untinen from The Synopsys Cybersecurity Research Center (CyRC). Issue was found by using Defensics Fuzz Testing Tool.

 

[Tech9]

I don't know what Asus updated, but I tried running AX86U in my downtown apartment with very hostile Wi-Fi environment around and still 46061 firmware performs better than 49447. I had no disconnections, but 46061 is much more consistent in throughput and moves files over Wi-Fi faster.

If Auto Firmware Update is Disabled in Administration, will the router still auto upgrade? What's the experience with this one?

 

[OzarkEdge]

Yeah, you may be right. I will watch it here more closely. So far, my 160MHz experience with my one ax client has been similar including 46061... it eventually drops to 80MHz.

OE

Or it never gets to 160MHz even though 36/160 is cleared for take off.

It also seems that the bandwidth and channel settings get into a 'can't get there from here' state when trying to set 160MHz and ch 36-48. Then when I give up and set a different combination, I can go back to setting what I could not set previously... as if the firmware logic gets confused.

OE

 

[RogerSC]

I don't know what Asus updated, but I tried running AX86U in my downtown apartment with very hostile Wi-Fi environment around and still 46061 firmware performs better than 49447. I had no disconnections, but 46061 is much more consistent in throughput and moves files over Wi-Fi faster.

If Auto Firmware Update is Disabled in Administration, will the router still auto upgrade? What's the experience with this one?

View attachment 42504

If "auto firmware upgrade" is off, your router will not upgrade automatically. That's the way that I have my Asus routers set up, I want to control when they're upgraded and what firmware they have on them.

 

[bbunge]

Still not having any issues with WIFI here. 5GHz switches from 80 MHz to 160 MHz and stays there as long as the client that is 160 MHz capable stays connected. I do have DFS enabled and WPA3/WPA2-Personal enabled. The 5GHz seems to like channel 52. I had tried Merlin 386.7 for a couple of days, with no real issues, but went back to Asus. Also using a USB2 thumb drive for my AiCloud sync.

 

[OzarkEdge]

I may need more than one ax client to test, if the router is 'switching' 5.0 bw based on ax client connection. Sometimes I'll get ax 160... sometimes it stays at 80, even when cleared for 160. Also seems a bit more reliable setting ch Auto, excluding DFS vs fixing the same non-DFS control ch.

All of my testing is confined to N-NII-1,2a bands with a non-DFS control channel (required for a legacy n client).

It does feel like the firmware needs more tuning.

OE

 

[bbunge]

I may need more than one ax client to test, if the router is 'switching' 5.0 bw based on ax client connection. Sometimes I'll get ax 160... sometimes it stays at 80, even when cleared for 160. Also seems a bit more reliable setting ch Auto, excluding DFS vs fixing the same non-DFS control ch.

All of my testing is confined to N-NII-1,2a bands with a non-DFS control channel (required for a legacy n client).

It does feel like the firmware needs more tuning.

OE

Actually I have an AC client that does 160 MHz.

 

[OzarkEdge]

Actually I have an AC client that does 160 MHz.

OK, I may need more than one 160MHz client to test 160MHz.

Or at least one that reliably connects at 160MHz bw.

OE

 

[OzarkEdge]

For example:

My one 160MHz client is connected at 80MHz and the router is not even trying to use a U-NII-1 non-DFS control channel (36-48) and 160MHz bandwidth.

But if I futz around with the bw/ch settings and/or set a fixed channel 36-48, I can some times get a 160MHz connection that has held for up to a week. OR, the router will clear a ch for 160MHz, but the client will remain at 80MHz.

It's not consistent... either the router or the client or the interaction of them. Given these behaviors did change some with the current firmware... not necessarily better or worse than the previous firmware... I'm inclined to look forward to improvements in the next release.

(My client is about 4' to the side and 4' down from the router... maybe I should move something.)

OE

 

[SAL9K]

Fwiw, I also have an ax201 (w/ intel driver 22.140.0) that is seamlessly connecting w/ [36-48]/160MHz (DFS disabled). The ax86u drops down to 80MHz when the client is off, but reliably goes back to 160MHz when it's on. I use all WiFi defaults, but did enable WPA2/WPA3-Personal. I live about 10mi from a major airport, but the DFS interference seems to be minimal. When the connection is at 160MHz, I actually don't feel a speed difference, as the client is in a relatively far location from router, and can only ul/dl ~400Mbps even though connected at >1200Mbps.

What 160MHz capable client(s) are having the issue?

 

[OzarkEdge]

Fwiw, I also have an ax201 (w/ intel driver 22.140.0) that is seamlessly connecting w/ [36-48]/160MHz (DFS disabled). The ax86u drops down to 80MHz when the client is off, but reliably goes back to 160MHz when it's on. I use all WiFi defaults, but did enable WPA2/WPA3-Personal. I live about 10mi from a major airport, but the DFS interference seems to be minimal. When the connection is at 160MHz, I actually don't feel a speed difference, as the client is in a relatively far location from router, and can only ul/dl ~400Mbps even though connected at >1200Mbps.

What 160MHz capable client(s) are having the issue?

I have a Killer(R) Wi-Fi 6 AX1650x 160MHz Wireless Network Adapter (200NGW), of Rivet Networks, now owned by Intel.

I just uninstalled the Rivet driver package and installed the current Intel driver package... the actual Intel wireless driver updated from 22.130.*/Mar'22 to 22.140.*/Apr'22... not a big leap forward.

If I set 20/40/80/160 and ch 36, it connects at 80MHz... 36/80. Then if I switch to ch Auto, no DFS, it will connect at 160MHz... 36/160. Then if I switch it back to ch 36... essentially the same... it reverts to 80MHz... 36/80. etc. And not always.

I don't think it's a client issue.

OE

 

[SAL9K]

Oh, I see, if you set bandwidth to 20/40/80/160, and manually choose a non DFS channel [36,48] then the router only does [36,48]/80. I see the same behavior w/ intel ax201. However, I can force [36,48]/160 and that seems to work ok.

So, is the lesson learned here, that folks with 160 problems should instead force [36,48]/160, and if that doesn't work you're probably screwed with auto settings doing the same. Idk, this 49447 and 160MHz is working really well for me in auto settings, I finally want more AX clients! But perhaps 49447 is indeed more strict with its DFS enforcement and that's why others prefer 46061.

 

[OzarkEdge]

Oh, I see, if you set bandwidth to 20/40/80/160, and manually choose a non DFS channel [36,48] then the router only does [36,48]/80. I see the same behavior w/ intel ax201. However, I can force [36,48]/160 and that seems to work ok.

So, is the lesson learned here, that folks with 160 problems should instead force [36,48]/160, and if that doesn't work you're probably screwed with auto settings doing the same. Idk, this 49447 and 160MHz is working really well for me in auto settings, I finally want more AX clients! But perhaps 49447 is indeed more strict with its DFS enforcement and that's why others prefer 46061.

Here's what I try (from my install notes):

5.0 1,2a fixed - 160MHz bw; ch 36-48 (non-DFS)
5.0 1,2a auto - 20-40-80-160MHz bw; ch Auto, excluding DFS chs (36-48)
5.0 2c fixed - 20-40-80-160MHz bw; ch 100-116 (DFS)
5.0 1,3 fixed - 80MHz bw, disable 160MHz; ch 36-48,149-161 (non-DFS)
5.0 1,3 auto - 80MHz bw, disable 160MHz; ch Auto, excluding DFS chs (36-48,149-161)
Start with U-NII bands 1,2a fixed; if airport/radar/DFS prevents 160MHz bw, switch to 1,3 fixed. Determine specific control channel for best client/backhaul connections; if WiFi/other interference persists, switch to auto.
Client must support control channel and should connect at its best mode/bandwidth/authentication permitted.

If I set 5.0 1,2a fixed, I get 80MHz.

If I set 5.0 1,2a auto, I sometimes get 160MHz... I see no pattern to it.

Lesson (re)learned is to wire my one ax PC client!

And/or, use 5.0 1,3 fixed and a N-NII-3 control channel 149-161 for best client/backhaul connections.

Dual-band WiFi6 can be marginally useful... and not at all without more exact firmware.

OE

 

[bbunge]

Here's what I try (from my install notes):

5.0 1,2a fixed - 160MHz bw; ch 36-48 (non-DFS)
5.0 1,2a auto - 20-40-80-160MHz bw; ch Auto, excluding DFS chs (36-48)
5.0 2c fixed - 20-40-80-160MHz bw; ch 100-116 (DFS)
5.0 1,3 fixed - 80MHz bw, disable 160MHz; ch 36-48,149-161 (non-DFS)
5.0 1,3 auto - 80MHz bw, disable 160MHz; ch Auto, excluding DFS chs (36-48,149-161)
Start with U-NII bands 1,2a fixed; if airport/radar/DFS prevents 160MHz bw, switch to 1,3 fixed. Determine specific control channel for best client/backhaul connections; if WiFi/other interference persists, switch to auto.
Client must support control channel and should connect at its best mode/bandwidth/authentication permitted.

If I set 5.0 1,2a fixed, I get 80MHz.

If I set 5.0 1,2a auto, I sometimes get 160MHz... I see no pattern to it.

Lesson (re)learned is to wire my one ax PC client!

And/or, use 5.0 1,3 fixed and a N-NII-3 control channel 149-161 for best client/backhaul connections.

Dual-band WiFi6 can be marginally useful... and not at all without more exact firmware.

OE

Are you using Dual Band SmartConnect and WPA2/WPA3-Personal?

 

[OzarkEdge]

Are you using Dual Band SmartConnect and WPA2/WPA3-Personal?

Not using SC... clients seem to roam better/more directly without it and I'm not forced to use Wireless Mode Auto.

Using WPA2/WPA3-Personal... have not noticed any client issues with it.

OE

 

[OzarkEdge]

I'm fixing 80MHz bw and waiting for the next firmware... there is something not right with DFS in this release when setting ch Auto yields 36/160 and a stable 160MHz bw connection, but setting ch 36 yields 36/80 and an 80MHz bw connection... essentially the same bandwidth and control channel settings yield reliably different results.

OE

 

[bbunge]

I'm fixing 80MHz bw and waiting for the next firmware... there is something not right with DFS in this release when setting ch Auto yields 36/160 and a stable 160MHz bw connection, but setting ch 36 yields 36/80 and an 80MHz bw connection... essentially the same bandwidth and control channel settings yield reliably different results.

OE

I am still on Auto channel for both bands with 160MHz and DFS enabled. 5 GHz is usually on channel 52 or 60 at 80 or 160 MHz depending on which clients connect. Did get RADAR bounced the other day which put 5 GHz to channel 161 for a while.

 

[SteverinoLA]

With this firmware my 86U no longer shows or support any DFS channels... as soon as I add my AX55 as an AIMesh client. This wasn't the case in prior releases. Is it the same for everyone else? Surely, I'm not the only one w/an 86U and a lower-end AX AIMesh client. I can't remember, does the AX55 support DFS channels? And also, my log is filled completely with this set of errors repeating every half hour or so:

Jul 9 11:55:47 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xe832 (36/160)
Jul 9 11:55:47 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xe832 (36/160)
Jul 9 11:55:47 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xe832 (36/160)
Jul 9 11:55:47 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xe932 (40/160)
Jul 9 11:55:47 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xe932 (40/160)
Jul 9 11:55:47 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xe932 (40/160)
Jul 9 11:55:47 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xea32 (44/160)
Jul 9 11:55:47 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xea32 (44/160)
Jul 9 11:55:47 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xea32 (44/160)
Jul 9 11:55:47 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xeb32 (48/160)
Jul 9 11:55:47 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xeb32 (48/160)
Jul 9 11:55:47 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xeb32 (48/160)

 

[OzarkEdge]

I am still on Auto channel for both bands with 160MHz and DFS enabled. 5 GHz is usually on channel 52 or 60 at 80 or 160 MHz depending on which clients connect. Did get RADAR bounced the other day which put 5 GHz to channel 161 for a while.

I see you are allowing DFS control channels 52 or 60. I do not since I have a legacy client that requires a non-DFS control channel. So that's a difference in our settings.

On your second point regarding bounce to ch 161, did it ever return to using 160MHz on the low bands? I've been wondering how long it stays off DFS channels.

OE

 

[OzarkEdge]

With this firmware my 86U no longer shows or support any DFS channels... as soon as I add my AX55 as an AIMesh client. This wasn't the case in prior releases. Is it the same for everyone else? Surely, I'm not the only one w/an 86U and a lower-end AX AIMesh client. I can't remember, does the AX55 support DFS channels? And also, my log is filled completely with this set of errors repeating every half hour or so:

Jul 9 11:55:47 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xe832 (36/160)
Jul 9 11:55:47 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xe832 (36/160)
Jul 9 11:55:47 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xe832 (36/160)
Jul 9 11:55:47 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xe932 (40/160)
Jul 9 11:55:47 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xe932 (40/160)
Jul 9 11:55:47 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xe932 (40/160)
Jul 9 11:55:47 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xea32 (44/160)
Jul 9 11:55:47 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xea32 (44/160)
Jul 9 11:55:47 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xea32 (44/160)
Jul 9 11:55:47 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xeb32 (48/160)
Jul 9 11:55:47 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xeb32 (48/160)
Jul 9 11:55:47 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xeb32 (48/160)

I'm not missing DFS channels here. And do not have those log entries, but I have other concerning entries. Your ch/bw entries suggest the Auto/DFS scanning does not like those parameters... or maybe the firmware can't find DFS channels either for 160MHz bw.

Too many entries to browse without knowing what they mean. Maybe they left the logging level high to help shake out some feedback on unresolved issues.

OE