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.

  • You've apparently solved your problem, but I'm just curious: Why are you using dhclient? RPi OS (née Raspbian) has long used dhcpcd as the default DHCP client app. I wonder if all of your problems were due to using dhclient without telling the system you were making this change?
    – Seamus
    Mar 15, 2022 at 20:28

1 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
  • the new reservation is

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 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


    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


    pkill -e -KILL dhcpcd


    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 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

  • 1
    You'll get a chuckle from this, but your last paragraph held a complete solution. It turns out dhcpcd is running, so all I did was to delete *.lease* from /var/lib/dhcpcd5 [sic], reboot, and it picked up a new lease with the correct address. Yes, that trailing '5' is present, that's not a typo. That said, while a static IP will work, I'd prefer to have the DHCP server aware of what's going on. It should never hand out that address to anything else, since the last octet for the Pi is .60 and I keep .100 - .250 for the pool. Even so better safe than sorry.
    – dgnuff
    Mar 15, 2022 at 2:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .