I'm running 18.06.4 on a TP-Link TL-WR1043NDv2. Nothing fancy with my setup. Simply an Arris TM1602 cable modem plugged into the WAN interface, and several LAN clients of course.
I've had OpenWrt installed for probably about a year now, and I've always had one nagging issue. If the router is rebooted / power cycled, the WAN connection is lost until the network cable is physically unplugged and plugged back in. If the WAN interface is disconnected, the router then rebooted, and the WAN interface reconnected-- that works fine. If the cable modem is rebooted independently of the router, that's no problem either. The only situation that consistently shows the issue is when the router is rebooted with the WAN interface physically connected.
I've been trying to determine if this is an issue with the router or modem. I've tried (through ssh) restarting the network service, bringing down/up the WAN interface, and even delaying the start of the WAN interface on boot up to no avail. When in the broken state, I cannot ping the router (192.168.100.1) until I physically cycle the network cable.
Here are the WAN entries from /etc/config/network:
config interface 'wan'
option ifname 'eth0'
option proto 'dhcp'
option peerdns '0'
option dns '1.1.1.1 1.0.0.1'
config interface 'wan6'
option ifname 'eth0'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option peerdns '0'
option dns '2606:4700:4700::1111 2606:4700:4700::1001'
If I reboot the router, here are the DHCP-related message I'm seeing using logread:
root@LEDE:~# logread | grep dhcp
Fri Nov 15 13:30:30 2019 daemon.info dnsmasq[770]: read /tmp/hosts/dhcp.cfg01411c - 0 addresses
Fri Nov 15 13:30:35 2019 user.notice ucitrack: Setting up /etc/config/network reload dependency on /etc/config/dhcp
Fri Nov 15 13:30:36 2019 user.notice ucitrack: Setting up /etc/config/dhcp reload dependency on /etc/config/odhcpd
Fri Nov 15 13:30:38 2019 daemon.notice netifd: wan (1126): udhcpc: started, v1.28.4
Fri Nov 15 13:30:38 2019 daemon.err odhcp6c[1127]: Failed to send RS (Address not available)
Fri Nov 15 13:30:38 2019 daemon.notice netifd: wan (1126): udhcpc: sending discover
Fri Nov 15 13:30:39 2019 daemon.info odhcpd[930]: Using a RA lifetime of 0 seconds on br-lan
Fri Nov 15 13:30:39 2019 daemon.notice odhcpd[930]: Failed to send to ff02::1%br-lan (Address not available)
Fri Nov 15 13:30:39 2019 daemon.err odhcp6c[1127]: Failed to send DHCPV6 message to ff02::1:2 (Address not available)
Fri Nov 15 13:30:41 2019 daemon.notice netifd: wan (1126): udhcpc: sending discover
Fri Nov 15 13:30:43 2019 daemon.info dnsmasq-dhcp[1385]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h
Fri Nov 15 13:30:43 2019 daemon.info dnsmasq[1385]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Fri Nov 15 13:30:43 2019 daemon.info dnsmasq-dhcp[1385]: read /etc/ethers - 0 addresses
Fri Nov 15 13:30:43 2019 daemon.info dnsmasq[1385]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Fri Nov 15 13:30:43 2019 daemon.info dnsmasq-dhcp[1385]: read /etc/ethers - 0 addresses
Fri Nov 15 13:30:44 2019 daemon.notice netifd: wan (1126): udhcpc: sending discover
So udhcpc is showing "Failed to send RS (Address not available)" and a similar DHCPV6 message as well. As soon as I cycle the network cable, udhcpc immediately retrieves an IP from the modem.
Here's the ifstatus output for the interface (when in the broken state of course):
root@LEDE:~# ifstatus wan
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcp",
"device": "eth0",
"data": {
}
}
And finally, the ip addr show output for eth0:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
link/ether c0:4a:00:f3:93:f3 brd ff:ff:ff:ff:ff:ff
inet6 fe80::c24a:ff:fef3:93f3/64 scope link
valid_lft forever preferred_lft forever
I'm not knowledgeable enough to interpret all of the above, but my mostly-uneducated guess is that the physical re-connection of the network cable is sending some sort of event that suddenly makes either device aware of the other.
I'm a little lost on where to look next. Any suggestions or ideas of what could be going on?