What's new

RT-AC3200 - Connection: Ethernet link down. / Connection: ISP's DHCP did not function properly.

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

KAZUNA

New Around Here
Since I started using RT-AC3200, my internet connection intermittently drops for 10s-120s several times a day.
Tested firmwares both Merlin 378.55.0 and ASUS 3.0.0.4.378.7838 but they both exhibit the same problem.
Changing cables (CAT5e/CAT5e STP/CAT6) has no improvement at all.
I suspected if it was something to do with Dual WAN but turning it off doesn't help at all.

While I'm testing various scenarios, I found some interesting facts.

When the connection drops with static IP WAN, I see:
Sep 29 23:19:02 WAN(0) Connection: Ethernet link down.
Sep 29 23:19:02 stop_nat_rules: apply the redirect_rules!
Sep 29 23:19:09 WAN(0) Connection: WAN was restored.
Sep 29 23:19:09 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan2_vlan2)!
Notice there is no correspond "Ethernet link up" message!

When the connection drops with dynamic IP WAN, I see:
Sep 26 05:58:27 WAN(0) Connection: ISP's DHCP did not function properly.
Sep 26 05:58:27 stop_nat_rules: apply the redirect_rules!
Sep 26 05:58:34 WAN(0) Connection: WAN was restored.
Sep 26 05:58:34 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan2_vlan2)!
Notice "Ethernet link down" message changes to "ISP's DHCP did not function properly" message.

If I physically disconnect and connect LAN cable with static IP WAN, I see:
Sep 29 23:16:33 WAN(0) Connection: Ethernet link down.
Sep 29 23:16:33 stop_nat_rules: apply the redirect_rules!
Sep 29 23:16:41 WAN(0) Connection: Ethernet link up.
Sep 29 23:16:41 rc_service: wanduck 522:notify_rc restart_wan_if 0
Sep 29 23:16:41 dnsmasq[534]: read /etc/hosts - 5 addresses
Sep 29 23:16:41 dnsmasq[534]: read /etc/hosts.dnsmasq - 6 addresses
Sep 29 23:16:41 dnsmasq-dhcp[534]: read /etc/ethers - 6 addresses
Sep 29 23:16:41 dnsmasq[534]: using nameserver 8.8.4.4#53 for domain local
Sep 29 23:16:41 dnsmasq[534]: using nameserver 8.8.8.8#53 for domain local
Sep 29 23:16:41 dnsmasq[534]: using nameserver 8.8.4.4#53 for domain local
Sep 29 23:16:41 dnsmasq[534]: using nameserver 8.8.8.8#53 for domain local
Sep 29 23:16:41 dnsmasq[534]: using local addresses only for domain MyHome
Sep 29 23:16:41 dnsmasq[534]: using nameserver 8.8.8.8#53
Sep 29 23:16:41 dnsmasq[534]: using nameserver 8.8.4.4#53
Sep 29 23:16:41 dnsmasq[534]: using nameserver 8.8.8.8#53
Sep 29 23:16:41 dnsmasq[534]: using nameserver 8.8.4.4#53
Sep 29 23:16:41 miniupnpd[16851]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Sep 29 23:16:41 miniupnpd[16851]: Failed to get IP for interface vlan2
Sep 29 23:16:41 miniupnpd[16851]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Sep 29 23:16:43 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan2_vlan2)!
Sep 29 23:16:43 dnsmasq[534]: read /etc/hosts - 5 addresses
Sep 29 23:16:43 dnsmasq[534]: read /etc/hosts.dnsmasq - 6 addresses
Sep 29 23:16:43 dnsmasq-dhcp[534]: read /etc/ethers - 6 addresses
Sep 29 23:16:43 dnsmasq[534]: using nameserver 8.8.4.4#53 for domain local
Sep 29 23:16:43 dnsmasq[534]: using nameserver 8.8.8.8#53 for domain local
Sep 29 23:16:43 dnsmasq[534]: using nameserver 8.8.4.4#53 for domain local
Sep 29 23:16:43 dnsmasq[534]: using nameserver 8.8.8.8#53 for domain local
Sep 29 23:16:43 dnsmasq[534]: using local addresses only for domain MyHome
Sep 29 23:16:43 dnsmasq[534]: using nameserver 8.8.8.8#53
Sep 29 23:16:43 dnsmasq[534]: using nameserver 8.8.4.4#53
Sep 29 23:16:43 dnsmasq[534]: using nameserver 8.8.8.8#53
Sep 29 23:16:43 dnsmasq[534]: using nameserver 8.8.4.4#53
Sep 29 23:16:43 wan: finish adding multi routes
Sep 29 23:16:43 miniupnpd[16851]: shutting down MiniUPnPd
Sep 29 23:16:43 miniupnpd[15039]: could not open lease file: /var/lib/misc/upnp.leases
Sep 29 23:16:43 miniupnpd[15039]: HTTP listening on port 51958
Sep 29 23:16:43 miniupnpd[15039]: Listening for NAT-PMP/PCP traffic on port 5351
Sep 29 23:16:43 ddns update: ez-ipupdate: starting...
Sep 29 23:16:43 ddns update: connected to nwsrv-ns1.asus.com (103.10.4.108) on port 80.
Sep 29 23:16:43 ddns update: Asus update entry:: return: HTTP/1.1 200 OK^M Date: Wed, 30 Sep 2015 06:16:38 GMT^M Server: Apache/2.4.9 (Unix) PHP/5.5.14 OpenSSL/1.0.1h^M X-Powered-By: PHP/5.5.14^M Content-Length: 0^M Connection: close^M Content-Type: text/html^M ^M
Sep 29 23:16:43 ddns update: retval= 0, ddns_return_code (,200)
Sep 29 23:16:43 ddns update: asusddns_update: 0
Sep 29 23:16:44 ddns: ddns update ok
Sep 29 23:16:45 WAN(0) Connection: WAN was restored.
Notice there *is* correspond "Ethernet link up" message. Also it does whole bunch of initialization to restore WAN connection.

It looks to me these logical connection drops are quite different than the physical connection drops.
I guessing these Ethernet link down and DHCP not function messages are just misleading and the firmware seems not handling connection state very well.

Has anyone found possible workaround for this connection issue?
 
Link down reports are almost always caused by the modem rebooting itself. This can happen with defective DSL modems, or with cable modems that lose their signal with the ISP.
 
Does it make sense that the connection can be restored without link up message?
What do you think about DHCP not function message in case of dynamic IP?
 
Have you checked your modem logs and modem signal levels for a problem?
 
Does it make sense that the connection can be restored without link up message?
What do you think about DHCP not function message in case of dynamic IP?

The DHCP error message is very generic, and comes up whenever a DHCP lease cannot be obtained, regardless of the reason.

Lack of link up message could simply be a timing issue. I'd focus on the fact that there is a link down message there.
 
The DHCP error message is very generic, and comes up whenever a DHCP lease cannot be obtained, regardless of the reason.
Yes, it sounds reasonable. But in this case DHCP error message seems caused by the link down and nothing to do with the DHCP lease time because DHCP error message is not aligned with DHCP lease timing.
 
Right, My personal guest is, the modem is rebooting itself, by the time it comes back online on the Ethernet port the router sends a DHCP lease request, but the modem's link isn't fully established with the ISP yet, hence the DHCP-related error message.
 
I just flashed my AC3200 to the latest firmware 3.0.0.4.378_9135 and the message is changed like this:
Oct 1 09:46:25 WAN(0) Connection: Detected that the WAN Connection Type was PPPoE. But the PPPoE Setting was not complete.
Oct 1 09:46:25 DualWAN: skip single wan wan_led_control - WANRED off
Oct 1 09:46:26 stop_nat_rules: apply the redirect_rules!
Oct 1 09:46:33 WAN(0) Connection: WAN was restored.
Oct 1 09:46:33 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan2_vlan2)!
Oct 1 09:46:33 ntp: start NTP update
There is no Ethernet link down message anymore and it is replaced with PPPoE error message which seems odd because I set Primary WAN to Static IP and Secondary WAN to Dynamic IP.
In any case, this issue seems nothing to do with link down but the firmware itself appears getting into some odd state.
Could this PPPoE error message lead to any possible connection issue?
 

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