What's new

Asus RT-AC3200 issues and impressions

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

@RMerlin,

Thanks for the info. Could you be little more helpful and instruct me how I can disable uPnP support on WAN1? I don't see that particular option anywhere.

Turn on Dual WAN? Then set uPnP off for Wan1?

I'm not sure why the concern. If Wan1 is not connected to the Internet, there should be no exposure.

ASUS does not expose the uPnP port to the Internet anyhow, so there is little risk there.

You can check uPnP exposure on this website: https://www.grc.com/default.htm
 
I am seeing the following in the General Log:

Code:
Feb  7 07:23:17 kernel: br0: received packet on eth3 with own address as source address
Feb  7 07:49:03 kernel: br0: received packet on eth1 with own address as source address
Feb  7 07:49:04 kernel: br0: received packet on eth2 with own address as source address
Feb  7 07:51:05 kernel: br0: received packet on eth3 with own address as source address
Feb  7 07:51:50 kernel: br0: received packet on eth3 with own address as source address
Feb  7 07:51:50 kernel: br0: received packet on eth2 with own address as source address
Feb  7 07:53:49 kernel: br0: received packet on eth2 with own address as source address

I believe that ASUS is using Linux NIC bonding for the Dual WAN and that may be where these messages are coming from. br0 is a typical bonding name used for this capability. I do not have Dual WAN enabled. I'm not sure that these messages are not causing some issues.
 
I am seeing the following in the General Log:

Code:
Feb  7 07:23:17 kernel: br0: received packet on eth3 with own address as source address
Feb  7 07:49:03 kernel: br0: received packet on eth1 with own address as source address
Feb  7 07:49:04 kernel: br0: received packet on eth2 with own address as source address
Feb  7 07:51:05 kernel: br0: received packet on eth3 with own address as source address
Feb  7 07:51:50 kernel: br0: received packet on eth3 with own address as source address
Feb  7 07:51:50 kernel: br0: received packet on eth2 with own address as source address
Feb  7 07:53:49 kernel: br0: received packet on eth2 with own address as source address

I believe that ASUS is using Linux NIC bonding for the Dual WAN and that may be where these messages are coming from. br0 is a typical bonding name used for this capability. I do not have Dual WAN enabled. I'm not sure that these messages are not causing some issues.

I'm getting the same thing since the update.

I was previously having the random disconnects/internet dropouts before - haven't had enough time to tell if this issue is now resolved.
 
@RMerlin,

Thanks for the info. Could you be little more helpful and instruct me how I can disable uPnP support on WAN1? I don't see that particular option anywhere.

It's not enabled, unless you enable Dual WAN. This is simply a false alarm.

If you want to get rid of the warning, you can run the following commands on your router, over telnet:

Code:
nvram set wan1_upnp_enable=0
nvram commit
 
I am seeing the following in the General Log:

Code:
Feb  7 07:23:17 kernel: br0: received packet on eth3 with own address as source address
Feb  7 07:49:03 kernel: br0: received packet on eth1 with own address as source address
Feb  7 07:49:04 kernel: br0: received packet on eth2 with own address as source address
Feb  7 07:51:05 kernel: br0: received packet on eth3 with own address as source address
Feb  7 07:51:50 kernel: br0: received packet on eth3 with own address as source address
Feb  7 07:51:50 kernel: br0: received packet on eth2 with own address as source address
Feb  7 07:53:49 kernel: br0: received packet on eth2 with own address as source address

I believe that ASUS is using Linux NIC bonding for the Dual WAN and that may be where these messages are coming from. br0 is a typical bonding name used for this capability. I do not have Dual WAN enabled. I'm not sure that these messages are not causing some issues.

br0 is a bridge.
 
I get more drops with the latest firmware. Am going to turn off smart connect and see how that goes. Too bad.

Same here. On my iPhone 6 I have to go into WIFI settings on the phone to reconnect by selecting the SSID again. For now I'm shutting down smart connect as well. I hope this gets some TLC from Asus. I really want to be able to use it.
 
Firware .4129 worse

I installed firmware .4129 last night and it has made Smart Connect unusable to me now, where before it just dropped a lot.

Netflix now, on UHD TV, locks up at exactly 50% on any movie. I have to reboot router and TV, try again and same. I switched Smart Connect off and it works great again.

On Galaxy S5 connects and disconnects more frequently with new firmware and Smart Connect also.

I have now turned it off until next firmware. Please fix this Asus.
 
Adaptive QoS -> Bandwidth Monitor

I'm having an issue with the Adaptive Qos -> Bandwidth Monitor. When I first boot the AC3200, it shows activity per device as I expect. After some time, I come back to look at it and it does not show any activity on any devices. I don't have the Apps Analysis turned on. I wonder if there is a setting that has an affect on the Bandwidth Monitor. The Traffic Analyzer is working fine.
 
I have now turned it off until next firmware. Please fix this Asus.

I have not experienced these disconnects as much as others are reporting. My iPad switches as I walk around the house to a different band causing a pause in the connection, but soon comes back. I'm not having any issues on laptops or other devices.

I wonder if the Smart Connect Rules need to be tweaked for the wireless environment at each location? I would guess that ASUS set up the Smart Connect rules for the ideal situation. What would help is documentation of the rules on the Smart Connect Page and what each does so we could make adjustments for our particular environment.

Wireless operation is very dependent on each unique environment - building construction, interference, other wireless bands in use, and placement of components. Expecting perfect Smart Connect operation out of the box may not be realistic in all cases.
 
Smart Connect Rules

If anyone can explain in detail the Smart Connect rules page I could see if changing some of the settings will make a huge difference. I do not understand quite a bit of it and I cannot find any instructions for it.
 
If anyone can explain in detail the Smart Connect rules page I could see if changing some of the settings will make a huge difference. I do not understand quite a bit of it and I cannot find any instructions for it.
There are no instructions. Have fun experimenting.
 
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.

Feb 8 10:48:48 kernel: net_ratelimit: 556 callbacks suppressed

Anybody seeing lots of these on the RT-AC3200 (4129, with Comcast IPv6)? Is that why I am getting the net_ratelimit due to syslog being filled with these?
 
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.
Feb 8 10:48:37 kernel: ipv6: Neighbour table overflow.

Feb 8 10:48:48 kernel: net_ratelimit: 556 callbacks suppressed

Anybody seeing lots of these on the RT-AC3200 (4129, with Comcast IPv6)? Is that why I am getting the net_ratelimit due to syslog being filled with these?

This is an age-old issue specific to Comcast's IPv6. Comcast blames Asus, Asus blames Comcast, and one year later neither of them have come up with any solution.

Personally, I blame mostly Comcast, since other ISPs have no issue and the packets that are causing these errors should never reach an end-user router in the first place, and partly the old Linux kernel used by all Broadcom routers.

At this time, the only solution is to go with a third party firmware that implements a workaround for this. The RT-AC3200 being new, there's currently no third party firmware available for it at this time.
 
If anyone can explain in detail the Smart Connect rules page I could see if changing some of the settings will make a huge difference. I do not understand quite a bit of it and I cannot find any instructions for it.

What are the rules/settings/choices that are available?
 

Latest threads

Sign Up For SNBForums Daily Digest

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