Created attachment 7621 [details] Patch to fix the issue A change made in Sep 2017 which introduced MSG_DONTROUTE flag to prevent udhcpc from reaching out to servers on a different subnet [1]. That change violates RFC2131 by forcing fully configured clients, who got their configurations through an offer relayed by a DHCP relay, from renewing through a unicast request directly to the DHCP server, resulting in the client resorting to boradcasting lease extension requests instead of unicasting them, further breaking RFC2131. The problem with MSG_DONTROUTE appears when talking to a properly configured DHCP server that rejects non-compliant requests. Such server will reject lease extension attempts sent via broadcast rather than unicast, as is the case with Finnish ISPs Telia and DNA as well as Estonian ISP Starman. Once the lease expires without renewal, udhcpc enters init mode, taking down the interfaces with it, and thus causing interruption on every lease expiry. On some ISPs (such as the ones mentioned above) that can be once every 10-20 minutes. The interruptions appear in the logs as such: ---- udhcpc: sending renew to x.x.x.x udhcpc: send: Network unreachable udhcpc: sending renew to 0.0.0.0 udhcpc: sending renew to 0.0.0.0 ... udhcpc: lease lost, entering init state Interface 'wan' has lost the connection Interface 'wan' is now down Network alias 'eth0' link is down udhcpc: sending select for y.y.y.y udhcpc: lease of y.y.y.y obtained, lease time 1200 Network alias 'eth0' link is up Interface 'wan' is now up ---- This keeps repeating every lease period, breaking VPN connections, SSH sessions, etc. During lease extension, a fully configured client should be able to reach out to the server from which it received the lease for extension, regardless in which network it is; that's up to the gateway to find. [2] It's worth noting that the correct behaviour I described exists in every mainstream DHCP client I checked, including the Internet System Consortium's. [3] P.S. I've attached a patch fixing this. I've made the change locally, built it, and have been testing it on my Archer C7 v2 for quite a while. This part of the logs shows it's working as expected without interruption: ---- Wed Jun 6 22:39:07 2018 daemon.notice netifd: wan (1299): udhcpc: sending renew to x.x.x.x Wed Jun 6 22:39:07 2018 daemon.notice netifd: wan (1299): udhcpc: lease of y.y.y.y obtained, lease time 1200 Wed Jun 6 22:49:07 2018 daemon.notice netifd: wan (1299): udhcpc: sending renew to x.x.x.x Wed Jun 6 22:49:07 2018 daemon.notice netifd: wan (1299): udhcpc: lease of y.y.y.y obtained, lease time 1200 Wed Jun 6 22:59:07 2018 daemon.notice netifd: wan (1299): udhcpc: sending renew to x.x.x.x Wed Jun 6 22:59:07 2018 daemon.notice netifd: wan (1299): udhcpc: lease of y.y.y.y obtained, lease time 1200 ---- [1] http://lists.busybox.net/pipermail/busybox-cvs/2017-September/037402.html [2] https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents [3] https://fossies.org/linux/dhcp/client/dhclient.c
PR with some discussion and more info under OpenWRT https://github.com/openwrt/openwrt/pull/1017
Recent instances of this issue manifesting in the described scenarios: https://forum.lede-project.org/t/strange-log-entry-for-wan-lease-renew/15660 https://forum.lede-project.org/t/how-can-i-reduce-chattyness-of-udhcpc/15629
Sounds convincing. I reverted the change which used MSG_DONTROUTE. Please try current git and reopen if there is still problems.