[Bug 11081] New: udhcpc: MSG_DONTROUTE prevents RFC2131-compliant behaviour

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=11081

            Bug ID: 11081
           Summary: udhcpc: MSG_DONTROUTE prevents RFC2131-compliant
                    behaviour
           Product: Busybox
           Version: 1.28.x
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: Networking
          Assignee: unassigned at busybox.net
          Reporter: adi.se at outlook.com
                CC: busybox-cvs at busybox.net
  Target Milestone: ---

Created attachment 7621
  --> https://bugs.busybox.net/attachment.cgi?id=7621&action=edit
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.