A device that usually gets the same local address can suddenly get a different
one. That's inconvenient when a printer, NAS, home-automation hub, or bookmark
expects the old address. Before you edit the DHCP reservation, check whether
the device uses a private Wi-Fi address on this particular network. The
reservation may still be correct. It may just point to a different Wi-Fi
address than the one the router sees today.
This guide is for a network you own or are authorized to administer. A changed
address does not necessarily mean something is broken or an unauthorized
device has connected. The aim is to establish how one network, Wi-Fi address,
and DHCP lease currently relate to each other, then make one deliberate
change if needed.
The three separate records
A DHCP reservation is a rule on a DHCP server: when a recognized client
requests configuration, the server should offer a chosen address. DHCP defines
how the server and client exchange that information. A lease isn't a permanent
label on a physical device. The router may also keep showing an old lease
after the client disconnects, depending on its interface and how much lease
time remains.
A Wi-Fi address is a separate record. A device uses it when associating with
an access point. Some operating systems can use a private or randomized
address to reduce tracking across networks. Apple documents a separate private
Wi-Fi address for each network, with fixed and rotating modes on current
systems. The setting and exactly how it behaves depend on the device,
operating-system version, and saved network. An address change doesn't prove
that the device's hardware changed or that somebody joined the network.
In practice, a reservation for the hardware address may not match the private
address the device currently uses on the home SSID. The router can then assign
an ordinary address instead. And an unfamiliar router entry can still be the
same phone or laptop, using the private address selected for that network.
A record of the current connection
Open the router's DHCP or connected-client view. Write down the time, network
name or VLAN, displayed client name, IP address, address used by the client,
and lease state or expiration if shown. A privately stored screenshot can
help, but don't share router screenshots that contain passwords, public
addresses, serial numbers, or administration tokens.
Then check the device while it's connected to that same Wi-Fi network. On
current Apple systems, the network's Wi-Fi details show the private address
setting. The exact path and options vary by OS version. Android manufacturers
can display network details differently, so check the settings for the
connected network rather than looking for a label from an older screenshot.
Compare the device's current Wi-Fi address with the address in the router's
active entry. Check the reservation's location, too: it needs to be on the
DHCP server serving this network. A guest SSID, IoT VLAN, mesh satellite, or
second router may have a different DHCP authority. Comparing an address from
the main LAN with a reservation on a guest network won't explain the lease.
The address for the reservation
If the device and router show the same private Wi-Fi address, this is usually
a choice about local policy, not something to fix. You can associate a
reservation with the address the device presents on that trusted network.
A lasting MAC-based reservation requires a stable address for that network.
Where supported, use Fixed private addressing on the trusted network, then
reserve that address. If rotation remains enabled, the reservation can stop
matching after the private address rotates. Before saving, check that the
chosen address isn't already reserved for another client and falls within
the DHCP server's intended scope.
If the reservation holds an older address and the device now presents a
different private address, confirm the device and that its address is stable
for this network, then update only the reservation. Don't disable private
addressing, set a manual IP on the device,
and edit the router all in one attempt. Changing several things at once makes
it hard to tell which change restored connectivity. It can also create an
address conflict.
Some environments deliberately require a stable hardware address. Examples
include a managed network, a captive portal, or a narrowly defined access
policy. Follow that network's documented requirement. On a household network,
updating the reservation to match the address actually used on that SSID is
often less disruptive than weakening a privacy setting just to make the
router table match an old note.
Lease renewal and verification
After one confirmed reservation change, reconnect the device to Wi-Fi or
renew its DHCP lease through its normal controls. Check the router again.
Look for a specific result: the same client address appears, the intended IP
was offered, and the device can reach the local service it needs. The router
page needs to have refreshed since the change.
If the intended address still isn't offered, stop before assigning a manual
address. Check the reservation syntax and the relevant DHCP scope. Confirm
that the device is actually on the expected SSID or VLAN, and check whether
another DHCP server is present. A ping alone doesn't prove that the right
device owns an address. Verify from both the router and the device where
possible.
For a device that must remain discoverable, record the network name, the
address the router uses for its reservation, and the date you confirmed it.
Don't treat a MAC address as a person or a permanent identity. It's a network
clue, and its meaning depends on the interface and network in use.
An inventory for comparison
A small inventory gives you something to check when an entry changes later.
Note the device's role, SSID or segment, current reserved IP, and whether it
uses a private Wi-Fi address where relevant. Keep Wi-Fi passwords and router
administrator credentials out of the inventory. When a router entry changes,
compare it with the dated record and the device's own settings before
blocking anything.
DeviceShelf is one possible local comparison tool for an authorized network.
Check its observations against the router and the device itself. Sleeping
clients, guest-network isolation, and different network segments can all limit
what a scan can see. Use the scan as evidence for comparison, not as a reason
to overwrite a DHCP rule automatically.
Top comments (0)