Menu
What's new
By:
Filters Better Search

AC86U RT Firmware 3.0.0.4.384.81918

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

OgUrecheK said:
I have such spam appeared:
Code: 
May 28 17:14:28 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
May 28 17:14:28 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
May 28 17:14:29 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
...

May 28 17:24:42 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
May 28 17:24:52 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
May 28 17:27:03 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
Click to expand...
Simple, if things in the log bother you, don't look at the log. If the router works just leave it alone!
 
OgUrecheK said:
I have such spam appeared:
Code: 
May 28 17:14:28 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
May 28 17:14:28 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
May 28 17:14:29 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
...

May 28 17:24:42 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
May 28 17:24:52 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
May 28 17:27:03 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)
Click to expand...

Not seeing that here... log is quiet except for normal associate/disassociate stuff. I'm using SC with fixed channels, not Auto.

OE
 
passed the 24 hour mark on this update and no problems whatsoever. it's just as stable as the last one, i miss the good old days when updates broke things :D:D:D:D
 
Same here, working fine, boring! Can I have at least a customizeable interface, dark mode? Well, it could be done, no?
 
tallytr said:
Why would one want to use all these features? Up/Down meter?
In my case I ignore everything. All I need/want is for the clients to have a stable connection to the internet :)
Click to expand...

Dude, I was being sarcastic. Yes, i also want a stable no BS firmware that i dont have to mess with all the time.
 
What is optimal logging level?
Code: 
0 - Emergency
1 - Alerts
2 - Critical
3 - Errors
4 - Warnings
5 - Notification
6 - Information
7 - Debug (debug)
 
cco12 said:
does they fix WIFI 2.4G ping time increase?
Click to expand...

i've been testing this out. the results are very inconsistent.

these are the results of two different android phones on the 2.4 range

PING 192.168.1.96 (192.168.1.96): 56 data bytes
64 bytes from 192.168.1.96: seq=0 ttl=64 time=20.636 ms
64 bytes from 192.168.1.96: seq=1 ttl=64 time=1.293 ms
64 bytes from 192.168.1.96: seq=2 ttl=64 time=1.500 ms
64 bytes from 192.168.1.96: seq=3 ttl=64 time=1.796 ms
64 bytes from 192.168.1.96: seq=4 ttl=64 time=2.801 ms
64 bytes from 192.168.1.96: seq=5 ttl=64 time=1.701 ms
64 bytes from 192.168.1.96: seq=6 ttl=64 time=1.354 ms
64 bytes from 192.168.1.96: seq=7 ttl=64 time=1.418 ms
64 bytes from 192.168.1.96: seq=8 ttl=64 time=1.995 ms
64 bytes from 192.168.1.96: seq=9 ttl=64 time=2.475 ms
--- 192.168.1.96 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 1.293/3.696/20.636 ms

PING 192.168.1.99 (192.168.1.99): 56 data bytes
64 bytes from 192.168.1.99: seq=0 ttl=64 time=513.883 ms
64 bytes from 192.168.1.99: seq=1 ttl=64 time=357.053 ms
64 bytes from 192.168.1.99: seq=2 ttl=64 time=369.030 ms
64 bytes from 192.168.1.99: seq=3 ttl=64 time=333.640 ms
64 bytes from 192.168.1.99: seq=4 ttl=64 time=246.715 ms
64 bytes from 192.168.1.99: seq=5 ttl=64 time=169.512 ms
64 bytes from 192.168.1.99: seq=6 ttl=64 time=69.837 ms
64 bytes from 192.168.1.99: seq=7 ttl=64 time=277.423 ms
64 bytes from 192.168.1.99: seq=8 ttl=64 time=179.613 ms
64 bytes from 192.168.1.99: seq=9 ttl=64 time=59.873 ms
--- 192.168.1.99 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 59.873/257.657/513.883 ms

both connected to the main router. on the 5Ghz range pings are very stable.

edit: the phone with the ip 192.168.1.99 had better results when its not in sleep state


PING 192.168.1.99 (192.168.1.99): 56 data bytes
64 bytes from 192.168.1.99: seq=0 ttl=64 time=59.254 ms
64 bytes from 192.168.1.99: seq=1 ttl=64 time=59.160 ms
64 bytes from 192.168.1.99: seq=2 ttl=64 time=75.709 ms
64 bytes from 192.168.1.99: seq=3 ttl=64 time=2.039 ms
64 bytes from 192.168.1.99: seq=4 ttl=64 time=90.292 ms
64 bytes from 192.168.1.99: seq=5 ttl=64 time=55.554 ms
64 bytes from 192.168.1.99: seq=6 ttl=64 time=109.160 ms
64 bytes from 192.168.1.99: seq=7 ttl=64 time=20.560 ms
64 bytes from 192.168.1.99: seq=8 ttl=64 time=34.912 ms
64 bytes from 192.168.1.99: seq=9 ttl=64 time=40.293 ms
--- 192.168.1.99 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 2.039/54.693/109.160 ms

still high though.
 
Last edited:
Im using ethernet try this and report back if its only wifi. My ping spikes are smaller after bug-fix release before it was unusable after some time.
 
bitsbytes said:
i've been testing this out. the results are very inconsistent.

these are the results of two different android phones on the 2.4 range

PING 192.168.1.96 (192.168.1.96): 56 data bytes
64 bytes from 192.168.1.96: seq=0 ttl=64 time=20.636 ms
64 bytes from 192.168.1.96: seq=1 ttl=64 time=1.293 ms
64 bytes from 192.168.1.96: seq=2 ttl=64 time=1.500 ms
64 bytes from 192.168.1.96: seq=3 ttl=64 time=1.796 ms
64 bytes from 192.168.1.96: seq=4 ttl=64 time=2.801 ms
64 bytes from 192.168.1.96: seq=5 ttl=64 time=1.701 ms
64 bytes from 192.168.1.96: seq=6 ttl=64 time=1.354 ms
64 bytes from 192.168.1.96: seq=7 ttl=64 time=1.418 ms
64 bytes from 192.168.1.96: seq=8 ttl=64 time=1.995 ms
64 bytes from 192.168.1.96: seq=9 ttl=64 time=2.475 ms
--- 192.168.1.96 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 1.293/3.696/20.636 ms

PING 192.168.1.99 (192.168.1.99): 56 data bytes
64 bytes from 192.168.1.99: seq=0 ttl=64 time=513.883 ms
64 bytes from 192.168.1.99: seq=1 ttl=64 time=357.053 ms
64 bytes from 192.168.1.99: seq=2 ttl=64 time=369.030 ms
64 bytes from 192.168.1.99: seq=3 ttl=64 time=333.640 ms
64 bytes from 192.168.1.99: seq=4 ttl=64 time=246.715 ms
64 bytes from 192.168.1.99: seq=5 ttl=64 time=169.512 ms
64 bytes from 192.168.1.99: seq=6 ttl=64 time=69.837 ms
64 bytes from 192.168.1.99: seq=7 ttl=64 time=277.423 ms
64 bytes from 192.168.1.99: seq=8 ttl=64 time=179.613 ms
64 bytes from 192.168.1.99: seq=9 ttl=64 time=59.873 ms
--- 192.168.1.99 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 59.873/257.657/513.883 ms

both connected to the main router. on the 5Ghz range pings are very stable.

edit: the phone with the ip 192.168.1.99 had better results when its not in sleep state


PING 192.168.1.99 (192.168.1.99): 56 data bytes
64 bytes from 192.168.1.99: seq=0 ttl=64 time=59.254 ms
64 bytes from 192.168.1.99: seq=1 ttl=64 time=59.160 ms
64 bytes from 192.168.1.99: seq=2 ttl=64 time=75.709 ms
64 bytes from 192.168.1.99: seq=3 ttl=64 time=2.039 ms
64 bytes from 192.168.1.99: seq=4 ttl=64 time=90.292 ms
64 bytes from 192.168.1.99: seq=5 ttl=64 time=55.554 ms
64 bytes from 192.168.1.99: seq=6 ttl=64 time=109.160 ms
64 bytes from 192.168.1.99: seq=7 ttl=64 time=20.560 ms
64 bytes from 192.168.1.99: seq=8 ttl=64 time=34.912 ms
64 bytes from 192.168.1.99: seq=9 ttl=64 time=40.293 ms
--- 192.168.1.99 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 2.039/54.693/109.160 ms

still high though.
Click to expand...
Why are you pinging a client from a client? Really proves nothing other than the clients are busy doing something else. WIFI works differently than Ethernet (WIFI works to avoid collisions thus the inconsistent results. An Ethernet switch eliminates the collision detection and gives greater thruput). You would be better off pinging the router from the client and you still may get inconsistent results on WIFI.
 
ryan806 said:
Is there any harm in updating the firmware over wifi if using the GUI firmware upgrade?
Click to expand...

It's doable, but WiFi can be much less predictable/stable than a wired connection, and since flashing firmware is a critical operation not to be disturbed, I prefer to always use a wired connection and a UPS for steady power, which has always yielded the best results.

OE
 
asus.jpg

AC86U Firmware Version : 3.0.0.4.384_81918

WIFI 2.4G when test speed on https://www.speedtest.net/

Still have WIFI 2.4G [ Ping time increase.... ]

normal use sometime ping time increase to 200-300 ms.
 
And what's your point?

Sent from my SM-G955F using Tapatalk
 
OzarkEdge said:
It's doable, but WiFi can be much less predictable/stable than a wired connection, and since flashing firmware is a critical operation not to be disturbed, I prefer to always use a wired connection and a UPS for steady power, which has always yielded the best results.

OE
Click to expand...
I always use a wired connection when flashing firmware, and normally download the file and flash it manually. However today i tried updating by having the router download and flash it, noticed its much slower. Think i'll stick to manually flashing it lol.
 
I routinely apply manual updates over wifi. I've never had one go bad.
 
maxbraketorque said:
I routinely apply manual updates over wifi. I've never had one go bad.
Click to expand...

It is not possible to brick this router when using gui method of updating firmware. There is some security mechanism that will restore previous firmware if there is bad flash from what i remember.

Also those ping spikes are interesting you should investigate it more guys !
 
You must log in or register to reply here.

Similar threads

L
Release ASUS RT-AC86U Firmware version 3.0.0.4.386_51925 (2024/03/29)
Replies
10
Views
1K
VANT
VANT
M
RT-AC86U -> RT-AX86U Pro Review
Replies
17
Views
1K
Rossmon
R
D
Asus Aimesh vs AP mode (channels interference)
Replies
12
Views
1K
Tech9
Tech9
D
RT-AC86U no Quick Internet Setup wizard and fails as AI-Mesh node
Replies
9
Views
528
ColinTaylor
C
Wobbo
RT-AC86U LED Management Issue After Reboot (Firmware 386.12_4)
Replies
14
Views
1K
RMerlin
RMerlin
Similar threads
Thread starter Title Forum Replies Date
L Release ASUS RT-AC86U Firmware version 3.0.0.4.386_51925 (2024/03/29) ASUSWRT - Official 10
L Release ASUS RT-AC86U Firmware version 3.0.0.4.386_51915 (2023/07/10) ASUSWRT - Official 15
jixiangyuan ASUS GT-BE98 Firmware version 3.0.0.6.102_34372 - 2024/04/23 ASUSWRT - Official 5
bbunge Release ASUS RT-AC66U B1 Firmware version 3.0.0.4.386_51685 2024/04/15 ASUSWRT - Official 3
Intrepid Release ASUS RT-AC68U Firmware version 3.0.0.4.386_51685 (2024/04/15) ASUSWRT - Official 14
P ASUS RT-AX58 - Firmware version 3.0.0.4.388.24762 ASUSWRT - Official 8
PR3MIUM Release ASUS GT-BE25000 Firmware version 3.0.0.6.102_33570 ASUSWRT - Official 1
U Aimesh speeds slower with new AX11000 pro firmware ASUSWRT - Official 0
R Is Asus RT AX3000 v2 going to receive a firmware update? ASUSWRT - Official 15
G XD4 firmware update - still supported ASUSWRT - Official 3

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Total: 612 (members: 9, guests: 603)
Top