Release ASUS RT AC86u Firmware - 3.0.0.4.384_81992-gdc7a780

[OzarkEdge]

It included very useful info, reading is fundamental.

Here's the whole quote, not the selected portion you chose:

"Thanks, I took the plunge and reset worked fine. The new encryption stuff doesn't play well when you roll back, be advised if you install the new firmware, you'll face the same issue when rolling back.

These are specific ac86u reset steps I took:
Product GT-AC5300, GT-AX11000, GT-AX11000 (Call of duty 4), RT-AC2900, RT-AC86U, RT-AX88U

ASUS router Hard Factory Reset - Method 2

1. Turn the router off.
2. Press and hold the "WPS" button and turn the router on.
3. Power light is on (keep holding the WPS button).
4. Release the WPS button after the power light is off.
5. Reboot your router by manually pressing the power button.

Afterwards set up router as new again, then loaded latest firmware again. All is well..."

Resetting and configuring routers is fundamental. It's what we all do when nothing else works... nothing revelatory there.

OE

 

[ATLga]

Resetting and configuring routers is fundamental. It's what we all do when nothing else works... nothing revelatory there.

OE

The revelatory part that you are failing to see is that with this firmware, rolling back REQUIRES a reset because of the new encryption.

 

[ATLga]

The revelatory part that you are failing to see is that with this firmware, rolling back REQUIRES a reset because of the new encryption.

There was a thread several weeks/months ago for another router (maybe ac88 or ax88) with a similar situation where someone had applied new firmware and then attempted a rollback and the encryption had the stuck captcha crap. RMerlin replied that with that new firmware and new encryption methods in it, it would require a reset to roll back. Starting with this firmware version, it has that same behavior.

 

[Neil62]

Yes, I've tried them all. I did not notice any issues at first, but after my definite experience with 81992, and reviewing similar issues posted for 81918, and noticing the three in short succession... 81918, 81930, and 81992... I'm inclined to suspect all three including 81930.

After struggling with rebuilding 81992 and getting nowhere, I was certain I wanted to go back beyond 81918. So far, 81858 is feeling reliable... no weird WiFi issues on the node that I've noticed.

I realize this is not a very definitive assessment, but we know that nearly every release can introduce new issues. It should not be this way but it is, so we have to roll with.

The trick is to 'know broken' when you experience it and take action to get rid of it... it's generally not about changing settings! @K-2SO made a similar point recently.

OE

Ok, thanks for the update, I too, am staying for now, also on 81858, for me as well, it seems the most stable in my environment.

 

[MarkyPancake]

Was there a wireless driver change in 81992 and do Asus ever call this out in their release notes? I've seen this level of detail mentioned in Merlin's release notes in the past.

 

[gfondeur]

Two weeks here no a single issue, just saying

 

[OzarkEdge]

Two weeks here no a single issue, just saying

One 86U is no AiMesh, just saying

OE

 

[DarkKnight75]

No Aimesh on my network and rock solid release after 2 weeks.

 

[KevTech]

Was there a wireless driver change in 81992 and do Asus ever call this out in their release notes? I've seen this level of detail mentioned in Merlin's release notes in the past.

Driver version is the same as 81930.

81930
wl0: Mar 4 2020 18:28:18 version 10.10.122.20 (r683106)


81992
wl0: Jun 29 2020 11:50:38 version 10.10.122.20 (r683106)

 

[OzarkEdge]

Driver version is the same as 81930.

81930
wl0: Mar 4 2020 18:28:18 version 10.10.122.20 (r683106)


81992
wl0: Jun 29 2020 11:50:38 version 10.10.122.20 (r683106)

I'd like to know if there was a 'wireless driver' change between 81858 and 81918.

OE

 

[KevTech]

I'd like to know if there was a 'wireless driver' change between 81858 and 81918.

Does not appear to be any changes.

81858
wl0: Mar 4 2020 18:28:18 version 10.10.122.20 (r683106)

81918
wl0: Mar 4 2020 18:28:18 version 10.10.122.20 (r683106)

 

[keefrto]

Hi, so I was happily working away on my searches for stuff online when there was no wifi, it just stopped working.I checked the general log and I don't understand any of the description detailed, can anyone decipher this for me? I apologize if this is not the correct thread to post this on, I searched wifi keeps dropping and this came up. i have x2 Asus rt ac86u and one Asus rt ac68u. one of the 86u is the main router and the other 2 are aimeshed. this happened in the basement 15ft away from the main router.

Jul 27 13:23:29 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth6: Deauth_ind 48:60:5F:84:94:41, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jul 27 13:23:29 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth6: Disassoc 48:60:5F:84:94:41, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul 27 13:23:29 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth5: Auth 48:60:5F:84:94:41, status: Successful (0)
Jul 27 13:23:29 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth5: Assoc 48:60:5F:84:94:41, status: Successful (0)
Jul 27 13:23:29 dnsmasq-dhcp[1225]: DHCPDISCOVER(br0) 48:60:5f:84:94:41
Jul 27 13:23:29 dnsmasq-dhcp[1225]: DHCPOFFER(br0) 192.168.50.186 48:60:5f:84:94:41
Jul 27 13:23:29 dnsmasq-dhcp[1225]: DHCPREQUEST(br0) 192.168.50.186 48:60:5f:84:94:41
Jul 27 13:23:29 dnsmasq-dhcp[1225]: DHCPACK(br0) 192.168.50.186 48:60:5f:84:94:41 G7-ThinQ
Jul 27 13:23:41 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind F8:AC:65:00:FB:A4, status: 0, reason: Unspecified reason (1)
Jul 27 13:23:41 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth5: Disassoc F8:AC:65:00:FB:A4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul 27 13:23:49 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth5: Auth F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:23:49 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth5: Assoc F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:23:49 dnsmasq-dhcp[1225]: DHCPREQUEST(br0) 192.168.50.47 f8:ac:65:00:fb:a4
Jul 27 13:23:49 dnsmasq-dhcp[1225]: DHCPACK(br0) 192.168.50.47 f8:ac:65:00:fb:a4 DESKTOP-PVFEEUG
Jul 27 13:23:49 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind F8:AC:65:00:FB:A4, status: 0, reason: Unspecified reason (1)
Jul 27 13:23:49 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth5: Disassoc F8:AC:65:00:FB:A4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul 27 13:23:50 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth5: Auth F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:23:50 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth5: Assoc F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:23:50 dnsmasq-dhcp[1225]: DHCPREQUEST(br0) 192.168.50.47 f8:ac:65:00:fb:a4
Jul 27 13:23:50 dnsmasq-dhcp[1225]: DHCPACK(br0) 192.168.50.47 f8:ac:65:00:fb:a4 DESKTOP-PVFEEUG
Jul 27 13:24:19 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind F8:AC:65:00:FB:A4, status: 0, reason: Unspecified reason (1)
Jul 27 13:24:19 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth5: Disassoc F8:AC:65:00:FB:A4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul 27 13:24:20 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth6: Auth F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:24:20 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth6: Assoc F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:24:21 dnsmasq-dhcp[1225]: DHCPREQUEST(br0) 192.168.50.47 f8:ac:65:00:fb:a4
Jul 27 13:24:21 dnsmasq-dhcp[1225]: DHCPACK(br0) 192.168.50.47 f8:ac:65:00:fb:a4 DESKTOP-PVFEEUG
Jul 27 13:24:23 dnsmasq-dhcp[1225]: DHCPREQUEST(br0) 192.168.50.47 f8:ac:65:00:fb:a4
Jul 27 13:24:23 dnsmasq-dhcp[1225]: DHCPACK(br0) 192.168.50.47 f8:ac:65:00:fb:a4 DESKTOP-PVFEEUG
Jul 27 13:24:35 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth6: Deauth_ind F8:AC:65:00:FB:A4, status: 0, reason: Unspecified reason (1)
Jul 27 13:24:35 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth6: Disassoc F8:AC:65:00:FB:A4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul 27 13:24:44 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth5: Auth F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:24:44 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth5: Assoc F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:24:44 dnsmasq-dhcp[1225]: DHCPREQUEST(br0) 192.168.50.47 f8:ac:65:00:fb:a4
Jul 27 13:24:44 dnsmasq-dhcp[1225]: DHCPACK(br0) 192.168.50.47 f8:ac:65:00:fb:a4 DESKTOP-PVFEEUG
Jul 27 13:24:49 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind F8:AC:65:00:FB:A4, status: 0, reason: Unspecified reason (1)
Jul 27 13:24:49 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth5: Disassoc F8:AC:65:00:FB:A4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul 27 13:24:50 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth5: Auth F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:24:50 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth5: Assoc F8:AC:65:00:FB:A4, status: Successful (0)
Jul 27 13:24:50 dnsmasq-dhcp[1225]: DHCPREQUEST(br0) 192.168.50.47 f8:ac:65:00:fb:a4
Jul 27 13:24:50 dnsmasq-dhcp[1225]: DHCPACK(br0) 192.168.50.47 f8:ac:65:00:fb:a4 DESKTOP-PVFEEUG
Jul 27 13:24:53 dnsmasq-dhcp[1225]: DHCPREQUEST(br0) 192.168.50.47 f8:ac:65:00:fb:a4
Jul 27 13:24:53 dnsmasq-dhcp[1225]: DHCPACK(br0) 192.168.50.47 f8:ac:65:00:fb:a4 DESKTOP-PVFEEUG
Jul 27 13:25:01 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 48:60:5F:84:94:41, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jul 27 13:25:01 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth5: Disassoc 48:60:5F:84:94:41, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul 27 13:25:01 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth6: Auth 48:60:5F:84:94:41, status: Successful (0)
Jul 27 13:25:01 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth6: Assoc 48:60:5F:84:94:41, status: Successful (0)

 

[keefrto]

other thing is should i be even posting all this coding on here at all?

 

[OzarkEdge]

Does not appear to be any changes.

81858
wl0: Mar 4 2020 18:28:18 version 10.10.122.20 (r683106)

81918
wl0: Mar 4 2020 18:28:18 version 10.10.122.20 (r683106)

Thanks for that. One less thing to consider when I do upgrade from 81858, which is working ok and may be my last AiMesh 1.0 firmware.

OE

 

[OzarkEdge]

other thing is should i be even posting all this coding on here at all?

Posting log entries from the time of an event is appropriate.

"no wifi" suggests all of your wireless clients and wireless backhauls dropped across all WLANs. And that no signals were observed to be broadcasting. And that the wifi never recovered. Do you want to clarify any of that?

Are you running 81918, 30, or 92 on the 86Us? I'm back on 81858 as noted earlier in this 81992 thread.

WiFi dropping is not normal, so I'd expect to make a definite network change (firmware or hardware), if not a client-specific issue.

Given this incident was noticed for router wireless clients, and you have a second 86U, you could swap them to push suspect hardware, if any, to the lessor node role... to see if the issue moves with the device.

Absent more information, I'd be inclined to downgrade to 81858... but that may be premature advice for your issue(?).

OE

 

[keefrto]

Posting log entries from the time of an event is appropriate.

"no wifi" suggests all of your wireless clients and wireless backhauls dropped across all WLANs. And that no signals were observed to be broadcasting. And that the wifi never recovered. Do you want to clarify any of that?

Are you running 81918, 30, or 92 on the 86Us? I'm back on 81858 as noted earlier in this 81992 thread.

WiFi dropping is not normal, so I'd expect to make a definite network change (firmware or hardware), if not a client-specific issue.

Given this incident was noticed for router wireless clients, and you have a second 86U, you could swap them to push suspect hardware, if any, to the lessor node role... to see if the issue moves with the device.

Absent more information, I'd be inclined to downgrade to 81858... but that may be premature advice for your issue(?).

OE

I am running 81992 on both 86u and the 20632 on the 68u.
the wifi did recover after about 3 minutes
I would be happy to change to 1858 if its deemed that most folks are having somewhat similar if not the same issue. my wife works from home and cant afford issues with wifi mid zoom calls etc

 

[keefrto]

Posting log entries from the time of an event is appropriate.

"no wifi" suggests all of your wireless clients and wireless backhauls dropped across all WLANs. And that no signals were observed to be broadcasting. And that the wifi never recovered. Do you want to clarify any of that?

Are you running 81918, 30, or 92 on the 86Us? I'm back on 81858 as noted earlier in this 81992 thread.

WiFi dropping is not normal, so I'd expect to make a definite network change (firmware or hardware), if not a client-specific issue.

Given this incident was noticed for router wireless clients, and you have a second 86U, you could swap them to push suspect hardware, if any, to the lessor node role... to see if the issue moves with the device.

Absent more information, I'd be inclined to downgrade to 81858... but that may be premature advice for your issue(?).

OE

If i do downgrade I don't want to keep the same data before as i will bring the same problem with me correct? i can't recall the name of the rest i have to do but i think i get it

 

[keefrto]

am gonna go for the 81858, do a rest using method 2 i believe then manually upload the 58 firmware, then a reset again

 

[OzarkEdge]

am gonna go for the 81858, do a rest using method 2 i believe then manually upload the 58 firmware, then a reset again

That will do it. Button reset and webUI reset (restore) with Initialize are all I use.

Note that this downgrade will require a button reset at the login screen afterward since the login will not work correctly until you do a reset. I would then login and do another webUI reset with Initialize just to be sure you have purged old logged data.

Then configure from scratch. My install notes have the basic settings.

I can't comment on the current 68U firmware, so I guess stick with it.

OE

 

[keefrto]

It might have gone tits up, internet and my isp dchp error messages so am waiting to see when I just throw it against the wall if it works