[Alpha] Preview builds for Asuswrt-Merlin 380.61

[Wutikorn]

I was running stock 3.0.0.4.380_3831 and AC68U had problems with obtaining automatic WAN IP from bridged Dovado with LTE USB modem. Whenever the connection went down due to rebooting Dovado, I was getting the following errors:

WAN Connection: ISP's DHCP did not function properly.

After a series of such errors, I saw on WAN page that it has started cloning some random MAC addresses. Sometimes switching off / on WAN helped, sometimes only rebooting Asus worked. This lead me to conclusion it must be Asus WAN bug.

But I am confused now, RMerlin says that 380.61_alpha1 is based on 3831 (which I had problems with), however since flashing 380.61_alpha1 2 days ago and performing factory reset, I have not had any single issues with obtaining WAN IP by Asus. I already rebooted Dovado many times to see if Asus pick up WAN IP, rebooted Asus, used WAN failover, load balancing, performed multiple tests of wan1 down/up and it worked every single time. So I am confused because the issue is gone but apparently it is based on 3831.

@bayern1975 , I had similar issue using pppoe with RT-AC56U. I don't know why but what helped was to change "yes" to "no" for: "Enable VPN + DHCP Connection" on WAN page.

Probably because RMerlin has already fixed the problem. I'm not sure if this was mentioned lately, but I think RMerlin said in some blog that he will send a patch to fix WAN issue to Asus and hope Asus will use it.

With an RT-N66 running 380.59, is a full reset necessary or can I "dirty" flash over top ?

I did not do any reset from 380.60beta2 to 380.59 then to 380.61 alpha1. If I remember correctly, you should reset if your NVRAM, found in "Tools", is full.

 

[RMerlin]

With an RT-N66 running 380.59, is a full reset necessary or can I "dirty" flash over top ?

Flashing without a reset should generally be fine.

 

[RMerlin]

Probably because RMerlin has already fixed the problem. I'm not sure if this was mentioned lately, but I think RMerlin said in some blog that he will send a patch to fix WAN issue to Asus and hope Asus will use it.

Asus did merge both of my changes in 3831, so these two specific fixes are part of the stock firmware as well. His issue came from something else. I've done very little changes of my own to the rest of the WAN code, so chances are his issue was either timing-related, or simply required a complete reboot to clear things up.

 

[princi]

No AC88U or AC3200 support yet - good thing I am on holiday!

I have an AC68U but I only run Sabai on that.

 

[bayern1975]

No AC88U or AC3200 support yet - good thing I am on holiday!

i am waiting too....but ASUS have to push online firmwares for those routers first....

 

[rx2]

I am running the RT-AC68U in bridge mode with a TP Link W8960N and getting frequent disconnections. It sounds like others are also experiencing this. Below is the system log. Hopefully this may be helpful to someone who is trying to resolve this error. Tomorrow I will be trying it with a new ISP and modem, so will be interested to see if it still occurs. I am open to suggestions in trying to get this to work.

Jul 24 20:09:18 pppd[521]: Serial link appears to be disconnected.
Jul 24 20:09:18 miniupnpd[9230]: Failed to get IP for interface ppp0
Jul 24 20:09:18 miniupnpd[9230]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jul 24 20:09:21 WAN Connection: Fail to connect with some issues.
Jul 24 20:09:21 stop_nat_rules: apply the redirect_rules!
Jul 24 20:09:24 pppd[521]: Connection terminated.
Jul 24 20:09:24 pppd[521]: Modem hangup
Jul 24 20:09:34 pppd[521]: Connected to 58:ac:78:22:90:dd via interface eth0
Jul 24 20:09:34 pppd[521]: Connect: ppp0 <--> eth0
Jul 24 20:09:50 pppd[521]: Connection terminated.
Jul 24 20:09:50 pppd[521]: Modem hangup
Jul 24 20:10:00 pppd[521]: Connected to 70:e4:22:8b:e0:cf via interface eth0
Jul 24 20:10:00 pppd[521]: Connect: ppp0 <--> eth0
Jul 24 20:10:01 pppd[521]: CHAP authentication succeeded
Jul 24 20:10:01 pppd[521]: peer from calling number 70:E4:22:8B:E0:CF authorized
Jul 24 20:10:01 miniupnpd[9230]: Failed to get IP for interface ppp0
Jul 24 20:10:01 miniupnpd[9230]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jul 24 20:10:01 miniupnpd[9230]: Failed to get IP for interface ppp0
Jul 24 20:10:01 miniupnpd[9230]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jul 24 20:10:01 miniupnpd[9230]: Failed to get IP for interface ppp0
Jul 24 20:10:01 miniupnpd[9230]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jul 24 20:10:01 pppd[521]: local  IP address 202.159.136.119
Jul 24 20:10:01 pppd[521]: remote IP address 150.101.32.14
Jul 24 20:10:01 pppd[521]: primary   DNS address 192.231.203.132
Jul 24 20:10:01 pppd[521]: secondary DNS address 192.231.203.3
Jul 24 20:10:01 miniupnpd[9230]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Jul 24 20:10:01 miniupnpd[9230]: Failed to get IP for interface ppp0
Jul 24 20:10:01 miniupnpd[9230]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jul 24 11:10:01 rc_service: ip-up 9517:notify_rc start_firewall
Jul 24 20:10:01 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Jul 24 11:10:02 wan: finish adding multi routes
Jul 24 11:10:02 rc_service: ip-up 9517:notify_rc stop_upnp
Jul 24 11:10:02 rc_service: waitting "start_firewall" via ip-up ...
Jul 24 11:10:03 rc_service: ip-up 9517:notify_rc start_upnp
Jul 24 11:10:03 rc_service: waitting "stop_upnp" via ip-up ...
Jul 24 20:10:03 miniupnpd[9230]: shutting down MiniUPnPd
Jul 24 11:10:04 ddns update: ez-ipupdate: starting...
Jul 24 20:10:04 miniupnpd[9554]: HTTP listening on port 43523
Jul 24 20:10:04 miniupnpd[9554]: Listening for NAT-PMP/PCP traffic on port 5351
Jul 24 11:10:05 ddns update: connected to updates.dnsomatic.com (67.215.92.215) on port 80.
Jul 24 11:10:06 ddns update: request successful
Jul 24 11:10:06 ddns update: asusddns_update: 0
Jul 24 20:10:06 WAN Connection: WAN was restored.
Jul 24 11:10:06 ddns: ddns update ok
Jul 24 20:10:06 ntp: start NTP update
Jul 24 20:10:10 rc_service: ip-up 9517:notify_rc start_firewall
Jul 24 20:10:11 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!

 

[Wutikorn]

I am running the RT-AC68U in bridge mode with a TP Link W8960N and getting frequent disconnections. It sounds like others are also experiencing this. Below is the system log. Hopefully this may be helpful to someone who is trying to resolve this error. Tomorrow I will be trying it with a new ISP and modem, so will be interested to see if it still occurs. I am open to suggestions in trying to get this to work.

Do you mean that TP Link W8960N is in bridge mode, while RT-AC68U is in router mode? What firmware are you on? I don't think I can help much, but these are something that others may ask to help you.

 

[R1-Limited]

Upgraded direct from Latest Asus Code to Merlin Alpha OK
Monitoring so far no runs no drips no errors. VoIP tests are all Okie Dokie

 

[bayern1975]

I am running the RT-AC68U in bridge mode with a TP Link W8960N and getting frequent disconnections. It sounds like others are also experiencing this. Below is the system log. Hopefully this may be helpful to someone who is trying to resolve this error. Tomorrow I will be trying it with a new ISP and modem, so will be interested to see if it still occurs. I am open to suggestions in trying to get this to work.

Jul 24 20:09:18 pppd[521]: Serial link appears to be disconnected.
Jul 24 20:09:18 miniupnpd[9230]: Failed to get IP for interface ppp0
Jul 24 20:09:18 miniupnpd[9230]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jul 24 20:09:21 WAN Connection: Fail to connect with some issues.
Jul 24 20:09:21 stop_nat_rules: apply the redirect_rules!
Jul 24 20:09:24 pppd[521]: Connection terminated.
Jul 24 20:09:24 pppd[521]: Modem hangup
Jul 24 20:09:34 pppd[521]: Connected to 58:ac:78:22:90:dd via interface eth0
Jul 24 20:09:34 pppd[521]: Connect: ppp0 <--> eth0
Jul 24 20:09:50 pppd[521]: Connection terminated.
Jul 24 20:09:50 pppd[521]: Modem hangup
Jul 24 20:10:00 pppd[521]: Connected to 70:e4:22:8b:e0:cf via interface eth0
Jul 24 20:10:00 pppd[521]: Connect: ppp0 <--> eth0
Jul 24 20:10:01 pppd[521]: CHAP authentication succeeded
Jul 24 20:10:01 pppd[521]: peer from calling number 70:E4:22:8B:E0:CF authorized
Jul 24 20:10:01 miniupnpd[9230]: Failed to get IP for interface ppp0
Jul 24 20:10:01 miniupnpd[9230]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jul 24 20:10:01 miniupnpd[9230]: Failed to get IP for interface ppp0
Jul 24 20:10:01 miniupnpd[9230]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jul 24 20:10:01 miniupnpd[9230]: Failed to get IP for interface ppp0
Jul 24 20:10:01 miniupnpd[9230]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping

hmmm, you have same errors and disconnectivity as me at 380.60 betas....what version of firmware you installed?

 

[primitivo]

I am running the RT-AC68U in bridge mode with a TP Link W8960N and getting frequent disconnections. It sounds like others are also experiencing this. Below is the system log. Hopefully this may be helpful to someone who is trying to resolve this error. Tomorrow I will be trying it with a new ISP and modem, so will be interested to see if it still occurs. I am open to suggestions in trying to get this to work.
[...]

I think Asus broke something some time ago and didn't fix it properly. It is impossible that so many people with bridged modems connected to Asus WAN has so many problems with disconnections and DHCP automatic IP retrieval.

Jul 24 14:36:09 WAN(0) Connection: ISP's DHCP did not function properly.
Jul 24 14:36:09 stop_nat_rules: apply the redirect_rules!
Jul 24 14:37:26 rc_service: wanduck 433:notify_rc restart_wan_if 0
Jul 24 14:37:26 miniupnpd[696]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Jul 24 14:37:26 miniupnpd[696]: Failed to get IP for interface vlan2
Jul 24 14:37:26 miniupnpd[696]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping

Jul 24 14:37:33 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan3_vlan3)!
Jul 24 14:37:33 wan: finish adding multi routes
Jul 24 14:37:34 rc_service: udhcpc 18532:notify_rc stop_upnp
Jul 24 14:37:34 rc_service: waitting "start_firewall" via udhcpc ...
Jul 24 14:37:35 rc_service: udhcpc 18532:notify_rc start_upnp
Jul 24 14:37:35 rc_service: waitting "stop_upnp" via udhcpc ...
Jul 24 14:37:35 miniupnpd[696]: shutting down MiniUPnPd
Jul 24 14:37:36 miniupnpd[18567]: HTTP listening on port 43274
Jul 24 14:37:36 miniupnpd[18567]: Listening for NAT-PMP/PCP traffic on port 5351
Jul 24 14:37:36 ddns update: ez-ipupdate: starting...
Jul 24 14:37:37 ddns update: connected to nwsrv-ns1.asus.com (103.10.4.108) on port 80.
Jul 24 14:37:38 WAN(1) Connection: WAN was restored.

Jul 24 18:34:25 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan2_vlan2)!
Jul 24 18:34:25 wan: finish adding multi routes
Jul 24 18:34:25 rc_service: udhcpc 24903:notify_rc stop_upnp
Jul 24 18:34:25 rc_service: waitting "start_firewall" via udhcpc ...
Jul 24 18:34:26 rc_service: udhcpc 24903:notify_rc start_upnp
Jul 24 18:34:26 rc_service: waitting "stop_upnp" via udhcpc ...
Jul 24 18:34:26 miniupnpd[18567]: shutting down MiniUPnPd
Jul 24 18:34:27 ddns update: ez-ipupdate: starting...
Jul 24 18:34:28 miniupnpd[24938]: HTTP listening on port 50971
Jul 24 18:34:28 miniupnpd[24938]: Listening for NAT-PMP/PCP traffic on port 5351
Jul 24 18:34:28 ddns update: connected to nwsrv-ns1.asus.com (103.10.4.108) on port 80.
Jul 24 18:34:28 ddns update: Asus update entry:: return: HTTP/1.1 200 OK^M Date: Sun, 24 Jul 2016 16:34:28 GMT^M Server: Apache^M Content-Length: 0^M Connection: close^M Content-Type: text/html^M ^M
Jul 24 18:34:28 ddns update: retval= 0, ddns_return_code (,200)
Jul 24 18:34:28 ddns update: asusddns_update: 0
Jul 24 18:34:29 WAN(0) Connection: WAN was restored.

Unfortunately I was not at home, so I can't verify that WAN0 had 4 hours outage. Troubleshooting such things is never easy really but what I have noticed in the latest stock 3831 is that I had plenty of failed DHCP IP requests from Dovado which runs in bridge mode. I have ticket with Dovado as well and they are going get Asus router for testing, as I am apparently not the only one reporting WAN IP DHCP issues to them.

Not sure what's the point of mentioning this here anyway, since Merlin doesn't touch WAN. As we can see, this case is probably very specific. There is never an issue if I place Dovado in router mode, but then I have double NAT. Both my primary and failover internet connections are 4G/LTE

It is even more complicated to troubleshoot such case in dual wan mode like the one above, as you may not always notice that failover connection kicked in. There is no built in email notification of WAN down/up.

 

[RMerlin]

I think Asus broke something some time ago and didn't fix it properly. It is impossible that so many people with bridged modems connected to Asus WAN has so many problems with disconnections and DHCP automatic IP retrieval.

Your issue might be specific to dual WAN, since very few people use it. Do things get more stable if you switch to singular WAN?

Being 4G/LTE based adds yet another layer of complexity. For years, I've seen a lot of random issues with USB-based WAN - that support never was very robust to begin with. Too many different modems with particularities.

 

[primitivo]

Your issue might be specific to dual WAN, since very few people use it. Do things get more stable if you switch to singular WAN?

Being 4G/LTE based adds yet another layer of complexity. For years, I've seen a lot of random issues with USB-based WAN - that support never was very robust to begin with. Too many different modems with particularities.

No, it doesn't. I have started using dual wan mode since 3 days anyway.

I am not using USB modem connected to AC68U. I am using Dovado Tiny AC in bridge mode + E398 USB modem connected to Dovado. Dovado makes very good products and firmware. There is not much to do by Asus in this case, except getting DHCP WAN IP from bridged Dovado. The 2nd WAN is B315 Huawei LTE which by default is in router mode and doesn't have bridge mode. Never issue with NATed IP in this case. Also never issue with the same if I put Dovado in router mode.

I checked Dovado logs and there is nothing about 4 hours LTE interval, failover is set to ping 8.8.8.8. But yes, I can't say it's 100% ASUS fault, because I am not sure. Based on the similar cases with failed DHCP WAN IP requests it is possible, but it could also be:

- Dovado fault
- LTE network outage (maybe modem was connected - based on Dovado logs but there was no internet, Dovado is bridged anyway so can't check it)
- Google DNS outage (doubtful)

 

[HallStevenson]

I did not do any reset from 380.60beta2 to 380.59 then to 380.61 alpha1. If I remember correctly, you should reset if your NVRAM, found in "Tools", is full.

Can you define "full" ? I mean, I know that 65536 out of 65336 is obviously full, but what's the threshold ? More than 50%, more than 75% ?

I have no problem doing a full wipe/reset - setting things back up is no big deal. The annoying part is that all of our WiFi devices have to be set up again. I don't know why that happens since a) the MAC address of the router doesn't change, b) I use the exact same SSIDs, and c) I use the same password. Laptops, phones, and so on are simple enough, but it's the devices like our Rokus (2 of them), a Dish DVR w/WiFi, smart TVs, and so on.

 

[XIII]

Installed 380.61 alpha 1 on my RT-AC66U. Running fine so far.

 

[Wangstang]

RMerlin,
I've been following your threads off and on for a few years as I started reading through them right as the AC66U(which I bought) was coming to market and I was trying to figure out which new router I wanted to purchase. It's clear that your understanding of the ASUS router lineup is amazingly broad and I appreciate your willingness to contribute to everyone with your updates.

I picked up an AC68R from my local Wal-Mart a couple of weeks ago for $75.00 new in the wrapper in the clearance section. It had very old firmware on it which I auto updated through the factory Asus UI. Now running 3.0.0.4.380_3831

Since the update I've been having issues with the internet connection dropping for about two to three minutes at a time several times a day since the update of the firmware. I've had some instances where it's even more frequent, like three times in an hour but the connection re-establishes a in a minute to a minute and a half. The connection to the router/LAN stays in place when this occurs, it's only my connection to the web that's dropping. I am running a publicly viewable guest network and a private full network. Both are designated to run on the 2.4 & 5 GHz bands. Cable Modem for what it's worth.

I'm looking at updating my firmware to the 380.61 update you've provided in hopes that it may resolve my connection issue. That said, I'm wondering if a "factory reset" would get the job done and frankly I'd like to see your walk through/description on how to do a factory reset the right way(manual vs through the UI) if you have one as I suspect I'd need to do one once I upgrade the firmware to 380.61 .

Any advice or thoughts?

Thanks in advance

 

[rx2]

hmmm, you have same errors and disconnectivity as me at 380.60 betas....what version of firmware you installed?

I have 380.61 Alpha installed....

 

[Wutikorn]

I had a problem today. For some reason, all my devices that connect to my router couldn't use the internet, while the only LAN device I have was able to surf internet normally. The router's status said that the WAN is connected, but I only see one WAN IP(169.254.207.xxx) instead of two normally(100.125.145.xxx, 169.254.207.xxx).

Jul 25 07:56:25 WAN(0) Connection: Fail to connect with some issues.
Jul 25 07:56:25 stop_nat_rules: apply the redirect_rules!

I could only find this that is related to WAN. There is nothing saying that WAN(0) connection is back, but my PC was able to use the internet normally.

Edit(add):I have ONU before my router, which I assume is in bridge mode as my router does PPPOE connection to my ISP's server and gets public WAN IP.

Any suggestion?

 

[Wutikorn]

Can you define "full" ? I mean, I know that 65536 out of 65336 is obviously full, but what's the threshold ? More than 50%, more than 75% ?

I have no problem doing a full wipe/reset - setting things back up is no big deal. The annoying part is that all of our WiFi devices have to be set up again. I don't know why that happens since a) the MAC address of the router doesn't change, b) I use the exact same SSIDs, and c) I use the same password. Laptops, phones, and so on are simple enough, but it's the devices like our Rokus (2 of them), a Dish DVR w/WiFi, smart TVs, and so on.

I'm not sure what exactly is the number, but when I just flashed the firmware and finished factory reset, NVRAM usage was around 52000bytes or less, I think anything below 60000bytes should be fine.

 

[stambeccuccio]

5 days 15 hours ... for me everything is ok

 

[bayern1975]

i never got more then 8 hours online....I think that will cancel subscription at my ISP and live without it....too many problems in recent months....