ASUS RT-AC87 Firmware - Official Releases

[raphaelogy]

what major bug have been fixed, all my apple products doesn't work on 5ghz.

but my apple devices are working just fine. I have an iPhone 6 and a macbook pro retina (2014) running 10.10.1 are doing better in this current firmware. There are still episodes of "pseudo-connections" when there is wifi connection but unable to utilise internet. Comparing to the past, the current latest firmware is much more compatible, but not flawless.

 

[tl2k2]

but my apple devices are working just fine. I have an iPhone 6 and a macbook pro retina (2014) running 10.10.1 are doing better in this current firmware. There are still episodes of "pseudo-connections" when there is wifi connection but unable to utilise internet. Comparing to the past, the current latest firmware is much more compatible, but not flawless.

if you look couple posts you will what i meant, i know this firmware getting better but still not stable enuogh as non beta firmware, just not mention the time setting bug. i like Asus the most out of all the brand of router out there but i don't like fan boy opinion.

My devices are iPhone 6 plus, iPad air 2 and retina mac pro first gen wifi N only and all of them have the connection issue.

 

[renderking]

I am getting this in the log over and over.


Jan 3 15:45:17 kernel: br0: received packet on vlan1 with own address as source address
Jan 3 15:45:17 kernel: br0: received packet on vlan1 with own address as source address
Jan 3 15:45:18 kernel: br0: received packet on vlan1 with own address as source address
Jan 3 15:45:19 kernel: br0: received packet on vlan1 with own address as source address
Jan 3 15:45:20 kernel: br0: received packet on vlan1 with own address as source address
Jan 3 15:45:21 kernel: br0: received packet on vlan1 with own address as source address
Jan 3 15:45:22 kernel: br0: received packet on vlan1 with own address as source address
Jan 3 15:45:23 kernel: br0: received packet on vlan1 with own address as source address

Jan 4 19:53:39 kernel: net_ratelimit: 37136 callbacks suppressed
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: net_ratelimit: 37020 callbacks suppressed
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 4 19:53:44 kernel: br0: received packet on vlan1 with own address as source address

Got them too. I disagree that these can be ignored, especially when syslog is suppressing blocks of 37k messages at a time. My router is running 8 days, and ping responses are starting to slow between PC and router. First CPU sits idle at approximately 9-14% utilization, while these messages continue to build.

 

[oric1]

For info (from ASUS@SG):

Dear all,

Our R&D work very hard and they even work on weekend just to fix Vlan issue and other bugs.

We are almost reach the point to release an unofficial beta firmware soon.

Currently testing on firmware Build: 3.0.*4.378

Best regard,
JK

http://forums.hardwarezone.com.sg/91134531-post1165.html

 

[arachnida]

Jan 4 19:53:39 kernel: net_ratelimit: 37136 callbacks suppressed
Jan 4 19:53:39 kernel: br0: received packet on vlan1 with own address as source address

Got them too. I disagree that these can be ignored, especially when syslog is suppressing blocks of 37k messages at a time. My router is running 8 days, and ping responses are starting to slow between PC and router. First CPU sits idle at approximately 9-14% utilization, while these messages continue to build.

I could not get this problem solved, tried many different FW incl. Merlin's FW. This WE I was able to swap both my AC87 for Netgear R7500 and guess what, all my problems are gone. No more storms of packets on the LAN, no more IP cams disconnecting from the recorder and SONOS works again like a charm. WIFI looks as good and as fast as with the ASUS on both 2.4 and 5 GHz, no problem with Apple devices. I liked the GUI of the ASUS more, especially with Merlin's FW, but this router works for me without any problems, also in AP mode.

I hope they solve the bad FW issues soon for you guys, but for me no more ASUS. I believe ASUS was pushed by the market and competition to release an unfinished product with beta FW. My router kind of worked in normal mode, however AP mode was a disaster.

 

[Jan2014]

With new 3754 I suddenly get tons of these errors in the log file:

Jan 5 11:07:16 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:08:11 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:09:04 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:09:57 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:10:49 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:11:40 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:12:32 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:12:34 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:13:24 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:14:16 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:14:18 miniupnpd[785]: sendto(udp): Operation not permitted
Jan 5 11:16:55 miniupnpd[785]: sendto(udp): Operation not permitted

MiniDNLA is working though, still does take up to 5min before it is recognized by clients and needs manual triggering for rescan, but overall it works.

Does anyone experience same errors in log?
Cheers Jan

 

[john9527]

With new 3754 I suddenly get tons of these errors in the log file:

Jan 5 11:07:16 miniupnpd[785]: sendto(udp): Operation not permitted
...
MiniDNLA is working though, still does take up to 5min before it is recognized by clients and needs manual triggering for rescan, but overall it works.

Does anyone experience same errors in log?
Cheers Jan

Are you running Plex Media Server?

That looks like an old issue with PMS that was fixed in miniupnpd a while ago. Maybe they accidently picked up an old miniupnpd release?

If you are running Plex, you can try to disable it's DLNA server as a workaround.

 

[Ronv42]

If you run a "detailed network statistics" on your Xbox One. Are you getting the download speeds that your ISP provides through wireless?

Yes I do get my speeds but I am using wired for my Xbox One.

 

[renderking]

I could not get this problem solved, tried many different FW incl. Merlin's FW. This WE I was able to swap both my AC87 for Netgear R7500 and guess what, all my problems are gone. No more storms of packets on the LAN, no more IP cams disconnecting from the recorder and SONOS works again like a charm. WIFI looks as good and as fast as with the ASUS on both 2.4 and 5 GHz, no problem with Apple devices. I liked the GUI of the ASUS more, especially with Merlin's FW, but this router works for me without any problems, also in AP mode.

I hope they solve the bad FW issues soon for you guys, but for me no more ASUS. I believe ASUS was pushed by the market and competition to release an unfinished product with beta FW. My router kind of worked in normal mode, however AP mode was a disaster.

In last 12 hours, Core1 now idles at 18-22% (from 9-14%) and frequency of messages continue to increase. Pretty close to dumping these too until the firmware matures. If ASUS is listening.. I'm willing to give you any/all logs you need to help solve.

Jan 5 07:32:11 kernel: br0: received packet on vlan1 with own address as source address
Jan 5 07:32:11 kernel: br0: received packet on vlan1 with own address as source address
Jan 5 07:32:16 kernel: net_ratelimit: 49428 callbacks suppressed

 

[RMerlin]

Are you running Plex Media Server?

That looks like an old issue with PMS that was fixed in miniupnpd a while ago. Maybe they accidently picked up an old miniupnpd release?

If you are running Plex, you can try to disable it's DLNA server as a workaround.

Asus is still using the years old miniupnpd 1.4.

 

[BobF]

Eh? If you go to

http://www.asus.com/us/Networking/RTAC87U/HelpDesk_Download/

it clearly lists the 3754 as the latest fw.

Found I had been going to an old north american Asus site. Thank you very much for your help.

 

[vaszago]

Asus is still using the years old miniupnpd 1.4.

@ Merlin maybe they can point ASUS miniupnpd times to update. That would certainly solve some problems.

 

[StormEffect]

Found I had been going to an old north american Asus site. Thank you very much for your help.

You are still correct though. The official ASUS support pages for both the U and R variants are not updated. Only the specific product page linked above has the new firmware.

 

[Jan2014]

Are you running Plex Media Server?

That looks like an old issue with PMS that was fixed in miniupnpd a while ago. Maybe they accidently picked up an old miniupnpd release?

If you are running Plex, you can try to disable it's DLNA server as a workaround.

Thanks for pointing me to the right direction! I am not running a Plex server but errors were obviously caused by a Raspberry Pi running OpenELEC. Will upgrade the Raspi to latest version 5.0 Kodi and hope this solves the issue. I could swear this error hasn't occurred in any of the older FWs (tried all betas since 2769). Anyways, a more up-to-date version of miniupnpd would certainly be highly appreciated by many folks...

 

[renderking]

Network crashed again with the following error:

kernel: br0: received packet on vlan1 with own address as source address.

If I didn't mention already, I have (2) RT-AC87's on the network. Maybe that's why other's aren't experiencing similar broadcast storms that I am. One is in router mode and the other in AP mode. I never lost remote access to the primary, and everything directly plugged into it was accessible. 2nd AP is plugged in further downstream, into a switch that sits between the primary and AP. Interestingly, it seemed that once the AP was rebooted, the issues appeared to resolve on the network. I'm going to remove it from the equation temporarily to see if that's the smoking gun.

Just thinking out loud, in-case I spark a thought in someone else's head that could shed a brighter light.

 

[scavenger]

One is in router mode and the other in AP mode.

I think by now this should qualify as a "known issue." Though if ASUS doesn't know about it, they should. If you look through this thread, and the firmware bugs thread, you'll see that you are not alone.

I think everyone running a second AC87 in AP mode is bitten by this.

My single AC87 router has been okay, but IMHO that bleeding-edge Quantenna chip, the cobbled-together architecture, and drivers that don't know what to do with either of them is just too much of a prototype to be admired.

 

[dfran1]

Ok,
First, this and the past 2 or 3 months or so (and maybe more) firmwares have been horrible with 5GHz, totally going backwards, I have now put every device on the 2.4GHz band, hoping someday Asus will get it right.

I have flushed the router and all, and when my wife complains about connection problems I know this firmware is garbage!!!!

If you think you get good results then you are not using it (and I mean using, or whatever)!!

Now the good (has noting to do with Asus though, but maybe it does?)
I changed my DNS on my PS4 (not in the router) and my lag has really gone away (besides a reboot of the router every day or 2).
Here is the DNS link

Here are ports, but I do not use them, just for reference

I do not mean to make anyone mad, but this 5GHz on this router is just garbage, I know I have said lots of good things in the past, but when my wife, that NEVER complains about wifi, and now does, makes me realize this routers 5GHz is garbage.

The older firmware (first 2 or?) were better, these new ones just hit an all time low.

I certainly hope Asus makes good on the next firmware they release.

Sorry to make anyone mad!!

edit: What is mean about the 5GHz, problems occur after a day or so.

 

[renderking]

I think by now this should qualify as a "known issue." Though if ASUS doesn't know about it, they should.

Does anyone know if ASUS actually post known firmware issues? If so where? All I ever see is a list of supposedly fixed issues under the firmware downloads. Everything else is learned from parsing forums.

Phone support is a waste of time, with a standard response "we will escalate to our engineers", and no way to track.

 

[richdbenson]

3754 Firmware update

I have installed _3754 firmware upgrade and my setup with R87 main and R87 Access point are now stable. Up until this update, the main would crash on my network. This does not appear to be related to the VLAN 1 message issue as I'm still getting those.

 

[CorruptedMind]

Anyone having issues with Plex Media Server or VPN? Issue seems to be with UPNP??

Cannot connect to Plex Media Server "externally." I simply cannot connect to my WAN IP. I've tried port forwarding as well. Anyone else having this problem or have any advice? The computer that is running the Plex Media server also has Static IP.

Also I am having struggles with connecting to VPN PPTP when enabled. Followed directions correctly but computer cannot connect to WAN IP as well. I am using the latest firmware 3754.

I figure these two problems are related with UPNP?

This is my system log...

Jan 6 20:10:29 wan: finish adding multi routes
Jan 6 20:10:29 rc_service: udhcpc 12825:notify_rc stop_upnp
Jan 6 20:10:29 rc_service: udhcpc 12825:notify_rc start_upnp
Jan 6 20:10:29 rc_service: waitting "stop_upnp" via udhcpc ...
Jan 6 20:10:29 miniupnpd[8840]: received signal 15, good-bye
Jan 6 20:10:30 dhcp client: bound 71.195.214.103 via 71.195.212.1 during 198697 seconds.
Jan 6 19:10:30 ntp: start NTP update
Jan 6 20:10:37 rc_service: httpd 9016:notify_rc restart_wan_if 0
Jan 6 20:10:39 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan2_vlan2)!
Jan 6 20:10:40 wan: finish adding multi routes
Jan 6 20:10:40 rc_service: udhcpc 12873:notify_rc stop_upnp
Jan 6 20:10:40 rc_service: udhcpc 12873:notify_rc start_upnp
Jan 6 20:10:40 rc_service: waitting "stop_upnp" via udhcpc ...


Also my system log is flooded with this.. I assume its me trying to connect multiple times.

Jan 6 19:05:19 miniupnpd[8840]: sendto(udp): Operation not permitted
Jan 6 19:06:14 miniupnpd[8840]: sendto(udp): Operation not permitted
Jan 6 19:14:19 miniupnpd[8840]: sendto(udp): Operation not permitted
Jan 6 19:19:42 miniupnpd[8840]: sendto(udp): Operation not permitted
Jan 6 19:20:27 miniupnpd[8840]: sendto(udp): Operation not permitted
Jan 6 19:21:31 miniupnpd[8840]: sendto(udp): Operation not permitted
Jan 6 19:23:19 miniupnpd[8840]: sendto(udp): Operation not permitted