Release ASUS RT-AX86U Firmware version 3.0.0.4.386_49599 (2022/07/12)

[willyburz]

I haven't downloaded quite yet. Sooooooo, can I hardlock ch36 and 160hz again, or will it dump to 80hz in an hour like it has been doing?!?!?!

Scrooling through, but haven't seen much input as to this fixing the 160 lock I want.

 

[tallytr]

My 160MHz Wi-Fi is stable just as with all previous firmware, I think this is very much down to the individual settings and the router environment, your location...

 

[willyburz]

I hadn't had ANY issues with 160 staying locked until the previous firmware, hoping this weeks corrects that. Historically I set locked 36 and 160...then when the new hit I even tried auto and auto, or 36 and auto...etc etc, and it would just dump to 80hz within an hour or two no matter the setting.

 

[SAL9K]

@SAL9K, do you have any links to support your statement? We may be (I may be) misinterpreting what you're saying to each other.

If you hold everything else the same, and just change the distance, then 1/r^2 must be true.

Yes, you can review any antenna design book (or ham radio book), or also this website has good coverage.

https://www.antenna-theory.com/

Different antenna's, have different directivity gains, w.r.t. a true omnidirectional (or isotropic) antenna. The 1/r^2 is for an ideal omni antenna, which doesn't exist in real life, as all real antenna's have directivity. Check out the video about half-wave dipoles, which is the typical one used for routers (super common). This has a directivity, D=~2dB, which means that a vertical 1/2 wave dipole will be 2dB stronger in the horizontal direction than on ideal omni (1/r^2) one. That's what's meant by antenna "gain", i.e. how much louder is it in its strongest direction with respect to an ideal omni antenna.

https://www.antenna-theory.com/antennas/halfwave.php

The D changes for every antenna type; all antenna's and radiation patterns are not created equal.

 

[tallytr]

I hadn't had ANY issues with 160 staying locked until the previous firmware, hoping this weeks corrects that. Historically I set locked 36 and 160...then when the new hit I even tried auto and auto, or 36 and auto...etc etc, and it would just dump to 80hz within an hour or two no matter the setting.

That works well for me.

 

[SAL9K]

Well, shoot, my router has now been stuck on 161/80 for over a day, and refuses to go back to [36,48]/160 when my capable ax200 clients are on (as it did before this f/w). I must have DFS interference, as every 15-30 minutes the below (repetitively) shows in the logs.

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

 

[Paliv]

Well, shoot, my router has now been stuck on 161/80 for over a day, and refuses to go back to [36,48]/160 when my capable ax200 clients are on (as it did before this f/w). I must have DFS interference, as every 15-30 minutes the below (repetitively) shows in the logs.

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

That’s unfortunate. We have an airport and and Air Force base a few miles away. There’s been increased air traffic at the base with recent events. I find 160 is more trouble than it’s worth. But I don’t have any backups or large file transfers running over wifi.

 

[SAL9K]

That’s unfortunate. We have an airport and and Air Force base a few miles away. There’s been increased air traffic at the base with recent events. I find 160 is more trouble than it’s worth. But I don’t have any backups or large file transfers running over wifi.

Oh well, 80mhz is plenty fast in the scheme of things, and I'd rather lose some b/w then have a Donnie Darko situation landing on my house, lol. Btw, I'm also sandwiched in btwn an international airport and and air force base, so I was very surprised to ever see 160 working.

 

[neil0311]

I hadn't had ANY issues with 160 staying locked until the previous firmware, hoping this weeks corrects that. Historically I set locked 36 and 160...then when the new hit I even tried auto and auto, or 36 and auto...etc etc, and it would just dump to 80hz within an hour or two no matter the setting.

My experience has been the same as yours.

 

[DiGz_Au]

The wifi drivers for this build are good. Using Australia setting (my location) and locking 36 to 160mhz works flawlessly. I'd have to say that there would be some kind of major update (388) coming eventually to solve majority of people's issue. I myself will move to the pro model once I can purchase the bloody thing.

 

[iFrogMac]

Just thought I would post an update here on my settings after testing this new firmware. I'm still unable to run the 2.4Ghz band on the router in mixed, or N only mode without my lights becoming unresponsive, or slow to respond in Alexa routines. However, keeping it set to legacy for 2.4 Ghz, and Auto+WiFi 6 for 5Ghz works without issues. The best explanation I can come up with after reading iOT threads on this forum, and smart home specific sources is: a lot of smart devices (bulbs, etc) use cheap, poor quality, or old chipsets that can cause compatibility issues with newer chipsets. The evidence of this in my setup is, when I went back to one of my older devices as a mixed mode AP for 2.4, or putting the Asus 2.4 into legacy mode, the problems with these devices go away.

The good news is, I do have options that make things stable, and I can continue to use the RT-AX86U as the daily driver. The other good news is, with the exception of the smart bulbs, I don't need 2.4Ghz at al, as my other devices l use all support 5Ghz, and therefore, could just turn it off and go 5Ghz, and Ethernet only. At least, I can get by with a minimal 2.4Ghz network. Just enough to give the devices a stable connection. (One note) my amazon smart plugs are 2.4Ghz only as well, but they don't seem to have the same issues as the bulbs.

So, to end with a bit of correction, the bulbs, and plugs are the only reason I still need a 2.4Ghz network. However, the bulbs are the main devices that exhibit any kind of compatibility issues in the way I prefer to use them.

 

[gp-se]

I just updated, I don't use 160mhz channels so I can't comment on that. However everything seems to be working good, WiFi deveices seem to be performing better with this firmware.

 

[ASciTek]

After an update is it necessary to perform a reset?

 

[OzarkEdge]

After an update is it necessary to perform a reset?

I think you should always allow for it and if necessary, do it. That's as good as it gets, imo.

There is no firm advice that it is necessary in this instance.

OE

 

[iFrogMac]

I think you should always allow for it and if necessary, do it. That's as good as it gets, imo.

There is no firm advice that it is necessary in this instance.

OE

The suggestions I've seen here on this forum are as follows:
Going from Stock to Merlin, or from Merlin back to Stock: Do a full reset.
Going from major updates of stock firmware: It's a good idea to do a full reset.
Going from point releases of stock firmware, it's not necessary usually.

As usual, if problems are encountered after an update, do a full reset, if that doesn't resolve the issue, roll back to the previous firmware.

 

[OzarkEdge]

The suggestions I've seen here on this forum are as follows:
Going from Stock to Merlin, or from Merlin back to Stock: Do a full reset.
Going from major updates of stock firmware: It's a good idea to do a full reset.
Going from point releases of stock firmware, it's not necessary usually.

As usual, if problems are encountered after an update, do a full reset, if that doesn't resolve the issue, roll back to the previous firmware.

They were asking about this release.

OE

 

[iFrogMac]

They were asking about this release.

OE

I know, those general guidelines probably apply here as well. I was going to do a reset on mine, but since I haven't had any issues, I just left it alone.
@ASciTek It sounded to me like you were asking about updates in general, that's why I gave you those guidelines.

 

[OzarkEdge]

It sounded to me like you were asking about updates in general, that's why I gave you those guidelines.

This covers that:

Reset FAQ
Reset/Restore - clears settings in NVRAM; reboot restores fw defaults from CFE (fw defaults)
Hard Reset/Restore+Initialize - also clears data logged in /jffs partition (fw defaults+clear logs)
Restoration - uploads fw in Rescue Mode

I always Restore+Initialize so I can know new defects when I experience them.

OE

 

[ASciTek]

I know, those general guidelines probably apply here as well. I was going to do a reset on mine, but since I haven't had any issues, I just left it alone.
@ASciTek It sounded to me like you were asking about updates in general, that's why I gave you those guidelines.

I was just asking in general but I appreciate the extra info. I remember reading somewhere that it should be done after each upgrade but couldn’t remember the specifics.

When you have over 20+ connected devices it can be a hassle setting them up again after a reset, especially those damn Wemo plugs lol.

 

[Tech9]

I remember reading somewhere that it should be done after each upgrade

Not necessary. Only if something goes wrong.