udhcpc: no MSG_DONTROUTE when sending packet #1017
Conversation
This reverts a change made in Sep 2017 [1] which introduced MSG_DONTROUTE flag to prevent udhcpc from reaching out to servers on a different subnet. 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 ---- During lease extension, a fully configured client should be able to reach out to the server from which it recieved the lease for extension, regardless in which network it is; that's up to the gateway to find. [2] This patch ensures that. [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 Signed-off-by: Adi Shammout <adi.shammout@outlook.com>
|
Impressive work on tracking this down! LGTM. Did you send this upstream by any chance? I think the busybox authors should be made aware of this problem. cc @dedeckeh |
|
Thanks! Indeed, it wasn't easy to track down. It took a full weekend of Submitting patches to BusyBox isn't as straightforward as here. I attempted to join the BusyBox mailing list, but still no confirmation. Non-members can't send to it. If you're on the list, could you please link them this PR? I was gonna reach out to the maintainers directly, but figured it might be bad etiquette. |
|
@adiov Indeed nice work tracking this down; we can accept the patch but it would be ideal upstream busybox fixes this as well. |
|
This morning, I filed a bug and attached the patch in BusyBox's Bugzilla. Let's see how it that progresses. In the dumps I collected,
Having that said, I don't believe
I suggest that no flag is passed. |
|
Had this patch in local tree for 24 hours - All is well for me, in fact DHCPv4 renewals with my ISP are cleaner, going straight to the DHCP server. Before this change the direct route would fail and would fall back to a broadcast renewal. Tested-by: Kevin Darbyshire-Bryant ldir@darbyshire-bryant.me.uk |
|
As the issue is critical I've pushed the patch to both master and openwrt-18.06. If upstream busybox fixes the issue in another way we can backport the patch; thx |
|
Tested with default
|
|
@adiov Thanks for informing me; replaced the patch by the upstream "fix" |
TL;DR Don't set
MSG_DONTROUTEwhen sending packets, otherwise it forces the client into non-compliant behaviour that is rejected by properly configured servers, thus creating unnecessary interruptions and connection breakages.This patch reverts a change made in Sep 2017 which introduced
MSG_DONTROUTEflag to prevent udhcpc from reaching out to servers on a different subnet. 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_DONTROUTEappears 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: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. This patch ensures that.
It's worth noting that this correct behaviour exists in every mainstream DHCP client I checked, including the Internet System Consortium's.
P.S. 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 from half an hour ago shows it's working as expected without interruption: