[Solved] Asus RT-AC87U: problem setting up 5GHz Guest Network

Greetings! I setup a new Asus RT-AC87U last week and am having a problem. Searching for solution online leads me to this forum.

Synopsis: setting up an Guest Network account for 5GHz always causes the GUI to 'crash' and thus losing internet connection. Enabling one for the 2.4GHz has no problem.

Detailed description: After hitting 'Apply' and the % says 'Complete', the GUI (in browser Firefox) keeps on connecting and eventually it is timed out.
The message ("Settings have been updated. Webpage will not refresh. Changes have been made to the IP address or port number. You will now to disconnected from RT-AC87U. To access the settings of RT-AC87U, reconnect to the wireless network and use the updated IP address and port.'') appeared. Using this message to search online, I found that clearing offline cache of FF might make this message to go away. I tried and have various degree of success and I sometimes (only once in a while) can even get back into GUI. But then, the whole process gave very very sluggish. Even if I can manage to get back into GUI, response within is very sluggish. Needless to say, connection to internet is lost the whole time.

Using IE as browser, rebooting the PC...do not solve the problem of not being able to get into GUI and restoring internet connection. The only solution that I have found (so far) is to reset the router to factory default settings (by pressing the little orange button for 5-10 seconds). Then, of course, I have to setup once again from square one. But still, I end up with no 5GHz Guest Network account.

This is a repeatable problem. I have tried several times, each time using different settings for the Guest account, but the same result happened each time.

I get into System log and copy below the portion which I think is relevant:-

Jul 31 13:01:06 WAN Connection: Ethernet link up.
Jul 31 13:01:06 rc_service: wanduck 633:notify_rc restart_wan_if 0
Jul 31 13:01:06 kernel: Attempt to kill tasklet from interrupt
Jul 31 13:01:14 WAN Connection: Ethernet link up.
Jul 31 13:01:14 rc_service: wanduck 633:notify_rc restart_wan_if 0
Jul 31 13:01:14 kernel: Attempt to kill tasklet from interrupt
Jul 31 13:01:22 WAN Connection: ISP's DHCP did not function properly.
Jul 31 13:01:48 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jul 31 13:01:48 wan: finish adding multi routes
Jul 31 13:01:48 rc_service: udhcpc 2386:notify_rc stop_upnp
Jul 31 13:01:49 rc_service: udhcpc 2386:notify_rc start_upnp
Jul 31 13:01:50 dhcp client: bound 203.218.75.205 via 203.218.75.254 during 900 seconds.
Jul 31 13:01:52 WAN Connection: WAN was restored.
Jul 31 13:01:53 ntp: start NTP update
Jul 31 13:23:26 rc_service: httpd 665:notify_rc restart_wireless
Jul 31 13:23:27 CTF: STP enabled, disable FA
Jul 31 13:23:30 kernel: wl_module_init: passivemode set to 0x0
Jul 31 13:23:30 kernel: wl_module_init: txworkq set to 0x1
Jul 31 13:23:30 kernel: eth1: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.86 (r456083)
Jul 31 13:23:31 kernel: br0: adding interface vlan4000 with same address as a received packet
Jul 31 13:23:38 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:39 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:40 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:41 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:42 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:43 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:44 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:44 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:44 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:45 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:46 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:47 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:47 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:47 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:48 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:50 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:50 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:53 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:53 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:03 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:04 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:10 kernel: net_ratelimit: 13 callbacks suppressed
Jul 31 13:24:10 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:10 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:14 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:16 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:16 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:16 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:16 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: net_ratelimit: 21 callbacks suppressed
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:22 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:22 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:22 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:22 kernel: br0: received packet on vlan1 with own address as source address


I see that this statement ''received packet on vlan1 with own address as source address'' comes up hundreds of times. Looks like the router is in some kind of a loop?

I am a router novice and am unable to extract useful hint further.

Please help. Thank you.
(BTW, I am using Asus 378_5134 firmware.)

snb008 said:

Greetings! I setup a new Asus RT-AC87U last week and am having a problem. Searching for solution online leads me to this forum.

Let me explain the situation: Setting up a Guest Network for the 2.4GHz is no problem. But enabling one for the 5GHz leads to strange problem. After hitting 'Apply' and the % says 'Complete', the GUI (in browser Firefox) keeps on connecting and eventually it is timed out. The message ("Settings have been updated. Webpage will not refresh. Changes have been made to the IP address or port number. You will now to disconnected from RT-AC87U. To access the settings of RT-AC87U, reconnect to the wireless network and use the updated IP address and port.'') appeared.

Using this message to search online, I found that clearing offline cache of FF might make this message to go away. I have various degree of success and I sometimes (only once in a while) can get back into GUI. But then, the whole time gave very very sluggish response. Even if I can manage to get back into GUI, response within is very sluggish. Needless to say, connection to internet is lost the whole time.

Using IE as browser, rebooting the PC...do not solve the problem of not being able to get into GUI and restoring internet connection. The only solution that I have found (so far) is to reset the router to factory default settings (by pressing the little orange button for 5-10 seconds). Then, of course, I have to setup it from square one. But still, I end up with no 5GHz Guest Network account.

This is a repeatable problem.

I get into System log and copy below the portion which I think is relevant:-

Jul 31 13:01:06 WAN Connection: Ethernet link up.
Jul 31 13:01:06 rc_service: wanduck 633:notify_rc restart_wan_if 0
Jul 31 13:01:06 kernel: Attempt to kill tasklet from interrupt
Jul 31 13:01:14 WAN Connection: Ethernet link up.
Jul 31 13:01:14 rc_service: wanduck 633:notify_rc restart_wan_if 0
Jul 31 13:01:14 kernel: Attempt to kill tasklet from interrupt
Jul 31 13:01:22 WAN Connection: ISP's DHCP did not function properly.
Jul 31 13:01:48 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jul 31 13:01:48 wan: finish adding multi routes
Jul 31 13:01:48 rc_service: udhcpc 2386:notify_rc stop_upnp
Jul 31 13:01:49 rc_service: udhcpc 2386:notify_rc start_upnp
Jul 31 13:01:50 dhcp client: bound 203.218.75.205 via 203.218.75.254 during 900 seconds.
Jul 31 13:01:52 WAN Connection: WAN was restored.
Jul 31 13:01:53 ntp: start NTP update
Jul 31 13:23:26 rc_service: httpd 665:notify_rc restart_wireless
Jul 31 13:23:27 CTF: STP enabled, disable FA
Jul 31 13:23:30 kernel: wl_module_init: passivemode set to 0x0
Jul 31 13:23:30 kernel: wl_module_init: txworkq set to 0x1
Jul 31 13:23:30 kernel: eth1: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.86 (r456083)
Jul 31 13:23:31 kernel: br0: adding interface vlan4000 with same address as a received packet
Jul 31 13:23:38 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:39 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:40 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:41 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:42 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:43 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:44 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:44 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:44 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:45 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:46 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:47 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:47 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:47 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:48 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:50 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:50 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:53 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:23:53 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:03 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:04 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:05 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:10 kernel: net_ratelimit: 13 callbacks suppressed
Jul 31 13:24:10 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:10 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:14 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:15 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:16 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:16 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:16 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:16 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: net_ratelimit: 21 callbacks suppressed
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:21 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:22 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:22 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:22 kernel: br0: received packet on vlan1 with own address as source address
Jul 31 13:24:22 kernel: br0: received packet on vlan1 with own address as source address


I see that this statement ''received packet on vlan1 with own address as source address'' comes up hundreds of times. Looks like the router is in some kind of a loop?

I am a router novice and am unable to extract useful hint further.

Please help. Thank you.
(BTW, I am using Asus 378_5134 firmware.)

Click to expand...

I recommend you to install one of the latest firmware from Asus or the latest Merlin`s firmware. (I preffer Merlin`s firmware)
http://www.snbforums.com/threads/asus-rt-ac87u-3-0-0-4_378_7449-unofficial-beta-firmware.26056/

http://www.snbforums.com/threads/asuswrt-merlin-378-55-is-now-available.25874/page-4#post-193248
I hope this can be usefull for you.

exducados said:

I recommend you to install one of the latest firmware from Asus or the latest Merlin`s firmware. (I preffer Merlin`s firmware)
http://www.snbforums.com/threads/asus-rt-ac87u-3-0-0-4_378_7449-unofficial-beta-firmware.26056/

http://www.snbforums.com/threads/asuswrt-merlin-378-55-is-now-available.25874/page-4#post-193248
I hope this can be usefull for you.

Click to expand...

If this is the last resort, then I would do it. But for the time being, I would rather stay with Asus official firmware as I am not an expert in networking.

But since you have brought this up, may I ask:-
After flashing to a Merlin's firmware,
1) and if something goes wrong, what happens when I use the reset button? What will the router load back?

2) will I be able to go back to Asus official firmware easily? eg, when I need to send the router in for warranty service, as I suppose it is better to have an official Asus firmware inside.

Once again, I hope to get familiar with Asus firmware more before 'upgrading' to Merlin's.
(I do like Merlin's firmware being able to show temperature. My 87U is a little hot but I am using an USB fan blowing across and it is quite cool to touch now.)

RMerlin is same as stock but with lots of improvements and fixes, even the user interface is similar.
The unofficial betas are taken from ASUS support, so there's no problem applying it.
Merlin's firmware after applying it, if you don't like it (you'll love it), you can flash stock again without any problem.

Remember after flashing any firmware into the device, always:
-Manually reboot device when requested.
-Do a hard reset after it fully booted
-Configure it manually (don't use restore option with the .cfg file)

sentinelvdx said:

Remember after flashing any firmware into the device, always:
-Manually reboot device when requested.
-Do a hard reset after it fully booted
-Configure it manually (don't use restore option with the .cfg file)

Click to expand...

I've never done that part. Not that I believe I shouldn't but it is just I never paid attention to the difference between a WebUI reboot and a physical press. So part of it is laziness and the other part is ignorance.

Could you please explain what could go wrong ?

Asus.87 said:

I've never done that part. Not that I believe I shouldn't but it is just I never paid attention to the difference between a WebUI reboot and a physical press. So part of it is laziness and the other part is ignorance.

Could you please explain what could go wrong ?

Click to expand...

When you reboot manually (power off and on again) new drivers and firmware changes are loaded.
The WebGUI should do the same, but I trust more the manual way.

I have flashed the firmware to 7410 (the latest beta firmware in Asus website) and has a very small improvement.

Now, I have successfully setup a 5GHz Guest Network. However, at the same time, I still cannot get into the GUI. After typing in the username and password, the browser (FF) keeps on 'connecting' to 192.168.1.1 and never gets through. Eventually, the attempt is timed out. At the same time, accessing the internet with my PC (as the only wired client of the RT-AC87U) is extremely sluggish. Loading a page takes forever.

Of course, this is unacceptable and I have to use the reset button to setup the router again, without a 5GHz Guest Network.

It seems to me whenever a 5GHz Guest Network is enabled, the router draws all its resource and power to that network, making itself slow or unable to handle my PC as a wired client (ie accessing the GUI or surfing the internet).

This might not be a bug. As I am a networking noob, there might be a setting or two that I need to adjust?

Anyone has this combo working (ie a PC as a wired client together with a 5GHz Guest Network) for a RT-AC87U?

Any ideas, suggestions and opinions are welcome.
Thank you.

I do have my main PC wired, 2 devices on 5Ghz, 1 5Ghz and 1 2.4Ghz guest, 3 devices on 2.4ghz and no problems at all.

I'll suggest going with Beta 7449 I have posted 12 days ago
But ensure to do a hard reset and reconfigure it manually after flashing (without using the cfg file)

Replied through Tapatalk

sentinelvdx said:

I do have my main PC wired, 2 devices on 5Ghz, 1 5Ghz and 1 2.4Ghz guest, 3 devices on 2.4ghz and no problems at all.

I'll suggest going with Beta 7449 I have posted 12 days ago
But ensure to do a hard reset and reconfigure it manually after flashing (without using the cfg file)

Replied through Tapatalk

Click to expand...

Thank you for your feedback.

I am too tired to do this today. I will do it tomorrow. Frankly, I am a little disappointed (and surprised) that this is happening. I mean, setting up a guest account is not a big deal and should not pose such headache.

Before buying this router, I narrowed down the choices to this Asus RT-AC87U and a Netgear equivalent. I finally picked this Asus over the Netgear because of Asus' supposedly superior firmware and user interface. I hope I have not made the wrong choice.

I hope this is not a hardware defect. Since the admin's 5GHz network works fine, I imagine the same hardware is also handling all 3 possible 5GHz guest networks. So frustrated...lol

Big improvement today.

I flash to 7449 and it is working now...so far at least.

But along the process is not free of problem. I will give detail below as a documentary for anyone to refer to when he might come across this problem in the future:-

After flashing to beta 7449, I hard reset as well as do a physical reboot (ie turning off the power to the router for a minute or two and then press down the power button again).

I first enabled a 5GHz guest network. Then, I enabled a 2.4GHz guest network. Both went without problem.
Then, I renamed the SSID of the 2.4GHz guest network. After hitting 'Apply', the % went up to 100 and is 'Complete'. Then, oddly, another Guest Network screen came up. I have not seen this screen coming up before during a 2.4GHz Guest Network setup. But, this screen almost always came up for a 5GHz Guest Network. It is the one asking you to fill in the WEP Key1, Key2, Key3, Key4 and Asus Passphrase. At this screen, the GUI crashed. GUI in Firefox kept connecting but never got through and, of course, it eventually was timed out.
(That screen also came up all the time while I tried to setup a 5Ghz Guest network previously. It was always at that screen that the GUI crashed. Unfortunately I did not take a pic of this screen and I cannot find a copy of the screen in Google to post here.)

So, I reset the router and started all over again. This time, I typed in the name of the SSID that I want in the first time. After hitting 'Apply', both 5GHz and 2.4GHz guest networks went through with no problem.

So, frankly, I do not feel that the router is 'rock solid' and it seems still 'unstable'. But for the time being at least, the problem is 'solved'.

Thank you all, especially sentinelvdx, for the help.

Sounds more like a browser problem than a router issue. Have you tried to use another browser clean the cache and hofully free of any third party BHOs?

The trick of clearing cache did not work for me. It can only get rid of the ''Settings have been updated...'' message but the problem remains. I have also tried IE as well.

It is interesting that 5134 and 7410 did not work but 7449 did work. And 7449 only came out like 12(?) days ago.

Perhaps the next firmware will further improve. (BTW, I am getting hundreds of ''kernel: br0: received packet on vlan1 with own address as source address'' in the System log and I gather from this forum that this has to be fixed by Asus. Hopefully, the next firmware release will take care of this as well.)

For the moment I don't have any news about upcoming firmware betas. I'll update as soon as I have any news.

New QTN SDK scheduled for sometime in August, so don't expect any new meaningful beta for a while.

Thanks for the update!

Replied through Tapatalk

So, after two days, decide to do a power reboot to test out the stability. Unfortunately, the problem comes back.

After manually shutting down the power last night and then power it back on this morning, the router becomes extremely sluggish, in the sense that entering GUI takes a lot of time (even being timed out a few times). It is still sluggish within the GUI. Surfing the net is also extremely slow. There are hundreds of ''kernel: br0: received packet on vlan1 with own address as source address'' in the System log and I am not sure if this has anything to do with this.

I still have the 5GHz Guest Network but it is still unacceptable to have the above problem.
At this point, I do a factory reset and use the Wizard to setup the router again. Right after hitting 'Apply' for a 5GHz Guest Network, the same problem happens again! So, I suppose 7449 does not totally solve the problem but only reduces the chance of happening.

I have a feeling that this problem might not be totally related to a 5GHz Guest network as this happened last time after I did a simple rename of the 2.4GHz Guest network.

I suppose, at this stage, I will try Merlin's firmware next. If this does not solve the problem. The router has to go back.

I want to report that after switching to Merlin's 378.55, the above problem did not manifest itself in the past several days. I hope this means the end of it. It seems enabling a 5GHz guest network will invoke instability, causing the GUI to crash. The root cause is unknown but somehow this problem does not come up after using 378.55 (latest as of the date of this post) for the few days.

I had this issue show up on the 5GHz Guest Network when I went to get setup network access for a client's infected laptop. Once I enabled it, things went haywire and had difficulties connecting to the router.

Eventually I got back onto the router and had a ton of the following messages:

One thing I noticed that when I went to setup the guest network it had plugged in the settings for my 5GHz network automatically which I think is likely the cause of all the instability. I was able to disable the guest network but still had the messages above flooding the logs. Ended up rebooting the router and the messages stopped. Didn't bother enabling the 5Ghz guest network again.