RT-AC68P & FiOS: WAN dropouts on 386.x

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

bilged

Occasional Visitor
Just wondering if there's been any progress on the WAN dropouts issue some of us have been having on 386?

FiOS ONT -> RT-AC68P (router) + 2x RT-AC68U (nodes). With the router on 384.19 everything is rock solid. This is true even after updating the nodes to a few different 386 firmwares including the latest (386.2_6).

Upgrading the main router to any of the 386 versions results in very frequent WAN dropouts. I've tried the following to troubleshoot:

- Turned off AIProtection
- Switched DHCP mode to normal, aggressive and continuous
- Changed DNS provider to Cloudflare and back to ISP

Does anyone have any idea of why this is happening and/or other fixes or troubleshooting I could try? Are people having more luck with stock firmware?

Edit: Back to 384.19 (router) and keeping 386.2_6 (nodes) and everything is fine again. No idea why this is happening. I might give the new firmware a try again but this time power cycling the ONT too. Also when I did the factory reset after upgrading, I just did the hold WPS button until the power light started blinking. Is there a more complete reset that I could do?
 
Last edited:

bilged

Occasional Visitor
OK I tried again following @L&LD's nuclear reset method and got it working. I used the following steps:

  1. Disconnect WAN and all ethernet except 1 PC, unplug ONT
  2. GUI factory reset (with checkbox ticked)
  3. Minimal config to get to advanced setup
  4. JFFS clear on reboot + reboot
  5. FW upgrade
  6. GUI factory reset (with checkbox ticked)
  7. Minimal config to get to advanced setup
  8. JFFS clear on reboot + reboot
  9. WPS NVRAM reset
  10. Minimal config to get to advanced setup
  11. GUI factory reset (with checkbox ticked)
  12. Minimal config to get to advanced setup + wait for CPUs to idle
  13. JFFS clear on reboot + reboot
  14. Power on ONT, wait for status lights, then connect to WAN port
  15. 3x reboot with 5mins between
  16. Re-setup all config except guest network
  17. Test for stable connection
  18. Plug in rest of ethernet cables
  19. Test for stable connection
  20. Node 1 WPS NVRAM reset then add to mesh
  21. Test for stable connection
  22. Node 2 WPS NVRAM reset then add to mesh
  23. Test for stable connection
  24. Re-setup guest network
Its been about 10hrs so far with no connection loss whereas before it was happening every 10mins or more. I hope this helps someone else with the same issue!
 

CoyoteDen

Occasional Visitor
It's the guest network! Turn it back on and have something join it. WAN will drop out until you manually cycle the WAN connection.

I thought it was coincidence too, but nope. Three days in a row now when I turn on my work laptop, it connects to the guest network and my WAN drops. Syslog is not very helpful, I see the wl1.1 assoc, DHCP lease, and then WAN goes down. Oddly enough, I can disconnect and reconnect to the guest network all day and WAN will stay up, it only seems to happen when nothing has been using the guest network for a while.

I've been using 386.2_6 for longer than that, but the difference is three days ago I stopped using YazFi. YazFi places the wl* interfaces on the default LAN bridge br0 and uses iptables rules to restrict them. ASUS places them on a different bridge (br2) if you have intranet access disabled.

Code:
Jun 23 12:56:45 syslog: wlceventd_proc_event(527): wl1.1: Auth ******************, status: Successful (0), rssi:0
Jun 23 12:56:45 syslog: wlceventd_proc_event(556): wl1.1: Assoc ******************, status: Successful (0), rssi:0
Jun 23 12:56:50 dnsmasq-dhcp[14132]: DHCPDISCOVER(br2) *****************
Jun 23 12:56:50 dnsmasq-dhcp[14132]: DHCPOFFER(br2) 192.168.102.242 ******************
Jun 23 12:56:50 dnsmasq-dhcp[14132]: DHCPREQUEST(br2) 192.168.102.242 ****************
Jun 23 12:56:50 dnsmasq-dhcp[14132]: Ignoring domain **************** for DHCP host name ***************
Jun 23 12:56:50 dnsmasq-dhcp[14132]: DHCPACK(br2) 192.168.102.242 ***************
Jun 23 12:57:19 WAN_Connection: ISP's DHCP did not function properly.
Jun 23 12:57:20 DualWAN: skip single wan wan_led_control - WANRED off
 
Last edited:

bilged

Occasional Visitor
It's the guest network! Turn it back on and have something join it. WAN will drop out until you manually cycle the WAN connection.
Actually that is something I forgot to mention above. Right now I'm not running any scripts but I did read somewhere in another thread that Guest Network 1 was bugged so I used the second one instead. Its now been up and stable since last night with multiple devices connected - wired, both wireless frequencies and both regular and guest networks.
 

CoyoteDen

Occasional Visitor
Guest networks 2 and 3 have a pretty bad bug too. They can access your LAN no matter how you set the "Access Intranet" option. They aren't safe to use if you are trying to keep guests out of your LAN.

This is the bridging configuration with 5G guest 1 and 2 on. Both are set to access intranet: disabled. Both should be on br2, but wl1.2 is on br0, same as if you enable intranet access on guest 1.
Code:
[email protected]_B1-0:/tmp# brctl show
bridge name    bridge id        STP enabled    interfaces
br0        8000.38d547dbe940    no        vlan1
                            eth1
                            eth2
                            tap22
                            wl1.2
br2        8000.38d547dbe945    yes        wl1.1
                            eth0.502
                            eth1.502
                            eth2.502
I have confirmed it can access LAN IPs. Enabling 2.4G guest networks will create a br1 and put wl0.1 on it.. but not wl0.2 or wl0.3.

br1/br2 blocks guests from the LAN and router services simply because the LAN vlan1/eth1/eth2 is only on br0. There are only firewall rules to allow DHCP and forwarding to WAN:
Code:
-A INPUT -i br2 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i br2 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i br2 -p udp -m udp --dport 68 -j ACCEPT
-A INPUT -i br2 -j DROP
-A FORWARD -i br2 -o eth0 -j ACCEPT
 
Last edited:

bilged

Occasional Visitor
That's awesome work - thanks for the update! Does that mean if I use your firewall script and move my guest network back to GN1 it won't drop WAN connections and the GN1 will still be isolated from the intranet?
 

CoyoteDen

Occasional Visitor
That I do not know. It’s possible the VLAN 501/502 is used to backhaul guest traffic over the mesh. If you use aimesh, you might want to modify the script to leave the VLANs on the bridge but take the WAN port off:

Code:
robocfg vlan 501 ports “1t 2t 3t 4t 5t”
robocfg vlan 502 ports “1t 2t 3t 4t 5t”
And remove the brctl lines. I do not know if this will work as I have no way to test it.

edit to add, only do this on the router connected to the WAN. You want to leave the vlans on the WAN port for the mesh nodes, especially if you use Ethernet backhaul. I think the bug in ASUS’s code is they add the WAN port in router mode. It should only be added in AP mode.
 
Last edited:

bilged

Occasional Visitor
I had zero issues with 384.19 but had dropouts on every version of 386 that I tried until I used the fixes above. I think its a new bug introduced when they updated guest network (1) to use AiMesh.
 

MamaLing

New Around Here
Hi! I'm experiencing similar situation, I have Fios internet as well. Asus Merlin firmware 386.2_6 version. I have a RT-AC68U, I got it not long ago to replace the router provided by the ISP. I have a small home network with 1 TP-Link wifi extender. I'm looking at the system log and I see strange log entries:
Jul 3 03:30:26 avahi-daemon[15918]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jul 3 03:30:34 WAN_Connection: ISP's DHCP did not function properly.
Jul 3 03:30:36 kernel: et0: et_mvlan_netdev_event: event 9 for vlan1 mvlan_en 0
Jul 3 03:30:36 kernel: et0: et_mvlan_netdev_event: event 2 for vlan1 mvlan_en 0
Jul 3 03:30:37 lldpd[15979]: cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted
Jul 3 03:30:37 lldpd[15979]: cannot get ethtool link information with GSET (requires 2.6.19+): Operation not permitted
Jul 3 03:30:39 kernel: et0: et_mvlan_netdev_event: event 6 for vlan1 mvlan_en 0
Jul 3 03:30:39 kernel: et0: et_mvlan_netdev_event: event 17 for vlan1 mvlan_en 0
Jul 3 03:30:39 kernel: et0: et_mvlan_netdev_event: event 6 for vlan2 mvlan_en 0
Jul 3 03:30:39 kernel: et0: et_mvlan_netdev_event: event 17 for vlan2 mvlan_en 0

I have problems with internet drops and what's very strange, I'm having trouble to connect to VPN on my iPhone. It's a random problem, sometimes I can connect... I've tried to connect to the VPN on different protocols, the problem is still existing. The internet still drops.
I did searches on this page on logs, I don't know if this helps, but I connected through SSH to the router and I did the following:
Code:
ASUSWRT-Merlin RT-AC68U 386.2_6 Sun Jun  6 16:34:17 UTC 2021
[email protected]:/tmp/home/root# /tmp/home/root# robocfg show
-sh: /tmp/home/root#: not found
[email protected]:/tmp/home/root# robocfg show
Switch: enabled
Port 0: 1000FD enabled stp: none vlan: 2 jumbo: off mac: 2c:21:83:69:2f:c5
Port 1: 1000FD enabled stp: none vlan: 1 jumbo: off mac: dc:a6:23:86:fa:27
Port 2:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 3:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 4:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 5: 1000FD enabled stp: none vlan: 2 jumbo: off mac: 40:16:5e:85:4e:82
Port 7:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 8:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
VLANs: BCM5301x enabled mac_check mac_hash
   1: vlan1: 1 2 3 4 5t
   2: vlan2: 0 5
  56: vlan56: 0 5 7 8t
  57: vlan57: 0 1t 3 4 5t 7t 8t
  58: vlan58: 0 4t 5t 7t 8u
  59: vlan59: 1t 4t 8u
  60: vlan60: 0 1t 2 3t 5t 8t
  61: vlan61: 0 1t 2t 4 7
  62: vlan62: 0 1 3 5t 8u
[email protected]:/tmp/home/root# brctl show
bridge name    bridge id        STP enabled    interfaces
br0        8000.40167e583e28    yes        vlan1
                            eth1
                            eth2

What can I do to troubleshot these issues?
 

CoyoteDen

Occasional Visitor
Those VLANs looks very different than my AC66_B1. I didn’t think ports 7 and 8 were even connected in these models, but it seems to be using them for something.

Does your ISP have IPTV requirements, and did you change the IPTV settings? If so, and you can’t get a WAN IP, you probably don’t have them set correctly.
 

ckennylin

Occasional Visitor
Downgrade to Merlin 384.19 and wait for the fixes to be rolled into an upcoming release. Some other posts suggest it may be some interactions with the Guest Network and the WAN DHCP, but many of us are not sophisticated or have the time to tinker with that level of details.

We saw this back in March and there's been a handful of threads on 386.x and Fios.

If you do have a spare Verizon router, you can avoid the problem by double-NAT i.e. the Asus behind a Verizon router, since Merlin supports DDNS through such configurations and stock does not.

Hope this helps!
 

MamaLing

New Around Here
Those VLANs looks very different than my AC66_B1. I didn’t think ports 7 and 8 were even connected in these models, but it seems to be using them for something.

Does your ISP have IPTV requirements, and did you change the IPTV settings? If so, and you can’t get a WAN IP, you probably don’t have them set correctly.
I don't have IPTV service.
 

MamaLing

New Around Here
Downgrade to Merlin 384.19 and wait for the fixes to be rolled into an upcoming release. Some other posts suggest it may be some interactions with the Guest Network and the WAN DHCP, but many of us are not sophisticated or have the time to tinker with that level of details.

We saw this back in March and there's been a handful of threads on 386.x and Fios.

If you do have a spare Verizon router, you can avoid the problem by double-NAT i.e. the Asus behind a Verizon router, since Merlin supports DDNS through such configurations and stock does not.

Hope this helps!
Yes, I've read several threads and the guest network problem seems to be valid, even in my case there's no guest network enabled. I just want a stable internet connection and home network. I really don't want to go into the details and spend hours to find out what they've messed up in the firmware. I will probably go and downgrade the firmware.
 

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