ASUS RT-AC87 Firmware - Official Releases

[8undy]

Steps to set up 2nd router in router to router config instead of AP mode

1) Turn off wireless radio on first router using button on front (this makes it easier to access only 2nd router)
2) Turn on 2nd router and access setup via wireless on 2nd router
3) Skip easy setup
4) Setup wireless radio (it will suggest doing this)
5) Keep 2nd router hooked up to WAN port (if it establishes a subnet of 192.168.2.1 then that is ok)
6) Go to LAN tab and disable DHCP, Setup up 192.168.1.1 as the DNS server and WINS server, Set up 192.168.2.1 as the 2nd router IP address.
7) Enable Static Routes (on Routes subtab)
8) Create a Static Route to 192.168.1.1 via LAN
9) Set Enable WAN, Enable NAT, Enable uPNP to "No"
10) Remove cable from WAN port on 2nd router and plug into LAN port

I'll repost if this setup has any issues with uptime. Based on prior posts, setting up router/router config should allow users to get around the Access Point preconfigured ASUS issues.

Also, there is a bug in setup on the admin tab. You have to set your system time to GMT and then save, after that you can move to your US time zone. The bug is that if you move from default mountain time that DST is not populated in the fields and system will error.

Excellent explanation! Thx for the info about the bug on the admin tab. My routers are currently set to GMT and since I don't really care about the time settings I'm going to leave it alone as everything is functioning flawlessly so far.

 

[richdbenson]

Excellent explanation! Thx for the info about the bug on the admin tab. My routers are currently set to GMT and since I don't really care about the time settings I'm going to leave it alone as everything is functioning flawlessly so far.

One more note, I did end up disabling the NAT accelerator on the Switch subtab/LAN tab on both routers. Once I did that I have been getting the best AC performance yet. I am getting 855.5 on my Surface Pro 3 in close proximaty to the 2nd router. I have never gotten than. Screen transitions are amazingly fast. I don't think my network has ever run this fast, noticeably faster than prior.

 

[richdbenson]

Excellent explanation! Thx for the info about the bug on the admin tab. My routers are currently set to GMT and since I don't really care about the time settings I'm going to leave it alone as everything is functioning flawlessly so far.

There is a typo in instruction 6. It should read as shown just below.

6) Go to LAN tab and disable DHCP, Setup up 192.168.1.1 as the DNS server and WINS server, Set up 192.168.1.2 as the 2nd router IP address.

 

[mromero]

Here is the print out of my temps using the commands Merlin posted in another thread.

Ambient temperature is a balmy 81F.

Using the supermarket wire rack passive cooling system solution I posted about in a separate thread. Must have got one of the good modems or the thermal tape has not failed yet

For some reason the modem reports the date wrong:

ASUSWRT RT-AC87U_3.0.0.4 Mon Jan 12 03:10:08 UTC 2015
qcsapi_sockrpc get_temperature
temperature_rfic_external = 0.0
temperature_rfic_internal = 62.4
temperature_bbic_internal = 75.0

cat /proc/dmu/temperature
CPU temperature : 76øC

What kind of SOC provider develops products without including thermal information in their datasheets? I find that a bit mind boggling if truly QTN can't provide that critical information to their customers, and they end up having to conduct their own experiments.

QTN isn't exactly a new player in this market despite what users think. From what I've seen, they've been developping business solutions for a few years already. Their QSR1000 just happens to be the first product aimed at the SOHO/home market. So that makes this situation even more surprising to me.

My QTN SOC currently runs at 79C here, but the living room is a bit cool at the moment (reduced heating since I'm not in that room). It reaches 83-84C once the room is up to its normal temperature.

Not surprised at Qualcomm having a better power budget than Broadcom. Qualcomm has pushed the envelope a lot over the years, as they are popular products in smartphones.

 

[scavenger]

I must be one of the lucky ones. I do have a powered laptop cooler under it, but I've never seen rfic temps above 50C. What I'm at now with multiple 5GHz streams hitting it:

# cat /proc/dmu/temperature
CPU temperature : 57øC

# qcsapi_sockrpc get_temperature
temperature_rfic_external = 0.0
temperature_rfic_internal = 48.0
temperature_bbic_internal = 55.0

BTW, rfic = radio frequency IC; bbic = baseband IC
http://mipi.org/working-groups/digrfsm-working-group

 

[mromero]

Ambient temp?

But I believe that would be negated by using a laptop cooler?

I must be one of the lucky ones. I do have a powered laptop cooler under it, but I've never seen rfic temps above 50C. What I'm at now with multiple 5GHz streams hitting it:

# cat /proc/dmu/temperature
CPU temperature : 57øC

# qcsapi_sockrpc get_temperature
temperature_rfic_external = 0.0
temperature_rfic_internal = 48.0
temperature_bbic_internal = 55.0

BTW, rfic = radio frequency IC; bbic = baseband IC
http://mipi.org/working-groups/digrfsm-working-group

 

[richdbenson]

There is a typo in instruction 6. It should read as shown just below.

6) Go to LAN tab and disable DHCP, Setup up 192.168.1.1 as the DNS server and WINS server, Set up 192.168.1.2 as the 2nd router IP address.

This AP issue has got to be some kind of firmware issue. These messages brought my main router down again.....I'll be calling ASUS monday morning.

Thinking about sending them a bill for my time at this point.

Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 ntp: start NTP update
Jan 17 18:39:02 kernel: net_ratelimit: 540213 callbacks suppressed
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: net_ratelimit: 540160 callbacks suppressed
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address

 

[jmantn]

Steps to set up 2nd router in router to router config instead of AP mode

1) Turn off wireless radio on first router using button on front (this makes it easier to access only 2nd router)
2) Turn on 2nd router and access setup via wireless on 2nd router
3) Skip easy setup
4) Setup wireless radio (it will suggest doing this)
5) Keep 2nd router hooked up to WAN port (if it establishes a subnet of 192.168.2.1 then that is ok)
6) Go to LAN tab and disable DHCP, Setup up 192.168.1.1 as the DNS server and WINS server, Set up 192.168.1.2 as the 2nd router IP address.
7) Enable Static Routes (on Routes subtab)
8) Create a Static Route to 192.168.1.1 via LAN
9) Set Enable WAN, Enable NAT, Enable uPNP to "No"
10) Remove cable from WAN port on 2nd router and plug into LAN port

I'll repost if this setup has any issues with uptime. Based on prior posts, setting up router/router config should allow users to get around the Access Point preconfigured ASUS issues.

Also, there is a bug in setup on the admin tab. You have to set your system time to GMT and then save, after that you can move to your US time zone. The bug is that if you move from default mountain time that DST is not populated in the fields and system will error.

This AP issue where it's killing some people's LAN could very well be the issue I've ran into however I'm wondering if it could take a few weeks for the AP bug to kick in if so that's the issue I've been experiencing.

 

[jmantn]

This AP issue has got to be some kind of firmware issue. These messages brought my main router down again.....I'll be calling ASUS monday morning.

Thinking about sending them a bill for my time at this point.

Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:38:57 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 ntp: start NTP update
Jan 17 18:39:02 kernel: net_ratelimit: 540213 callbacks suppressed
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:02 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: net_ratelimit: 540160 callbacks suppressed
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address
Jan 17 18:39:07 kernel: br0: received packet on vlan1 with own address as source address

Is it confirmed the vlan1 error brings the network down or to a crawl?

 

[Richard1864]

We finally heard back from Quantenna. Max bbic = 95° C. Max rfic = 90° C. Surprised it can't take higher temps. ASUS advised to use thermal paste not tape for heat sink, PCIe not RGMII, include 40 mm fan of not using thermal paste. Wonder why they didn't follow those recommendations?

 

[scavenger]

We finally heard back from Quantenna. Max bbic = 95° C. Max rfic = 90° C. Surprised it can't take higher temps. ASUS advised to use thermal paste not tape for heat sink, PCIe not RGMII, include 40 mm fan of not using thermal paste. Wonder why they didn't follow those recommendations?

Well, they are the first MU-MIMO SOHO router on the market by months, so take that into account. It's not a very considered architecture, the Quantenna stuff is almost like a parody of a kludge, like a 'bag hanging off the side' of the router (cf. "Soul of a New Machine").

First-to-market pressure?

//sorry, veering off-topic. Truth is, the firmware has been solid for me so I shouldn't be one to complain too loudly.

 

[mromero]

Has anyone taken a number of these units apart to ascertain which are using tape or paste?

Pictures?

Class action suit?

We finally heard back from Quantenna. Max bbic = 95° C. Max rfic = 90° C. Surprised it can't take higher temps. ASUS advised to use thermal paste not tape for heat sink, PCIe not RGMII, include 40 mm fan of not using thermal paste. Wonder why they didn't follow those recommendations?

 

[renderking]

This AP issue where it's killing some people's LAN could very well be the issue I've ran into however I'm wondering if it could take a few weeks for the AP bug to kick in if so that's the issue I've been experiencing.

Mine first started appearing within the first hour when the AP was online, then progressively got worse till the network was completely down with a red hot router. Usually 3-4 days into it.

Is it confirmed the vlan1 error brings the network down or to a crawl?

It progresses to a complete outage over the course of a few days. You'll slowly start to experience packet loss between LAN devices, which to the average user will translate to 'slow internet'. But in reality, your main router is processing so many vlan error messages, it can't handle normal traffic.

Unhooking the AP from the network solved my issue. Up time of 7+ days with barely a log entry in the main router. My 2nd AP is still hanging on the wall waiting for a stable firmware.

 

[jmantn]

Was afraid of that...

 

[RMerlin]

We finally heard back from Quantenna. Max bbic = 95° C. Max rfic = 90° C. Surprised it can't take higher temps. ASUS advised to use thermal paste not tape for heat sink, PCIe not RGMII, include 40 mm fan of not using thermal paste. Wonder why they didn't follow those recommendations?

Those max temperature are pretty low, considering how easy it is to get dangerously close to them in a basic design. It's good we finally have some actual numbers, might explain why there's such a thin line between those of us with a perfectly stable router, and others who are having more serious stability issues. Mine never got above 85C as far as I can remember.

I suspect the RGMII design was for cost/simplicity at the time when working with a BCM environment.

Switching the thermal tape with actual thermal paste is something that could be resolved with a new HW revision at least. In theory so could the addition of a fan (Asuswrt even has code already to handle fan control, an artifact from the revision A RT-N66U), tho that kind of change might require re-certification and releasing it under a new SKU, as for some people having a fan in there would be unacceptable (like myself - I want my router to be 100% quiet).

 

[dfran1]

Has anyone taken a number of these units apart to ascertain which are using tape or paste?

Pictures?

Class action suit?

The only ones who benefit from a class action are the lawyers, don't even think for a moment you would at all!!!

I have seen many thru the years and we the people NEVER GET any benefit that is anything worth it (there MIGHT be a very few that are good but not many at all).

Matter in fact I received a letter from one last month and I had to contact them to receive a whapping $15. I threw it out!

Don't even get me into the scam lawyers from injury.

Those max temperature are pretty low, considering how easy it is to get dangerously close to them in a basic design. It's good we finally have some actual numbers, might explain why there's such a thin line between those of us with a perfectly stable router, and others who are having more serious stability issues. Mine never got above 85C as far as I can remember.

I suspect the RGMII design was for cost/simplicity at the time when working with a BCM environment.

Switching the thermal tape with actual thermal paste is something that could be resolved with a new HW revision at least. In theory so could the addition of a fan (Asuswrt even has code already to handle fan control, an artifact from the revision A RT-N66U), tho that kind of change might require re-certification and releasing it under a new SKU, as for some people having a fan in there would be unacceptable (like myself - I want my router to be 100% quiet).

Hi merlin and all!!
I replaced my router yesterday and put it on my laptop cooler and configured 75% to what I had, I even left nat acceleration on!
my video test played fine about 85% of the time (Never with the old 87 router)

PS4 lag is also non existent at the moment also.

Now I did reflash and reset my old one the last time I complained on here, so the heat is also corrupting the code.
As nothing to the old one would stop the lag but a flash and reset.

Bottom line is use a fan / laptop cooler on this and all should be ALMOST perfect.

note: I had an inch under my old one with no fan tho, but airflow was NEVER a problem, and that still was not enough.

Edit: my friends router that I picked up for him when it came out, is in a shelf in a closet with the same firmware from then (2nd or 3rd version) and it is still good, now they DO NOT use the usb or much at all, so I do not know why some of us are having this heat problem, unless the cause is a usb drive attached (thou mine are powered). and it takes a while to break down like mine did??? Anyway my friend is buying a laptop cooler for his, just in case.

 

[LoneWolf]

Well, the above might explain why I have had no issues with my RT-AC87. My results for the Quantenna:

temperature_rfic_external = 0.0
temperature_rfic_internal = 59.3
temperature_bbic_internal = 75.0

And for the Broadcom:

CPU temperature : 77øC

Based on what everyone else is saying, I can only guess that the heatsinks in my router are attached well, and that air circulation is good enough to keep a reasonable temperature. I think I saw the bbic_internal at 79.0 yesterday, but that still sounds well within parameters.

 

[richdbenson]

There is a typo in instruction 6. It should read as shown just below.

6) Go to LAN tab and disable DHCP, Setup up 192.168.1.1 as the DNS server and WINS server, Set up 192.168.1.2 as the 2nd router IP address.

I may have figured out what flooded my syslog with VLAN1 messages. I have an Epson printer that was set up on ethernet as well as attached to the wifi radio. Just figured this out last night. Does anyone else with the AP or VLAN1 issues have this situation? Still some message suppression but no VLAN1 and the number is much smaller (hundreds vs hundreds of thousands)

This is my total syslog since last night.

Jan 18 02:59:57 ntp: start NTP update
Jan 18 03:59:59 ntp: start NTP update
Jan 18 05:00:01 ntp: start NTP update
Jan 18 05:00:04 ntp: start NTP update
Jan 18 05:01:01 kernel: br0: received packet on eth1 with own address as source address
Jan 18 05:59:57 ntp: start NTP update
Jan 18 06:00:00 ntp: start NTP update
Jan 18 06:59:57 ntp: start NTP update
Jan 18 07:59:57 ntp: start NTP update
Jan 18 08:14:41 kernel: net_ratelimit: 684 callbacks suppressed
Jan 18 08:15:07 kernel: net_ratelimit: 195 callbacks suppressed
Jan 18 08:15:31 kernel: net_ratelimit: 511 callbacks suppressed
Jan 18 08:15:55 kernel: net_ratelimit: 269 callbacks suppressed
Jan 18 08:16:35 kernel: net_ratelimit: 293 callbacks suppressed
Jan 18 08:16:47 kernel: net_ratelimit: 8 callbacks suppressed

 

[Ronv42]

Temperature not effecting mine yet: I had two roku's streaming and my kids school MacBook and two tablets hitting the 5 Ghz and this is what I saw:


2.4 GHz: 47°C - 5 GHz: 66°C - CPU: 78°C

I just have the router sitting on a desk, no fans, small amount of airflow at this desk and indoor temp for winter is hovering about 68 to 70 degrees. I have had the router since it was released at Best Buy last year.

 

[TheDude54]

Temperature not effecting mine yet: I had two roku's streaming and my kids school MacBook and two tablets hitting the 5 Ghz and this is what I saw:


2.4 GHz: 47°C - 5 GHz: 66°C - CPU: 78°C

I just have the router sitting on a desk, no fans, small amount of airflow at this desk and indoor temp for winter is hovering about 68 to 70 degrees. I have had the router since it was released at Best Buy last year.

======================================
I don't think temp is causing my problem either. I am currently using RT-AC87U_3.0.0.4_376.49_5 (Merlin) - still having the same problem since I got the router - the 5Ghz wireless signal disappears - - on average once a week or so. my temp has never exceeded 62 degrees C - I do a lot of streaming using ghe 5ghz both inside the network with mezzmo and outside (using Plex pass). I have tried nearlyy all of the official ASUS and Merlin firmwares - no joy..
One other thing I want to mention, there seems to be some difference between the ASUS and Merl.in firmwares. When I use ASUS firmware - the please streaming won't work outside of my network - when using Merlin's firmware - the remote plex streaming works fine. As far as I know , I am using the same setting for both... any ideas. It is not a big deal because I prefer Merlin's firmware - just curious mostly.