ASUS RT-AC68U Firmware version 3.0.0.4.384.81049

[OzarkEdge]

i downgrade fw in my node to 81039 and will be observ. Now node work ok (on 45717 i was same issue like 81049)

Stations List                          
----------------------------------------
idx MAC               Associated Authorized    RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time
2C:xx:A1:xx:69:41 Yes        Yes         -61dBm ac  No  Yes Yes  No     3  192.5M    130M 04:10:35

now my node is Authorized

Ideally, someone from ASUS will take notice of this quirk and try to fix it; otherwise, it may continue in future releases.

OE

 

[bachastain]

wl0.1 Link encap:Ethernet HWaddr 18:31:BF:E141
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:41501 errors:0 dropped:0 overruns:0 frame:9540
TX packets:363605 errors:7 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6258505 (5.9 MiB) TX bytes:80178312 (76.4 MiB)

Interesting. According to what I can find, wl0.1 is Guest Network 1, which makes a lot more sense than an unused Ethernet port. I do have a guests defined on both 2.4 and 5. Now the byte counts make more sense.

However, that MAC address is on the node, and it was my understanding that the mesh nodes don't support guest access, so it's still confusing.

Bruce.

 

[sdmf74]

i downgrade fw in my node to 81039 and will be observ. Now node work ok (on 45717 i was same issue like 81049)

Stations List                          
----------------------------------------
idx MAC               Associated Authorized    RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time
2C:xx:A1:xx:69:41 Yes        Yes         -61dBm ac  No  Yes Yes  No     3  192.5M    130M 04:10:35

now my node is Authorized

Why would you downgrade your node to a defective firmware that Asus has pulled? Seems counter productive to me

 

[JGodfrey82]

I think maybe you misunderstand.. I upgraded to 81039 when it was first available on Asus update, once I realized it was bad I rolled back to 4117, Asus pulled 81039 the next day and then released 81049 as a supposed fix.. I updated to that and it sucks too.. I just rolled back again to 4117 and Asus still wants to push me the 81049 which is still problematic. Thanks

 

[Ronald Schwerer]

...Asus still wants to push me the 81049 which is still problematic.

Simply ignore the update until you find (from reading postings) they've got a release that works right.

 

[VANT]

Why would you downgrade your node to a defective firmware that Asus has pulled? Seems counter productive to me

simply. on this fw aimesh is rock solid for me. Both bands work ok on node without problems.
On node i not use httpd so no cpu spike.

 

[sdmf74]

I think maybe you misunderstand.. I upgraded to 81039 when it was first available on Asus update, once I realized it was bad I rolled back to 4117, Asus pulled 81039 the next day and then released 81049 as a supposed fix.. I updated to that and it sucks too.. I just rolled back again to 4117 and Asus still wants to push me the 81049 which is still problematic. Thanks

I dont believe I misunderstood anything, Im only going off of what I read, you said "i downgrade fw in my node to 81039 and will be observ. Now node work ok" so I simply wondered why you would downgrade to 81039
Also Im not sure where you are finding the 4117 firmware, I just checked all four of your routers & that firmware does not exist, unless its listed under something other than windows 10 OR you are attempting to say 45717 (which is pretty far off, all of your Asus' firmwares end in 5 digits)

BTW I jsut noticed that 2 different people are responding to me about 81039 (unless VANT is also jgodfrey82) & I believe one is saying that 81039 is stable with AImesh and that may be the case, it was stable for me too but there are many other things that can go wrong with firmware and the main issue with 81039 was that the gui was freezing & becoming 100% inacessable which is no bueno.

 

[Grisu]

I dont believe I misunderstood anything, Im only going off of what I read, you said "i downgrade fw in my node to 81039 and will be observ. Now node work ok" so I simply wondered why you would downgrade to 81039
Also Im not sure where you are finding the 4117 firmware, I just checked all four of your routers & that firmware does not exist, unless its listed under something other than windows 10 OR you are attempting to say 45717 (which is pretty far off, all of Asus' firmware ends in 5 digits)

BTW I jsut noticed that 2 different people are responding to me about 81039 (unless VANT is also jgodfrey82) & I believe one is saying that 81039 is stable with AImesh and that may be the case, it was stable for me too but there are many other things that can go wrong with firmware and the main issue with 81039 was that the gui was freezing & becoming 100% inacessable which is no bueno.

I see, they all use 5 digits, 384.6210: https://www.asus.com/me-en/Networking/RT-AX88U/HelpDesk_BIOS/
or 378.6975: https://www.snbforums.com/threads/asus-rt-ac68u-firmware-version-3-0-0-4-378-6975.25662/
380.7266: https://www.snbforums.com/threads/asus-rt-ac68u-firmware-version-3-0-0-4-380-7266.37510/
They start with fewer too and will count up to 99999, then they might change to 386 branch.

 

[JGodfrey82]

Yea sorry somehow I got tagged and replied in error to your reply to someone else. I had to downgrade my 3 68u AI setup back to the may fw release to quiet the syslog and get nodes stable.

 

[bachastain]

2 RT-AC66U B1s. 1 router and 1 mesh node running 81049. After 1 day of running, router started spitting log errors (previously posted) pointing to the node, so I warm booted the node and it's been running mostly smoothly ever since.

Router:
18:03:55 up 3 days, 9:39, load average: 0.00, 0.06, 0.05
Node:
17:52:28 up 2 days, 3:02, load average: 0.07, 0.05, 0.04

So far no instances of the node foreably disconnecting all clients at once. This may be the longest I've seen the mesh run in the last year without mass client disconnects.

Logs on both boxes are largely quiet right now. Every once in a while I get a burst of entries that seems to eventually fix itself. This morning I got page after page of these on the node:

Sep 9 08:17:28 syslog: WLCEVENTD wlceventd_proc_event(420): wl1.1: Auth 76A:38:94:F0:BE, status: 0, reason: d11 RC reserved (0)

Eventually it fixed itself.

Nothing changed from line to line other than the timestamp. I'm trying to track down the mac address 76A:38:94:F0:BE but the standard mac decoders don't have an entry for that. As best I can tell I don't have a device that matches that. Anyone have some idea what those might point to?

Bruce.

 

[sdmf74]

I see, they all use 5 digits, 384.6210: https://www.asus.com/me-en/Networking/RT-AX88U/HelpDesk_BIOS/
or 378.6975: https://www.snbforums.com/threads/asus-rt-ac68u-firmware-version-3-0-0-4-378-6975.25662/
380.7266: https://www.snbforums.com/threads/asus-rt-ac68u-firmware-version-3-0-0-4-380-7266.37510/
They start with fewer too and will count up to 99999, then they might change to 386 branch.

Well according to the links you referenced they do end in 5 digits , not that it matters. Maybe if you go back a little further say to before 2015 you will find some that prove me wrong. Better yet reference another routers firmware that he doesnt own
cause if you actually read my post you will see I wrote "I just checked all four of "your" routers". He doesnt own an RT-AX88U.

 

[Grisu]

Well according to the links you referenced they do end in 5 digits , not that it matters. Maybe if you go back a little further say to before 2015 you will find some that prove me wrong. Better yet reference another routers firmware that he doesnt own
cause if you actually read my post you will see I wrote "I just checked all four of "your" routers". He doesnt own an RT-AX88U.

You compare apples and oranges (I would natively say apples with pears)!
Do you really know what you are writing about?
Those 5 digits you marked bolded are the THREAD-ID in this forum and have nothing to do with Asus or their firmwares at all!
We are speaking about the digits just behind branch, actually 384.
or 378.6975: https://www.snbforums.com/threads/asus-rt-ac68u-firmware-version-3-0-0-4-378-6975.25662/
380.7266: https://www.snbforums.com/threads/asus-rt-ac68u-firmware-version-3-0-0-4-380-7266.37510/

You made a general statment that version numbering ends with 5 digits what is wrong, they can end with 5 but less too.
And with AX88 I gave you an example that recent firmwares may be shorter too.

 

[Good3alz]

This thread is titled " ASUS RT-AC68U Firmware version 3.0.0.4.384.81049 "

Comments related to this firmware version are also firmware versions:
45717
81039

There is no discussion of anything else.
I don't want to read others saying " 378.6975 " or " 380.7266 " is 4 digits not 5, as those versions are not to do with the recent firmware update that ASUS had to pull, and replace with 3.0.0.4.384.81049.

"Im not sure where you are finding the 4117 firmware" this comment is legit. There is an error on that topic. I don't know of a 4177 firmware version.
The comment to say, you made a mistake, perhaps you meant to say 45717 is also legit.

Everyone is right.
Let us please stay on topic.

 

[Good3alz]

Simply ignore the update until you find (from reading postings) they've got a release that works right.

I also remember reading some having issues with old firmware that didn't flush out if they did not erase nvram via telnet.
With this new 81049 firmware install, I erased in the UI & Telnet.. because I felt like it
Maybe this person you replied to should try to erase nvram using Telnet.

 

[Ronald Schwerer]

I also remember reading some having issues with old firmware that didn't flush out if they did not erase nvram via telnet.
With this new 81049 firmware install, I erased in the UI & Telnet.. because I felt like it
Maybe this person you replied to should try to erase nvram using Telnet.

You're reading too much into my comment. He was fretting about the notification (from ASUS) that newer firmware was available. I'm just saying to ignore the notification.

 

[sdmf74]

This thread is titled " ASUS RT-AC68U Firmware version 3.0.0.4.384.81049 "

Comments related to this firmware version are also firmware versions:
45717
81039

There is no discussion of anything else.
I don't want to read others saying " 378.6975 " or " 380.7266 " is 4 digits not 5, as those versions are not to do with the recent firmware update that ASUS had to pull, and replace with 3.0.0.4.384.81049.

"Im not sure where you are finding the 4117 firmware" this comment is legit. There is an error on that topic. I don't know of a 4177 firmware version.
The comment to say, you made a mistake, perhaps you meant to say 45717 is also legit.

Everyone is right.
Let us please stay on topic.

Thank You, I dont know why he got so anal about my comment & started linking firmware from a random router & versions that existed 5 years ago lol when I specifically said I was referring to only the firmwares of Vant's four routers.
Im just here to try to help members (albeit with less knowledge than some) and share my experiences so that others can more easily troubleshoot Asus' often buggy firmware (that never ever ends in anything other than 5 digits )

 

[sclift]

Not having much luck with 81049. I have two 68Us, a primary router and a repeater. Out of caution I installed 81049 only on the repeater. Initially it seemed nicely responsive, but would choke after running for a few hours. Tried reset-to-defaults and clearing the NVRAM with no improvement. Eventually the router got so messed up I had to use the rescue loader to revert it to 45717. Maybe the next revision will be better.

 

[Good3alz]

You're reading too much into my comment. He was fretting about the notification (from ASUS) that newer firmware was available. I'm just saying to ignore the notification.

Okies

Thank You, I dont know why he got so anal about my comment & started linking firmware from a random router & versions that existed 5 years ago lol when I specifically said I was referring to only the firmwares of Vant's four routers.
Im just here to try to help members (albeit with less knowledge than some) and share my experiences so that others can more easily troubleshoot Asus' often buggy firmware (that never ever ends in anything other than 5 digits )

Keep helping
Same with the other guy.. It just went a tad off topic was all IMHO.
I knew what you meant.

 

[bachastain]

2 RT-AC66U B1s. 1 router and 1 mesh node running 81049.

Logs on both boxes are largely quiet right now. Every once in a while I get a burst of entries that seems to eventually fix itself. This morning I got page after page of these on the node:

Sep 9 08:17:28 syslog: WLCEVENTD wlceventd_proc_event(420): wl1.1: Auth 76A:38:94:F0:BE, status: 0, reason: d11 RC reserved (0)

Eventually it fixed itself.

Nothing changed from line to line other than the timestamp. I'm trying to track down the mac address 76A:38:94:F0:BE but the standard mac decoders don't have an entry for that. As best I can tell I don't have a device that matches that. Anyone have some idea what those might point to?

Bruce.

2 RT-AC66U B1s. 1 router and 1 mesh node running 81049

Router:
up 6 days, 10:08
Node:
up 5 days, 3:44

Figured out what 76-da-38-94-f0-bd is that was caused lots of log messages. I have an Edimax wifi device that I'm using in Ethernet bridge mode to supply an Ethernet connection for an old Sony Bluray player. The player is only rarely used so I didn't notice the Edimax device somehow lost its configuration. Any mac that fits the pattern x6:xx:xx:xx:xx:xx is considered a private mac, explaining why I couldn't find 76-da-38-94-f0-bd in the mac decoders. I reset the Edimax and reconfigured it and it's working properly now.

So if I ignore all those log entries on the router and node, the rest of the logs are pretty clean.

So far 81049 is a hit in my home.

Bruce.

 

[eieio345]

My setup until 81049 was:

RT-AC86U (AiMesh router)
RT-AC68U (AiMesh node)

I updated both to 81039 and didn't notice any issues. Then 81049 was released. I performed the update like I always do: via the firmware upgrade section in the web UI. My RT-AC86U updated fine, but when I logged back in to the web UI, my 68U was nowhere to be seen. I looked at it and saw that the power light was rapidly flashing. I made several attempts at resetting it (e.g. holding reset while powering on; holding WPS while powering on, holding both reset and WPS while powering on, etc.) and none worked. My 68U seems to be bricked.