What's new

Asus RT-AC87R/U - FACTORY F/W Bug Thread

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

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

This message flood went away for me after I've disabled the "use DHCP routes" setting under LAN/IPTV. Don't know why or if this is associated. Only as a hint.
 
I tried that, mine still show up but only on the 5ghz. weird.....
 
I have the same Vlan1 issue.
I tried the DHCP routes setting but it is still there.
The strange thing is the time stamps on the log entry's.
They all happen at the same time (xx:27:yy) and with in 3 seconds of each other.
I have double checked all of my computers, cell phones etc etc for duplicate IP's.
All devices use a static IP and the cell phones have a manually assigned DHCP IP address.
I have added all my wireless devices MAC addresses into the mac filter table.
Then set it to only allow those devices.
The wireless 2.4Ghz and 5Ghz have different SSID's
I have been reading other forums and postings here for ideas as to what is causing this.
I'm at a loss here as to what is going on.
Ideas??

Oct 11 02:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 02:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 03:27:26 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 03:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 04:27:26 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 06:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 06:27:29 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 07:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 08:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 08:27:29 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 09:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 09:27:29 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 10:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 15:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 17:04:00 rc_service: httpd 1034:notify_rc restart_wlcscan
Oct 11 17:04:24 rc_service: httpd 1034:notify_rc restart_wlcscan
Oct 11 19:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 19:27:29 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 20:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 21:27:28 kernel: br0: received packet on vlan1 with own address as source address
.
 
Purchased the router over the weekend and updated to the latest firmware. Over night the router shut off its radios. I had to manually go in this morning to enable radios for 2.4ghz and 5ghz. Anyone else experience something similar?
 
Purchased the router over the weekend and updated to the latest firmware. Over night the router shut off its radios. I had to manually go in this morning to enable radios for 2.4ghz and 5ghz. Anyone else experience something similar?

Most likely reason was someone pressed on the button at the front that turns off the radios, unless you somehow configured a schedule on both bands.
 
Most likely reason was someone pressed on the button at the front that turns off the radios, unless you somehow configured a schedule on both bands.

I haven't messed with the schedule at all and its on top of a shelf far away from my toddler. Will have to see if it repeats any time this week, and if so, still in return period if I need to return it.
 
I have the same Vlan1 issue.
I tried the DHCP routes setting but it is still there.
The strange thing is the time stamps on the log entry's.
They all happen at the same time (xx:27:yy) and with in 3 seconds of each other.
I have double checked all of my computers, cell phones etc etc for duplicate IP's.
All devices use a static IP and the cell phones have a manually assigned DHCP IP address.
I have added all my wireless devices MAC addresses into the mac filter table.
Then set it to only allow those devices.
The wireless 2.4Ghz and 5Ghz have different SSID's
I have been reading other forums and postings here for ideas as to what is causing this.
I'm at a loss here as to what is going on.
Ideas??

Oct 11 02:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 02:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 03:27:26 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 03:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 04:27:26 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 06:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 06:27:29 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 07:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 08:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 08:27:29 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 09:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 09:27:29 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 10:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 15:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 17:04:00 rc_service: httpd 1034:notify_rc restart_wlcscan
Oct 11 17:04:24 rc_service: httpd 1034:notify_rc restart_wlcscan
Oct 11 19:27:28 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 19:27:29 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 20:27:27 kernel: br0: received packet on vlan1 with own address as source address
Oct 11 21:27:28 kernel: br0: received packet on vlan1 with own address as source address
.
I'm seeing the exact same issue here using an AC87 + AC66 in repeater mode. From some digging, I've found it can be a layer 2 loop I guess? This is something I found from another forum, relating to that exact message...

"The simplest way for a wi-fi repeater to work is to listen out for wi-fi traffic, copy any it receives, wait for the airwaves to go quiet then broadcast a pretty much verbatim copy of the original transmission. The "repeat" transmissions are highly likely to be received by the original transmitter also, which means it will be receiving a wi-fi packet with it's own address as the "senders" address. (There are a few "wrinkles, so I'm generalising somewhat for the sake of brevity.)

By way of example, let's have a router "R" and a repeater "A" and client station "C". To send a packet from R to C, R will construct a packet with destination address "C" and source address "R" which will be transmitted by R...

R: sends packet [C][R][Data]

The repeater/extender will "hear" this, copy it, thence send exactly the same packet...

A: sends packet [C][R][Data]

Because your repeater (A) is "in range" of R, then R will "hear" this frame and complain that "someone else" is sending data using R's address as it's source address."
 
I do not have any repeaters set up.
There may be one at a neighbors house.
I was seeing other wi-fi signals when I do a scan.
The last 2 days nothing shows up, in active or passive mode.
Strange.
 
I found what broke the site scan function.
If I set the wireless MAC filter to enabled, enter my wi-fi devices using the 'allow' function
Then site scan does not work.
Disable the filter and the scan works.
 
Last edited:
Hi - First post here.

Similar AP issue with a new RT-AC87R. It's in AP mode, static IP. I assign an address ending in .240/24. Reboot. It initially comes up with .240 but then changes to .220 which is an IP in my DHCP address pool. I can then access the admin pages at .220, change it to .240 and then access it via .240. I've not yet tried a DHCP reservation. Regardless, the static assignment should work but it doesn't. There may not be a DHCP server around if the entire network comes up cold.

I'm running Merlin 3.0.0.4.376.47_0.

A minor annoyance is that sshd isn't yet available, only telnet.
 
Same Problem

I have the same problem in AP mode. Give it an IP address of 192.168.3.2 and then it goes and gets an IP address from DHCP!

I have to use a DHCP static reservation - that's the only way to get the AP to stay on a known IP.

This router is so flaky...
 
After getting this router over the weekend, and using it for about 2 day's. I thought it would make sense to start a thread, so anyone who has this router already, can post about bugs they are finding. So if you find a bug, or bugs using this router, report your finding's here.
To add my experience, using this AC87U, as access point combined with my ERL router, after 3 weeks of usage, using latest stock firmware:

1. range has become worse compared to my earlier R7000 and much earlier ac66u. My guts tells me that this has to do with reduced Tx power on ALL channels as I am using an EU model.

2. Static IP does NOT work with this thing when using it as an access point. Seems to be a general firmware issue as I encountered the same limitation on my AC66U recently.

3. Network instability when used with a Broadcom based bridge, resulting in network interrupts throughout. As mentioned by many on this site. Very annoying.

4. Channel hopping. I tell it to use ch48 it takes ch108 as an example.

5. Had a situation that the wireless log tells me that 5g radio is not ready yet (forever) while still being operative. Hard reset didn't work. nvram clear also didn't resolve. The only way to get rid of this was to re-flash!

Above are just some of the problems out of my head. Eventually I swapped it with my old R7000 and am back at a stable, and better range, network.

This AC87U box is currently lying in dust until better firmware comes along.

Regarding issue 1. it would be useful if someone could compare the US and EU power settings. Have no idea how to retrieve this from Quantenna firmware. I think the EU-based buyers should become aware of limitations. @Tim: would be useful to cover the regional power limitations in future reviews, to avoid disappointments.
 
Last edited:
Quite honestly, I don't understand why so many people are having such issues, while a lot of us don't have any. Personally, the RT-AC87U has been my main router since before its release, and all my wireless devices are working just fine with it so far:

  • One laptop with an Intel AC7260 (5 GHz)
  • One Nexus 7 (2.4 GHz)
  • One Nexus 4 (2.4 GHz)
  • One Asus Transformer T100 (some Broadcom chip, 5 GHz)


    • The fact that different people have different experiences lead me to believe that any issue might be client or environment specific.
 
Sir, could it possibly be that you have a better router hardware wise? If I can plug it into the very spot my 66 was in and it has problems.....I doubt its my environment....I'm not the expert you are...and I don't have the money to throw down on every 300+ dollar router....but I think it should at the very minimum plug and play with ASUSs last gen routers.....I think these have hardware tolerance or quality issues.
 
Sir, could it possibly be that you have a better router hardware wise? If I can plug it into the very spot my 66 was in and it has problems.....I doubt its my environment....I'm not the expert you are...and I don't have the money to throw down on every 300+ dollar router....but I think it should at the very minimum plug and play with ASUSs last gen routers.....I think these have hardware tolerance or quality issues.

Wireless networking will never be just plug and play, due to the fact that you have a bunch of different manufacturers trying to inter-operate with one another. Too many variables, and as wireless technology becomes increasingly complex with the addition of MIMO, MU-MIMO, 802.11ac beamforming, proprietary beamforming and so on. Take the Intel AC7260 just for an example that's totally unrelated to Asus. Under Windows 8, it took 6-10 months for Intel to provide a driver that worked properly regardless of the router that was at the other end.

Another case: it seems that every now and then, a new iOS release causes wifi issues that get posted all over the Apple forums. Many iOS 8 users reported issues with their iDevices.

Take such wireless interface issues, combine them with router-specific issues, and you get the current situation: wireless technology is one big messy situation of random luck on whether one particular router, with one particular wireless client, running in one particular environment, will be able to work properly "just plug and play", or if you will have to spend a lot of time upgrading router firmwares, wireless client drivers, changing channels, changing channel bandwidth, retiring that old wireless baby monitor, and so on.

That's why I always tell everyone, both on forums and my own customers that wireless should be a LAST RESORT technology, not a "let's go wifi everywhere". because it's very, very rarely "just plug and play". Ethernet will always work better and be far more reliable than wireless, because the technology is far simpler, with fewer variables.

These types of complains are far from unique to the RT-AC87U. I read the same type of complains from R7000 owners too. And every now and then, an Asus customer will switch to Netgear and claim that all his issues "just went away". And on another forum, it's a Netgear user who switches to Asus and claim the same thing.

So in short, people too often put all the blame on their router's firmware when a lot of times the actual issue lies at the client's end, or with their un-optimized router settings (how many times must people be told that using 40 MHz on the 2.4 GHz band is very unlikely to end up well?). When working on a wireless issue, the ENTIRE network must be looked at, not just the router. The "this other router works just fine" conclusion does not lead to any legit conclusion until they have actually went through the whole troubleshooting process.
 
You are absolutely right that its difficult to maintain 100% compatibility with everything because of the wide range of equipment out there.

But are you saying some of the widely reported bugs just don't exist?

For example, have you tried using it in AP mode with a static IP address?

RT-AC87U: 192.168.3.2 (AP mode)
Main Router: 192.168.3.1

Problems:
- IP address - keeps changing - has been widely reported that the static IP address function doesn't work
- AP keeps going offline
- AP keeps causing some sort of network loop

Thanks.
 
You are absolutely right that its difficult to maintain 100% compatibility with everything because of the wide range of equipment out there.

But are you saying some of the widely reported bugs just don't exist?

For example, have you tried using it in AP mode with a static IP address?

RT-AC87U: 192.168.3.2 (AP mode)
Main Router: 192.168.3.1

Problems:
- IP address - keeps changing - has been widely reported that the static IP address function doesn't work
- AP keeps going offline
- AP keeps causing some sort of network loop

Thanks.

I'm talking about the constant reports that "wireless sucks on this router, therefore it's the router's fault".

The firmware is certainly not without its bugs.
 
Agreed :)

Havent gotten as far as really testing the wireless performance yet on my router, since its never really been stable for long enough :)

I have to say the NAS performance is much better than RT-AC68U, but then again, the 68U was just really bad at that.

Thanks for the reply.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Staff online

Top