How to release and renew DHCP lease using dhclient, without loosing connectivity

Question

I want to be certain this will work before I try it, since I'm dealing with a headless Pi (Zero W if it matters) that is only ever accessed via SSH.

I've set up an address reservation in my router for the Pi, this is more or less essential, both to simplify access via Putty, and for accessing the custom server running on the Pi.

The problem is that originally there wasn't a reservation, so it's at some other random address in the pool, rather than the fixed address in the "non-pool" area I've set aside for it. And patience hasn't fixed the issue: it's been steadfastly holding onto that address for several days now, rather than changing. I'm assuming a reasonable lease length e.g. 12 or 24 hours on the part of the DHCP server in the router here.

Obviously, if I just use dhclient -r to release the lease, my current SSH session will abort, leaving things is a less than useful state. I also note that if you dhclient -r there is a risk that it'll bring down the WiFi connection as well: see the warning at the bottom of this page for details.

So what is the likelihood that nohup (dhclient -r -d && dhclient) & typed into a root bash session will (a) terminate the current lease, and then (b) attempt to turn WiFi back on if needed, and finally (c) obtain a new lease, hopefully with the correct address.

My reasoning is that using nohup means it won't receive a SIGHUP when the SSH session goes south, and putting it in a sub-shell in background means it has the highest chance of getting both commands executed.

Another option I've considered is nohup (dhclient -r && reboot) & in a root bash session, the logic there is that rebooting the system should re-establish the WiFi connection, and then ping the DHCP server for an address. Hopefully the reserved one.

Failing both of these, what other options do I have to release and renew the lease, and finish with a running system connected to WiFi at the preferred address? As a last resort, I can see if I can figure how to attach a screen and keyboard, but I really don't want to have to do that, it'd be a fairly major pain.

Answer 1

Disclaimer: I can't test it, but as only the last optional step would change any permanent configuration, worse that can happen is to have to reset the system.

Let's suppose for illustration that:

• the wireless interface is called wlan0
• the old address is 192.168.1.242/24
• the new reservation is 192.168.1.2/24

Everything should be run as root user. The method would be:

• Add a static IP address with the reserved address: since it's reserved, who cares?

  ip address add 192.168.1.2/24 dev wlan0
  

• enable promote_secondaries on the interface (else when the first address configured on an IP LAN is removed, all other addresses in the same IP LAN are also removed: the new address would be deleted too)

  sysctl -w net.ipv4.conf.wlan0.promote_secondaries=1
  

  or:

  echo 1 > /proc/sys/net/ipv4/conf/wlan0/promote_secondaries
  

• connect using the new address

  ssh [email protected]
  

  and become root again. From now on proceed from the new connection, on a root shell.

• SIGKILL the DHCP client, to ensure it can't do anything when killed (like bringing the interface down).

  It's not clear if dhclient, dhcpcd, udhcpc, yet an other DHCP client is in use, or even if one is still running (some minimal configurations could just get an IP address once and exit without handling lease renewal or expiration at all).

  pkill -e -KILL dhclient
  

  or

  pkill -e -KILL dhcpcd
  

  etc.

  or if there's no pkill command, figure out the PID to kill (using kill -KILL ...).

  It's important to be sure there's no client left running from now on.

• delete manually the older address (which gets the newer promoted as primary instead of being deleted too)

  ip address del 192.168.1.242/24 dev wlan0
  

• optional: update configuration to static address if needed, or just don't do anything

  As it's RaspberryPi Zero W related, I don't know how to do this last step (it could use Debian's ifupdown and have configuration in /etc/network/interfaces or be configured differently). But without any change anyway, on next (re)boot this will either adopt the new lease with this new IP address, or if there's really a bug revert to the older.

  If DHCP is handled by dhclient, wiping the lease memory by removing the relevant files in /var/lib/dhcp/dhclient*.leases should force it to ask a new lease next time. For dhcpcd that would likely be /var/lib/dhcpcd/*.lease