[Bug 11221] New: udpcpc does not send DHCPRELEASE

[bugzilla at busybox.net]

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

            Bug ID: 11221
           Summary: udpcpc does not send DHCPRELEASE
           Product: Busybox
           Version: 1.28.x
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Networking
          Assignee: unassigned at busybox.net
          Reporter: falconict at gmail.com
                CC: busybox-cvs at busybox.net
  Target Milestone: ---

Created attachment 7686
  --> https://bugs.busybox.net/attachment.cgi?id=7686&action=edit
packet trace of 'kill -HUP <udhcpc_pid' when udhcpc has -R option

I'm using both BusyBox v1.25.1 packaged with LEDE 17.01.1, and Busybox v1.28.3
packaged with OpenWRT 18.06.0, on 2 routers connected to the internet in
active/passive configuration.  The OS's are virtualised within KVM, and their
WAN interface obtains an IP address from my upstream ISP using DHCP.  The DHCP
client for Busybox is of course udhcpc.

The IP address is obtained as normal on each router, however when I attempt to
release the IP address on an interface (by 'kill -USR2 <pid>', the IP address
is released on the interface from the client side, but no DHCPRELEASE message
(i.e. option 53:7) is sent to the upstream ISP.  This hinders my ability to
change traffic from one router to another, as I have to wait for the DHCP lease
to expire as normal before the ISP will accept traffic from a different router.

I have attempted some modifications in an attempt to trigger the DHCPRELEASE. 
The first was to modify the script initialising udhcpc, to include the '-R'
switch which is not included by default, and then kill the udhcpc process using
'kill -HUP <pid>', but again no DHCPRELEASE message was initiated.  What was
interesting though, looking at the packet trace, is that there was one
DHCPDISCOVER message issued with one transaction ID, and then a range of normal
DHCPDISCOVER, DHCPOFFER, DHCPREQUEST and DHCPACK, triggered by the respawned
udhcpc process, with a different transaction ID.  This leads me to suspect that
the -R switch is generating a DHCPDISCOVER on termination instead of a
DHCPRELEASE.

I have also attempted to run a second udhcpc process on the same interface, and
forcing the DHCPRELEASE option with the '-x' switch.  This does result in a
DHCP message containing the option 53:7, but the same message also contains a
53:1 option by default, so although Wireshark identifies the message as
DHCPRELEASE, it is really ambiguous and arbitrary on how the server handles it.

Is this a bug or expected behaviour?

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