What's new

ASUS RT-AC87U Firmware 3.0.0.4.380.3264

  • 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!

ankhazam

Senior Member
Release Note
ASUS has been dedicated to cooperate with third party developers to come up with more innovative features.
To comply with regulatory amendments, we have modified firmware verification rule to ensure better firmware quality.
This version is not compatible with all previously released ASUS firmware and uncertified third party firmware.

Security Fixed
- Fixed Samba Badlock CVE-2016-2110 (Man in the middle attacks possible with NTLMSSP)
- Fixed Samba Badlock CVE-2016-2111 (NETLOGON Spoofing Vulnerability)
- ASUS firmware did not enable Samba LDAP, and not affected by CVE-2016-2112 (LDAP client and server don't enforce integrity) issue.
- The Samba version in ASUS firmware was not affected by
CVE-2016-2118 (SAMR and LSA man in the middle attacks possible)
- The Samba version in ASUS firmware was not affected by
CVE-2015-5370 (Multiple errors in DCE-RPC code)
- Fixed command injection issue. Thanks for Chris' contribution.
- Fixed XSS issue. Thanks for Chris' contribution.

Bug Fixed
- Fixed Windows Radius server compatibility issues.
- Fixed 5G performance issue when using bandwidth monitor.
- Fixed bandwidth monitor incorrect number problem.
- Fixed setup wizard redirect issue when router automatically changed LAN IP in IP conflict case.
- Modified setup wizard process when router detected DHCP and PPPoE at the same time.
- Fixed bandwidth limiter bug when there are multiple clients in rule list.
- Fixed NTP automatically sync issue when router rebooted
- Fixed Safari slow response issue.
- Enhance AiCloud dynamic stream port mechanism (please also keep AiCloud app up to date)
- Fixed AiCloud share link related issues.
- Fixed Media Server/DLNA related issue.
Select "Other" OS to download from: http://www.asus.com/Networking/RTAC87U/HelpDesk_Download/


Do we have a daredevil who will flash it?
 
Hahaha, good question. I'll take the risk (But in a couple of hours because I'm with a lot of work right now and I need my connection up)
 
Last edited:
Well, it's now flashed. Did a hard reset and finished configuring it all.
So far no issues found but I need a couple of days to know how it really performs with my devices and Internet (it has adaptive QoS, Guest AP, priority devices selected too).

Also later I'll be checking signal strenght to see if that was reduced or only locked to what it was before

Sent from Tapatalk
 
Is the driver for the quantenna chip updated to?
Don't remember the one on previous version. This one is 37.4.0.56

check on yours before updating please
 
380.2695 - 37.4.0.56

378.9460 - 37.3.0.50
 
NTP Time synchronization bug is still present.
ntp.png


Fu....k Why asus cant fix this bug ? In RMerlin fw this bug is not exist.....
I lose many times with trying bugged fw......
i do factory default.
i do many reboot...sometimes time is synchronized correctly, but more time not.....
 
Last edited:
NTP Time synchronization bug is still present.
View attachment 6419

Fu....k Why asus cant fix this bug ? In RMerlin fw this bug is not exist.....
I lose many timest with trying bugged fw......
i do factory default.
i do many reboot...sometimes time is synchronized correctly, but more time not.....
Working for me... [emoji53] (Buenos Aires, Arg)

Sent from Tapatalk
 
next bug is that "fail back" not work....i connect wan (pppoe) but router is still on secondary WAN :(
this bug also exist in latest rmerlin fw

i found this
one reboot and time is ok
Code:
Aug  1 02:05:05 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Aug  1 02:05:05 wan: finish adding multi routes
Aug  1 02:05:05 dhcp client: bound 192.168.8.100 via 192.168.8.1 during 86400 seconds.
Aug  1 02:05:06 ntp: start NTP update
May 24 22:24:03 rc_service: ip-up 1590:notify_rc start_upnp

next reboot and time is not synchronized
Code:
Aug  1 02:00:38 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Aug  1 02:00:41 kernel: * Make sure sizeof(struct sw_struct)=160 is consistent
Aug  1 02:00:42 kernel: sizeof forward param = 160
Aug  1 02:00:44 rc_service: ip-up 501:notify_rc start_firewall
Aug  1 02:00:45 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Aug  1 02:00:54 qtn: bootcfg.tgz exists
 
Last edited:
Enabling IPv6 causes the UI to respond very slowly (2-3 min to log in and also select settings when you are in) in this version. Also enabling IPv6 causes the wireless log to report that the 5ghz band is not ready even though it is working.

Performance seems unaffected though. Just slow UI and glitchy wireless log.

If you turn off IPv6, everything returns to normal in terms of responsiveness of the UI and even the wireless log reports correctly in the 5ghz band.

Flashed it twice because I thought something went wrong the first time and also did a factory reset both times and enter settings manually. Update was applied through Ethernet so I think this is a bug.
 
Enabling IPv6 causes the UI to respond very slowly (2-3 min to log in and also select settings when you are in) in this version. Also enabling IPv6 causes the wireless log to report that the 5ghz band is not ready even though it is working.

Performance seems unaffected though. Just slow UI and glitchy wireless log.

If you turn off IPv6, everything returns to normal in terms of responsiveness of the UI and even the wireless log reports correctly in the 5ghz band.

Flashed it twice because I thought something went wrong the first time and also did a factory reset both times and enter settings manually. Update was applied through Ethernet so I think this is a bug.

I had the very same issues with 9_..._380_2998!!! Though I did not track it down to IPV6. After flashing the UI has simply gone (unresponsive) nuts and I was only able to reset it to default and flash back 380_2695.
 
i back to 9460 becouse with this two bug this fw is not usable for me.
 
Enabling IPv6 causes the UI to respond very slowly (2-3 min to log in and also select settings when you are in) in this version. Also enabling IPv6 causes the wireless log to report that the 5ghz band is not ready even though it is working.

Performance seems unaffected though. Just slow UI and glitchy wireless log.

If you turn off IPv6, everything returns to normal in terms of responsiveness of the UI and even the wireless log reports correctly in the 5ghz band.

Flashed it twice because I thought something went wrong the first time and also did a factory reset both times and enter settings manually. Update was applied through Ethernet so I think this is a bug.
Hi,
I had a same issue with the ipv6 service. When I turn it on the GUI works very slow and the 5Ghz wifi is not responding.
But when the ipv6 running and restart the router, turn off the wifi with the phisical button, on the booting time. And after when the router system already running turn on the wifi with the phisical button, and will everything works fine ipv6, 5Ghz and the GUI too.
I think the ipv6 services kill the wifi drivers or cannot start the wifi service on the same time.
 

Sign Up For SNBForums Daily Digest

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