DEV Community: DeviceShelf

MQTT Last Will Messages: What an Offline Alert Actually Means

DeviceShelf — Tue, 20 Oct 2026 09:00:10 +0000

An MQTT-based dashboard can mark a device offline within seconds of losing its connection. That's useful, especially when the device normally keeps a persistent connection to the broker. But it's easy to read too much into the alert. An offline MQTT message alone doesn't prove that a NAS lost power, a service stopped, or the whole network went down.

These alerts often come from MQTT's Last Will and Testament feature, usually called LWT. It lets a client leave the broker a message to publish if the connection ends unexpectedly. This guide covers what that message tells you, how to test it without disrupting a working setup, and how to keep an automation's conclusions within what its input actually shows.

The connection event visible to the broker

An MQTT client can supply a will message with a topic, payload, quality-of-service setting, and optional retained flag. If the broker detects that the connection ended without a normal disconnect, it can publish that message for the client. The broker is reporting what happened to a client connection. It isn't checking every process or network interface on the device.

The MQTT Version 5.0 specification defines will messages and the conditions for publishing them. It also covers session and delay options that can affect when a subscriber receives a will. Those settings matter if you're using the alert to trigger a time-sensitive response.

A publisher might, for example, connect with an online birth message and an offline will. If Wi-Fi drops, the device loses power, or a network path fails, the broker may eventually publish offline. That's good evidence that the broker didn't receive the expected graceful disconnect from that client. It doesn't tell you which cause was responsible. Nor does it tell you the state of a file share, web interface, or storage volume on the same machine.

Before turning a topic into an alert, write down exactly what it tells you. “MQTT client connection was lost” is a narrow claim you can test. “NAS is broken” rolls several separate questions into one and needs more evidence.

Graceful stops and unexpected connection loss

An application can normally disconnect from a broker cleanly. Depending on the client configuration and protocol settings, that can prevent the broker from publishing a will. The will is meant to report an ungraceful connection loss; it isn't a general shutdown log. You can't reliably use it to tell whether someone deliberately stopped a service.

Keepalive affects the timing, too. MQTT clients and brokers use it to detect a connection that has gone quiet. The broker won't necessarily detect the loss at the instant someone unplugs a cable. The delay depends on the configured interval, network timing, and broker behavior. Record when the subscriber received the message; record the broker's detection time separately only when supported by broker logs. Will Delay, delivery delays, and retained-message replay can separate those times.

Home Assistant documents an MQTT integration with birth and last-will messages, along with availability topics for MQTT entities. Its availability documentation explains the distinction between an entity's current value and the connection signal used to decide whether that value is available.

An offline will can be retained. That may be useful when a new subscriber needs the last known availability state. There's a catch, though: a subscriber can receive a stored offline value when it starts. That message reports the last recorded state, which doesn't necessarily mean a new outage happened when the subscriber connected.

A controlled test topic

Run tests only on a broker and network you administer. Pick a separate, clearly labeled test topic instead of a production device-control topic or a wildcard subscription. Don't reuse a topic that drives a lock, switch, alert escalation, or any other physical action.

Set up a disposable client with an online birth message and an offline will. Use a second authorized client to subscribe, and record the topic, payload, subscriber receipt time, retained indicator, and configured keepalive. Stop the publisher normally first. Check whether the broker publishes the will. In a separate test, interrupt the client's network path or terminate its process abruptly so it cannot send DISCONNECT, then watch whether the subscriber receives the will and when it arrives.

Mosquitto's subscriber manual documents a command-line client you can use to watch a test topic. Its output shows which messages it received. That doesn't prove every other subscriber reacted or that the device itself is unreachable through another route.

Use clear test payloads that contain no sensitive information. A short value like test-online or test-offline is safer than a real hostname, private address, inventory data, token, or credential. If you use a retained will for the test, clear the retained test value after recording the result. That's good housekeeping, but it won't undo any copies a subscriber has already processed.

Independent checks for the question at hand

Choose an independent check based on what you would do with the result. To find out whether a NAS file service is reachable, test the documented service through an authorized path. To check whether the host rebooted, compare an uptime record or system log. For a possible Wi-Fi change, look at the network equipment's current association information. Each answers a different question from an MQTT connection event.

You can also have an automation wait through a short, documented grace period before sending a notification. After the grace period, notify only if the offline condition still holds. This cuts down on noise from brief Wi-Fi changes or broker restarts. It doesn't make LWT a health check. One useful condition might require both an offline will and no fresh publisher timestamp after the expected interval. Test the rule with an intentionally short interruption and an ordinary graceful stop, as well as a broker or subscriber restart.

Don't test by blocking unfamiliar devices or changing router settings on a live household network. A controlled test client gives you a clear result with less risk of disrupting an authorized user. If a production result surprises you, save the topic, time, payload, client identifier where appropriate, and broker logs before changing several settings at once.

Restart behavior and retained availability

Broker and subscriber restarts are normal. They can briefly interrupt connections or cause retained availability messages to appear. Before attaching a notification to a topic, restart the subscriber during a test window and check whether it receives a previously retained state. Then, when it's safe and authorized, restart the broker and watch how the publishers reconnect.

This matters for Home Assistant automations. A trigger that runs when Home Assistant reconnects can process a value that was already there before the restart. An arriving message needs to be evaluated; it doesn't automatically mean there's a new incident. If the publisher supports it, a timestamp, a monotonic counter, or a separately modeled availability state can make the rule more specific.

DeviceShelf Server can publish network observations to a Home Assistant installation you administer. Treat it as one input among others. Compare an MQTT event with the observation time and the relevant device or service record; it doesn't guarantee device identity, availability, or security. The server documentation describes the supported integration path.

Conclusions supported by the evidence

A reliable troubleshooting note after an alert can be short: “At this time, the subscriber received an offline message on the configured availability topic.” Record the independent check and its result separately. MQTT 5 also permits a client to deliberately request Will publication using DISCONNECT reason code 0x04, and retained delivery need not coincide with publication. This wording therefore establishes neither an unexpected disconnect nor the publication time.

That's the practical value of LWT: it gives a managed system a standard way to communicate an unexpected MQTT disconnect. With a defined topic, a bounded test, and an independent follow-up observation, it can help you decide what to check next. On its own, a received offline message can indicate a broker connection problem, but may also reflect deliberate Will publication or a retained state. It doesn't establish the state of the whole device.

Sources checked

How to Read a Stale Router Device Entry Before Calling It Unknown

DeviceShelf — Sun, 18 Oct 2026 09:00:06 +0000

An unfamiliar name, address, or old-looking entry in your router can be unsettling.
But it doesn't tell you much on its own. Router interfaces often put several
kinds of information on the same screen: devices connected to Wi-Fi now, DHCP
leases issued earlier, remembered host names, and sometimes a history of
clients. A row on that screen can be useful evidence. By itself, though, it
doesn't show that a device is currently connected or belongs to an intruder.

Start with a narrower question: what kind of record is this, and when was it
last observed? Work that out before blocking an address, resetting the router,
or changing a password. The steps below are for a network you own or are
authorized to administer. The first checks are reversible, and each leaves you
with a record of what you actually observed.

The type of router list

Check the page label and its fields as well as the device name. A page called
DHCP leases, address reservations, or known clients can keep
information after a client goes offline. DHCP is the protocol a server uses
to assign an address for a lease time; RFC 2131 describes how clients obtain,
renew, and release those leases. A lease tells you the server allocated an
address. It doesn't necessarily mean there's a live Wi-Fi session.

A current Wi-Fi association list tells you something different. It may show
signal, band, connection time, or a short inactivity timer. An Ethernet switch’s MAC address table is another kind of observation. A router dashboard may combine all three
without making the differences clear. Write down the page name beside the
entry. When you compare it later, that detail helps you avoid treating a
remembered lease as evidence of a current connection.

Record the time, network name or VLAN, IP address, displayed hardware address,
host name, and any last-seen or expiration value. Keep the note private:
router screenshots can expose local addresses, Wi-Fi names, or administration
details. No timestamp? Put that in the note too. Leave that uncertainty in the
record instead of filling in a time from memory.

The lease lifetime

A device can leave the room while its DHCP lease stays on the screen. A phone
may be asleep, a laptop may have moved to another network, or a streaming box
may simply be powered off. The router normally decides when to reuse an
address based on how it handles leases. Manually deleting a row doesn't prove
anything about who used it.

Compare the entry's expiration or last-seen time with the time you recorded
your observation. A recent Wi-Fi association and packets moving through the
router are stronger evidence of current activity than an address under an old
lease. A lease that expired long ago but still appears on the screen, on the
other hand, may just be a remembered client. Router vendors use different
words for these fields. Read the labels as that vendor's descriptions, not as
status terms that mean the same thing on every router.

Don't create an address conflict to test the record. RFC 5227 describes IPv4
address-conflict detection used by hosts that implement it; deliberately
assigning the same address can interrupt a printer, NAS, or another legitimate
device. It's safer to observe what's there than to create a conflict.

The network boundary and a known device

First, check which device is actually assigning addresses. Homes with a
modem-router plus a separate Wi-Fi router, mesh system, guest network, or VLAN
can have more than one client list. A device may belong on one list and be
correctly absent from another. Note the SSID, subnet, and gateway of the
network you're checking before comparing results from a scanner or a computer.

Then test an ordinary explanation. Check household phones, tablets, printers,
consoles, watches, and IoT devices on the same network. With the owner's
permission, compare their Wi-Fi details, connection time, and displayed IP
address with the router entry. Keep private Wi-Fi addresses in mind too.
Apple documents private Wi-Fi addressing per network; a settings change,
forgetting and rejoining a network, or a different privacy mode can make a
familiar device appear under a different address. That doesn't prove the entry
is harmless. It does give you a reason to compare before blocking it.

Names and address prefixes are clues, not proof of identity. A host name can
be generic, copied from an older record, or set by a user. A private or
randomized address doesn't reliably identify a manufacturer. Write down what
matches and what you're still unsure about, rather than guessing who owns a
device from one label.

One limited, read-only observation

If the entry is still unclear, make one observation from an authorized computer
on the same network. Check the router's current association view, a managed
switch table, or a local network scan that you understand. Record the method
and time with the result. A device missing from a scan isn't a conclusive
result: sleeping devices, firewalls, client isolation, and separate subnets can
all affect what you can see.

Avoid broad service probing or logging into an unfamiliar device. If you
suspect a household printer or NAS, a less invasive way to check is to look at
that known device's own network settings or watch its entry while its owner
connects and disconnects it. DeviceShelf is one option for making another local
observation on a network you administer, but it can't turn an ambiguous router
record into a confirmed identity.

You don't need a sweeping conclusion. “Old DHCP lease; no current association observed”
is useful. So is “current connection observed; ownership not yet confirmed.”
For the next review, a dated note of what you did and didn't see is better
evidence than a confident label based on a single dashboard row.

Escalation based on the facts

If a current connection is still unexplained after those comparisons, review
who knows the Wi-Fi password, whether the guest network is separated, and
whether the router firmware and administrator credentials are current. NIST's
wireless LAN guidance provides a useful checklist for reviewing the network's
security configuration. Make changes through the router vendor's documented
interface, not through a link in a device name or a message about the device.

Changing a Wi-Fi password can make sense when there's evidence behind a concern
that an unauthorized person knows it. The change also disconnects legitimate
devices, so plan for it and reconnect them deliberately. Blocking one MAC
address isn't a complete security response: addresses can change, and a block
doesn't replace secure Wi-Fi and router administration. If you've explained
the record, keep a short inventory note. If you haven't, keep your observations
and seek appropriate local administration help. Be clear about what the router
list actually proved.

Sources

Private Wi-Fi Addresses and DHCP Reservations: Check the Match First

DeviceShelf — Fri, 16 Oct 2026 09:00:05 +0000

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.

Sources

How to Investigate an Unknown Device on Your Home Network

DeviceShelf — Wed, 14 Oct 2026 09:00:05 +0000

An unfamiliar entry in your router’s device list is worth checking. On its own, though, it doesn't mean somebody has gained access to the network. Router interfaces often mix current Wi-Fi associations with DHCP leases, remembered clients, and names supplied by devices. Any of those records can be incomplete or out of date. A phone using a private Wi-Fi address can look like a new device. A lease may still be listed after a laptop goes to sleep, and a name such as “android-1234” tells you very little.

Instead of asking “what is this, immediately?” start with “what did the router observe, on which network, and what can I safely compare it with?” This process is for a network you own or are authorized to administer. Start with observations and changes you can undo, rather than blocking or resetting devices before you have enough evidence.

A record of the first observation

Before changing a setting, record what the router shows. Note the date and time, network name or VLAN, displayed IP address, hardware address, device name, connection type, and any last-seen or lease-expiry field. A screenshot can help, provided you store it privately. When asking for help, don't post router screenshots that contain local addresses, Wi-Fi names, serial numbers, or administration details.

Check which list you're looking at, too. A page labeled DHCP leases isn't necessarily the same as one labeled connected devices. A DHCP lease records an address allocation with a lifetime. RFC 2131 describes how a client can renew, release, or receive that allocation, so an entry may remain visible after the device is no longer actively connected. A Wi-Fi client list may be more current. It still won't necessarily tell you who owns the device.

Write the source beside the observation: for example, “main-router DHCP lease list, 11 October, 09:40.” You'll need that context when comparing records later. A remembered lease isn't proof that a client is currently transmitting.

The network boundary

Many homes have more than one network. A guest SSID, an IoT segment, a mesh network, a second router, or a work VPN can change what appears in a particular list. Check which router or DHCP server is responsible for the network where you found the entry. On a computer you're authorized to use, note the local IPv4 address, prefix length or subnet mask, and default gateway.

Private IPv4 addresses are common, but seeing a prefix such as 192.168 doesn't tell you that two devices share a local segment. RFC 1918 reserves several private ranges. The prefix length and routing rules determine what's local from a given interface. A client on the guest network might be invisible to a scan from the main LAN, just as intended. Check whether that separation is deliberate before treating it as a fault.

If you have a modem-router and a separate Wi-Fi router, find out which one assigns addresses. Two DHCP servers on one simple network can give confusing results. But a second router serving a deliberately separate network can be normal. Different device lists aren't a reason to reset either router.

Ordinary explanations

Start with the devices your household already owns. It's easy to forget phones, tablets, watches, streaming boxes, printers, smart plugs, and visitors’ devices. While they're connected to the same network, check their Wi-Fi settings. Compare the connection time, IP address, and any displayed device name against the router's record. Ask the owner before disconnecting anything that isn't yours.

Pay particular attention to private Wi-Fi addressing. Apple documents that its devices can use a private Wi-Fi address for each network. A familiar device can appear with a different hardware address after a privacy setting changes, after forgetting and rejoining a network, or after restoring settings. That's a privacy feature. By itself, it isn't a sign of unauthorized access. Other platforms can behave similarly, so don't turn off a privacy feature just to tidy up the router's list.

Device names are clues, not identities. A name might come from the manufacturer or the user, or it might have been copied from an old lease. There may be no name at all. A MAC-address prefix can also hint at the interface vendor, but it doesn't conclusively identify a model or owner, especially if the address is private or randomized.

One read-only comparison

From a computer on the same authorized network, make a single read-only check. You can run a local network scan, check the router's current association view, or consult a managed switch's address table if you administer it. Record the method and time alongside the result. What you see locally can support a hypothesis, but a device's absence doesn't prove it has left the network. A sleeping phone, a firewall rule, client isolation, or a different segment can affect what's visible.

If something appears to answer at the address, look for a non-invasive way to confirm what it is. Open the known printer's local status page, inspect the NAS network settings, or watch what changes when an authorized owner joins or leaves the Wi-Fi. Avoid probing services you don't need to use. Never create a duplicate IP address to test this; an address conflict can interrupt other devices. RFC 5227 explains how hosts that implement address-conflict detection handle it. Deliberately creating a conflict isn't a diagnostic shortcut.

Keep your notes to what you've established. “Lease present; no matching household device yet” is more useful than a guess that it belongs to a neighbor or an intruder. A local observer such as DeviceShelf can give you another point of comparison on a network you administer, but it doesn't replace the router or the device's own settings.

Reasons for a security response

If the entry is still unexplained after those comparisons, take a closer look. Check who knows the Wi-Fi password, whether the guest network is separate, and whether the router firmware is current. NIST's guidance on wireless-network security provides a useful checklist for reviewing security settings and router administration. Follow the router vendor's documented update process. Don't use an update link supplied by an unexpected device name or message.

Changing the Wi-Fi password can be reasonable if there's evidence that an unauthorized person may know it, or if a router-administration credential has been exposed. That will disconnect legitimate devices, too. Plan to reconnect them and update their stored credentials. Choose a new, unique passphrase, and review the router's administrator password separately. Blocking a single MAC address isn't a complete fix: a hardware address isn't a lasting identity, and blocking it doesn't replace securing the wireless network.

If you recognize the device, keep a short note in a dated network inventory. If it remains unknown, keep the facts you observed and a record of the checks you made. Those notes will help with the next review without treating one ambiguous line in the router's list as a conclusion.

Sources

Build a Home Network Inventory Without Guessing

DeviceShelf — Mon, 12 Oct 2026 09:00:06 +0000

A home network inventory is useful well before something breaks. It helps answer everyday questions: which address belongs to the printer, whether a NAS has moved to a different network, or whether that unfamiliar name in the router is a phone with a changed Wi-Fi identifier. When troubleshooting does come up, you have a record to start from instead of relying on memory.

No single list covers the whole network. A router usually records the DHCP clients it knows about; a scan shows devices that answer from one place at one time. A device's own settings tell you how it's meant to be configured. Those records overlap, but ordinary things can make them disagree. You need a dated record with enough evidence to check a change. You don't need to treat every entry as permanently identified.

The boundaries of your network

Before collecting device names, work out which network you're documenting. On an authorized computer connected to it, note the IPv4 address, prefix length or subnet mask, default gateway, and the name of the Wi-Fi or Ethernet connection. Then find the router, firewall, or DHCP server serving that connection. A home can have several network boundaries: a guest network, a mesh system with a router upstream, a separate IoT VLAN, or a second router left in router mode.

Private address ranges are common at home. But an address starting with 192.168 doesn't establish that two devices are on the same local network. RFC 1918 reserves several blocks for private use; the prefix length and routing configuration determine which addresses are local to a particular interface. See RFC 1918.

Give the inventory a short heading such as “main home LAN, observed 10 October 2026” and include the gateway and subnet. Keep guest networks separate. Putting their entries in the same table can make an ordinary isolation rule look like a missing device. If someone else administers the network, ask before collecting or changing its records.

The initial list from the DHCP authority

Open the client, lease, or connected-device view on the DHCP authority for the network you've identified. Menu labels vary. Look for terms such as DHCP leases, clients, address pool, and reservations, which often lead to the right screen. Record what the server actually supplies, leaving gaps where you'd otherwise have to guess:

The displayed device name and hardware address, if shown.
The assigned IPv4 address and whether the entry is a lease or reservation.
The last-seen time or lease-expiry time, if the interface shows one.
A source note naming the router or DHCP server and the observation date.

A DHCP address is a binding with a lifetime, not a permanent ownership label. Clients can renew a lease or receive another address. A sleeping or disconnected device may still have an entry in the lease list. RFC 2131 describes how allocation and renewal work. RFC 2131. That makes a lease list a useful starting point, particularly for devices using DHCP. It doesn't prove that an address is unused or that a name is accurate.

Capture what exists before making any new static assignments. If you later use the inventory to set up an address reservation, check the proposed device identity against the interface that will actually connect. DHCP treats a laptop's Ethernet and Wi-Fi interfaces as different devices.

Observations and their sources

Next, make a read-only observation from an authorized machine on the same network. A local scan, switch table, or a device's own network settings can confirm parts of the DHCP list and reveal a system with a static address. Record the method and time beside each result. A system missing from one scan may be asleep or on another segment. It may have a firewall, or it may simply not answer the probe you used. Its absence doesn't prove it's gone.

A reachable address doesn't prove identity, either. Records showing the same address at different times may just reflect a normal DHCP reassignment. An address conflict is more serious. Investigate it through the DHCP configuration and the affected devices rather than deliberately creating one as a test. RFC 5227 explains IPv4 Address Conflict Detection used by hosts that implement it. RFC 5227.

Add a short confidence note when the evidence doesn't support a firm conclusion. For example, “printer — confirmed from printer panel and DHCP reservation” is stronger than “HP-looking name in router list.” “Unknown — lease present, no owner confirmed” is more useful than deciding, without evidence, that it belongs to a neighbor or an intruder, or that it's a particular model.

Changing Wi-Fi identifiers

Modern phones, tablets, and laptops can use a private Wi-Fi address for a saved network. After a reset, a network-forget action, or a privacy-setting change, the same physical device may appear with a new hardware address. Apple documents how private Wi-Fi addresses behave and where to review them on its platforms. Apple Support. Other platforms have similar privacy features; their behavior depends on the device and network.

Don't disable a privacy feature just to tidy up a spreadsheet. Mark the older entry as historical and add the observation date. Only merge records once you can confirm the device through its own settings, its owner, or a stable service it provides. For a fixed appliance such as a NAS, a documented DHCP reservation is often a clearer way to establish identity than a nickname copied from an old router screen.

Be careful with names, too. A device name may come from its user or manufacturer, or it may be missing altogether. Manufacturer prefixes in hardware addresses offer clues, but they can't fully identify a model. They're less helpful when the address is private or randomized.

A manageable inventory

The table only needs a few columns: date observed, network, device label, address method, current IP address, hardware-address note, source, and confidence. Add a final column for the next check, such as “confirm with owner” or “review after next DHCP renewal.” Keep passwords, recovery codes, public IP addresses, and sensitive service details out of any broadly shared copy.

Review the list after deliberate changes, such as replacing a router, adding a mesh node, moving a NAS, or reserving an address. In day-to-day use, update an entry when you can observe the change. Don't automatically take a scan result as truth. Keep the old values and their dates until you've checked dependent bookmarks, backups, and local integrations.

For a network you administer, DeviceShelf can provide one local observation source to compare with the DHCP authority and device settings. It shouldn't replace those records or turn an unconfirmed scan result into an identification.

A useful home network inventory tells you what was observed, where, and how certain the identification is. The number of columns matters less. With that information recorded, the next unfamiliar entry becomes something you can check instead of guess at.

How to Give a Device a Stable IP Address with DHCP Reservation

DeviceShelf — Sat, 10 Oct 2026 09:00:03 +0000

Some devices need a predictable local address. A printer may be saved on several computers, a NAS may hold your backups, or a home server may be named in an automation. If that address changes, the service can look broken. The device itself may still be working fine.

The usual fix is a DHCP reservation, sometimes called an address reservation or static lease. It tells the router's DHCP server to offer a chosen address to a specific client. That is different from setting an address manually on the device. An address that looks unused today may already be in the DHCP pool and be assigned to another device later, so the distinction matters.

This guide is for a network you own or are authorized to administer. Router menus vary. A reservation also won't guarantee uninterrupted access: Wi-Fi coverage, power, DNS, VLAN rules, or the service running on the device may still be the real problem.

DHCP leases and client identities

On a typical home network, the router runs a DHCP server. A client asks for network settings, and the server gives it a lease containing at least an IP address for a limited time. DHCP identifies the client by a client identifier or, commonly in home-router interfaces, the MAC address of its network interface. The protocol calls this association a binding. The server manages it; the client does not own it permanently. RFC 2131

This explains a couple of common surprises. A device can get a different address when its lease expires, when it reconnects, or when the router decides the old address is no longer appropriate. And an old lease can stay in the router's device list after the device goes offline. A listed address is useful evidence, but it doesn't prove the device is reachable right now.

A DHCP reservation tells the server what to do with future leases: when this client asks, offer this address. It is usually safer than setting a static address on the device because the router remains the single place that allocates addresses. It also helps with troubleshooting later. The reservation records the intended assignment at the DHCP server, rather than leaving you to guess from a one-time scan.

A stable device identity

Before creating a reservation, check that you have the right network interface. A NAS with Ethernet and Wi-Fi can have two different MAC addresses. A laptop using a USB Ethernet adapter can change identity when you swap the adapter. A reservation for the Wi-Fi address won't help once the device is plugged into Ethernet.

Use two independent details where possible: the device's name or physical location, plus the MAC address currently shown by the router or the device itself. Copy the address with its separators exactly as the router displays it. Don't rely on a label alone. Generic names such as “android” or “unknown” are often reused.

Private Wi-Fi addresses need a closer look. Apple documents that its devices can use a private Wi-Fi address for each network, and that address can rotate in some circumstances. A reservation tied to a changing Wi-Fi address may stop matching the device later. Before relying on a MAC-based reservation, check the private-address setting for that specific network. Understand the privacy consequence before changing it. Apple: private Wi-Fi addresses

For equipment that needs to be reliably reachable, a wired interface or a documented, stable Wi-Fi identity is often easier to manage. That's a choice about managing that equipment, not a reason to disable privacy settings on every personal device.

Address selection without conflicts

Open the router's DHCP or LAN settings and note three things before changing anything:

The local subnet, such as 192.168.1.0/24.
The DHCP pool, for example 192.168.1.100 through 192.168.1.200.
Existing reservations and currently active leases.

Choose an address in the same subnet that isn't already assigned or reserved. Many routers allow reservations inside the normal DHCP pool. That's fine when supported: the router knows the address is set aside. Other interfaces recommend an address outside the automatic pool. Follow the router's own approach instead of mixing the two.

One unanswered ping doesn't mean an address is free. A sleeping client, a second DHCP server, an isolated VLAN, or a firewall can make an address look unused when it isn't. Start with the router's reservation and lease tables. If you have more than one router, mesh controller, or DHCP server, find the one serving the device's network before adding the reservation.

Reservation setup on the router

Look for the menu under Network, LAN, DHCP Server, or Address Reservation. TP-Link's current support instructions give one example: select the client or enter its MAC address, enter the IP address you want, enable the entry, and save it. Other vendors use different labels, but you need the same basic information. TP-Link: configure address reservation

Make one change at a time:

Select the confirmed client or enter its MAC address.
Enter the chosen unused address in the correct local subnet.
Save or enable the reservation. In your network notes, record the device, interface, MAC address, chosen IP address, and date.
Renew the DHCP lease on the device, or reconnect its network interface, only if doing so is safe for its current work.
Check the router's current lease table after the device reconnects.

Don't reboot a NAS or a computer that's updating, backing up, or serving other people just to test an address change. After the normal reconnect, check the device's management page or local service if it has one. Saving the router entry successfully doesn't prove that every application using the old address has updated.

Verification from the right network

Once the client gets a new lease, check three separate facts:

The router shows the intended address bound to the intended client identity.
The device itself reports that same address on the expected interface.
One authorized client on the same network can reach the relevant service by its intended name or address.

Each check catches a different kind of error. The router may have the right reservation while the device is still using an old lease. Or the device may have the right address, but a backup job still points to the previous address. Even with the correct IP assignment, a service can be unavailable.

For services that support one, prefer a local DNS name, mDNS name, or router-managed hostname to copying an IP address into every configuration. Names can make later renumbering easier, though they have dependencies of their own. Keep the reservation as the stable allocation record. Use a name where the service and network resolve it consistently.

Problems beyond the reservation

If the address changes again, compare the MAC address in the new lease with the one in the reservation. A mismatch usually means the device used a different interface or a private Wi-Fi address. If they match, check for another DHCP server and confirm that the reservation was enabled and saved. Also check whether the client is connecting to a guest or separate VLAN instead of the expected LAN.

If the address stays the same but the device is still unavailable, also verify its subnet mask, gateway, and DNS settings, including those supplied by DHCP. Then check the connection and service. Check link status, Wi-Fi signal, and power. Look at the device's own logs, DNS resolution, firewall rules, and the specific service. A reservation makes one variable predictable. It doesn't diagnose the rest of the path.

Remove old reservations when you retire a device or replace its network interface. A short note beside each active reservation prevents a future administrator from assigning a familiar-looking address to the wrong machine. That record is often more useful than a long router list of unlabeled historical leases.

Sources rechecked 8 October 2026

Check an IP Address Before Assigning It Statically

DeviceShelf — Thu, 08 Oct 2026 09:00:05 +0000

Giving a printer, NAS, or home-automation hub a predictable IPv4 address can make it easier to manage locally. A bookmark, backup target, or integration then has a consistent destination. But a fixed address can also cause an outage that's hard to track down if DHCP is already offering that address, it belongs to another network segment, or you copied it from an old router configuration.

“Does this address answer a ping right now?” isn't enough to go on. An address that doesn't respond may still be reserved for a sleeping client, blocked by a firewall, or reachable only from another part of the network. The checks below give you a short sequence for assigning a fixed address based on what you can verify, on a network you own or are authorized to manage.

DHCP reservations and static configurations

There are two common ways to give a device a predictable address. You enter a static configuration on the device itself. A DHCP reservation lives on the DHCP server, which offers the same address to a recognized client. Neither is always better. A reservation does, however, keep the gateway, DNS servers, and other network settings under the DHCP server's control.

First, check what the device supports and what manages its current network. A managed work network, guest Wi-Fi, IoT VLAN, or second router may use a different DHCP server from the main home router. Before setting a static address, identify which server is responsible and which subnet applies. If someone else or another organization manages the device, ask the responsible administrator to assign the address.

A fixed address won't fix weak Wi-Fi, a missing route, an unavailable service, or a name-resolution problem. Write down the original symptom. Otherwise, the new configuration may make it harder to work out what went wrong in the first place.

The correct network range

On a device that's currently connected, note its IPv4 address, subnet mask or prefix length, default gateway, and DNS servers. Check those values against the router or DHCP server serving that connection. RFC 1918 describes the private IPv4 ranges often used on local networks. It doesn't tell you which subnet your network uses or which addresses your DHCP service can allocate. See RFC 1918.

For example, an address starting with 192.168.1 isn't automatically suitable just because another device uses 192.168.1.20. The subnet mask determines which addresses are local to a particular interface. A private range that looks the same can also sit behind a downstream router or on a separate VLAN. The address you choose must belong to the network the device is supposed to join.

Record the current values before changing anything. If the device stops responding afterward, you'll have a known configuration to compare with its recovery procedure. Don't copy a gateway or DNS address from an unrelated network, a screenshot, or an old tutorial.

The DHCP scope and available addresses

Open the DHCP settings for the relevant network. Find the allocation range, reservations, exclusions, and current leases. Menu names vary, so look for DHCP server, address pool, leases, or client list. DHCP leases are usually time-limited and can be renewed; infinite leases are also supported. A lease table is useful evidence, but it doesn't show every static address in use. RFC 2131 describes this exchange.

A DHCP reservation for the device's actual network interface usually leaves the least room for confusion. If you need a static configuration, use an address that the local network documentation and DHCP configuration explicitly place outside the dynamic pool. Alternatively, create an exclusion using the router's documented procedure. Don't assume the last few addresses in a range are free. Check the router and any existing records.

Check the device's identity carefully, too. A laptop may have different MAC addresses for Wi-Fi and Ethernet, and phones and laptops can use private Wi-Fi addresses. The reservation needs to match the interface that will connect. If you tie it to an old identifier, the device may get a different dynamic address instead of the one you expected.

Reachability tests as supporting evidence

Before applying a static setting, look for the proposed address in current leases and any documented static-address list. A reachability check from an authorized machine on the intended network can tell you more, but it can't prove the address is unused. A device may ignore ping, be asleep, or sit behind a firewall while still owning that address.

IPv4 Address Conflict Detection is a specific protocol behavior. It doesn't guarantee that every client and network will reveal a conflict the same way. RFC 5227 explains how hosts that implement it probe and announce addresses. That background helps explain why a conflict might come and go, or appear only when a second device reconnects. Don't deliberately assign a duplicate address to see how your router reacts.

If a record assigns the proposed address to another device on the intended network, choose another documented address. If ownership is unclear, resolve it before proceeding. Stop if the records disagree. Before changing several settings at once, work out which DHCP server and network segment those records belong to.

A single change and full-path verification

Configure a static address on the device, or create a reservation on the responsible DHCP server using its documented procedure. Write down the old settings and proposed address, along with the time of the change and whether it requires a reconnect or restart. For a NAS or a device running backups, use a maintenance window. Changing the network configuration can interrupt transfers and make remote recovery harder.

Once the device reconnects, check more than the address it displays:

Confirm that the address, prefix, gateway, and DNS settings match the intended network.
Check that the DHCP server no longer offers the same address to a different client.
Reach the device through one authorized local service or administration page.
Confirm that any bookmark, integration, or backup target points to the new address.
Keep a note of the old address until you know that no permitted local dependency still uses it.

If the device works locally but a service can't reach it, check routing, access rules, service state, or DNS separately. Changing the address again is unlikely to help explain any of those problems.

A short record for future changes

You don't need an elaborate address plan. A short entry with the device, interface, network, address method, address, and date is enough to prevent many accidental duplicates. Label any guesses as guesses. Update the record only after you've checked the actual configuration.

On networks you administer, DeviceShelf can provide one source of local observations when you compare devices and address changes. Use it alongside the responsible DHCP server and the device's own configuration. Seeing an address associated with a device doesn't, by itself, prove that the address is reserved, exclusive, or reachable from every network segment.

Choose an address after you've identified the right network and checked its allocation policy. Those checks take a few minutes, but they're much easier than recovering a device after two clients have been given the same address.

Why an Online Device Can Be Missing from a Ping-Based Network Scan

DeviceShelf — Tue, 06 Oct 2026 09:00:09 +0000

A laptop, NAS, printer, or phone can work just fine on a home network without showing up in a scan. Its normal app may still work, a shared folder may open, or it may have just sent a notification. You might think the scan is wrong or the device has disappeared. A single missing result doesn't tell you either way.

One common reason is that the scan used ping, or ICMP echo, to look for devices. A device can accept the traffic it needs for its normal job without answering ICMP echo. Or it could be asleep, on another network segment, or outside the scan range. This guide walks through those possibilities. The check is limited to a network you own or are authorized to administer.

A missing scan entry as a single observation

Start with what the scan actually did. Record the time, the computer that ran it, the network or VLAN it was connected to, the target range, and any discovery methods the tool shows. Write down the device's expected name and IP address, if you know it, along with the normal activity that made it seem online. Do this before restarting a router, changing a firewall rule, or removing a lease.

“Online” isn't a single network test. A printer can accept a print job but refuse a ping. A NAS may serve a file to one client while remaining unreachable by a scan from guest Wi-Fi. A phone might wake briefly for a push message, then go back to sleep before you run a scan. The reverse matters too: a ping reply doesn't prove that every service on the device works.

The Internet Control Message Protocol defines echo request and echo reply messages. It doesn't require every host or network policy to make a reply available to every other host. RFC 792 describes the protocol messages themselves. A missing echo reply tells you something about that particular request and path. It doesn't tell you the device's overall status.

A fair comparison of network locations

Before hunting for a fault, check where the device sits on the network and where you ran the scan. Are the scanning computer and the expected device on the same SSID, wired LAN, VLAN, or routed subnet? Guest and IoT networks often restrict traffic between clients on purpose. With a mesh system, a device can look close to the router and still be on a separate segment with different traffic rules.

Check the target range, too. For example, scanning 192.168.1.0/24 won't include a device at 192.168.168.25, even if both addresses belong to networks at the same site. Don't expand the scan into networks you don't manage just to fill out the list. If you administer another subnet, check its address range and the route to it separately.

For an IPv4 device on the same local link, a recent ARP or neighbor-table observation can help. ARP maps an IPv4 address to a link-layer address on a local network; it doesn't cross a router to discover devices on another segment. RFC 826 explains that local role. A stored entry doesn't prove the device is still there. It can, however, help you work out whether to investigate the local address or the routed path.

The scan's discovery methods

Network-discovery tools use different probes. Depending on the tool, its permissions, and the target, a scan might use ARP on a local IPv4 network, ICMP echo, TCP connection attempts, or several methods together. The Nmap host-discovery reference gives examples of these approaches and explains why their results can differ.

The method matters. ARP can find a local device that ignores ICMP. Depending on the scanner, TCP discovery can infer reachability from either an accepted connection or a reset response from a closed port. A device may appear in the router's client list because it recently received a DHCP lease, yet answer no probes while it's asleep. These observations aren't interchangeable. Keep track of what each one actually tested.

If the scanner shows its selected methods, compare a repeat run from the same authorized computer and network. Don't change several settings at once. A repeat run may show that the result was temporary, but it won't establish why the device didn't reply. Keep the time and method alongside the result so you have that context for later comparisons.

Host and network policy checks without weaker protection

Operating-system firewalls can allow a device's normal services while controlling unsolicited inbound traffic, including ICMP. Microsoft documents how Windows Firewall rules can be scoped by protocol, profile, address, and other conditions. Read its Windows Firewall guidance before modifying a rule.

Inspect the policy through the device's usual, authorized administration path instead of disabling its firewall to test a scan. An administrator may control the policy on a managed computer. Being able to sign in doesn't necessarily make changing it appropriate. For a NAS, printer, or camera, check the vendor's documentation for network and sleep settings. There may be a setting labeled “respond to ping”, but enabling it is a choice about exposure. The device doesn't need it enabled to work.

Also check router features that separate clients: guest isolation, wireless client isolation, VLAN rules, parental controls, or access-point policies. If you find a rule that explains the result, record it. Don't disable isolation just to make a device appear in a scan; that protection may be intentional.

A narrow troubleshooting sequence

Start with the least disruptive evidence, then move to more specific checks:

Confirm the scan time, target range, and scanning network.
Compare the device's expected IP address and network with the router or controller's current information. Note whether you're looking at a current assignment or an older record.
Repeat the same permitted discovery method once from the same place. Keep a local check from becoming a broad probe.
If you administer the device, check one normal, already-authorized service it's expected to provide, such as its existing management page or a known file share.
Review the documented sleep, firewall, and isolation settings before deciding whether a configuration change is justified.

You may still have an inconclusive result. That's useful information, too. “The device was reachable through its normal service at this time but did not answer this discovery method” is more accurate than marking it offline. If the device is needed for a critical task and its normal service is also unavailable, follow the vendor's support procedure or your local administrator's incident process.

DeviceShelf can provide another observation for a network you administer. Compare any discovery result with the router's current information and the device's expected service. A missing scan record alone doesn't establish an outage, a firewall fault, or an unauthorized device.

Keep the scope small. Record which method you used, the path it took, and when you ran it, then compare a known service only when you have permission. You'll have a checkable observation behind that puzzling empty result without weakening the device's security settings just to satisfy a scan.

Why Your Router Can Appear Twice in a Network Scan

DeviceShelf — Sun, 04 Oct 2026 09:00:06 +0000

A network scan sometimes looks as though it's found two routers. Maybe the same vendor name appears twice, two records have similar hostnames, or you recognize one address but not the other. That can be unsettling, especially when the second entry wasn't in an earlier scan. On its own, though, it isn't proof of an unknown device, a compromised router, or a scanner failure.

Routers are networked computers that do more than one job. A single physical appliance can have separate interfaces for the home LAN, an internet-facing connection, a guest network, a mesh backhaul, or a management network. Each interface can have its own address and respond differently to a discovery method. This guide walks through a cautious comparison of two records on a network you own or are authorized to administer. The goal is to work out what the scan found. Making an entry disappear is not the point.

Record both entries first

Before restarting equipment or deleting a saved record, take a screenshot or write down the details of both entries. For each, record the scan time, IPv4 or IPv6 address, MAC address if shown, hostname, vendor label, and the network or scan range that produced it. If the scanner reports open services, note the service names and ports it already shows. There's no need to probe a device further just to sort out a duplicate label.

The word “router” in a device list may come from a hostname, a vendor database, a service, or a response to a protocol. It's useful evidence. But it doesn't identify a device the way a serial number does. Two devices from the same vendor may get the same broad label, while one router with two visible network interfaces may show up as two records.

Start with a simple comparison:

Are the IP addresses in the same subnet?
Are the MAC addresses identical, similar, or completely different?
Do the hostnames, vendor labels, and observed services agree?
Did both records appear in the same scan range and at the same time?
Does one address match the router address configured as the default gateway on a client?

Don't draw a conclusion from the last digits of an address or a friendly name alone. A device's DHCP address can change, and names often come from a factory default or the router. Even this is a useful result: “These are two observations that need to be checked against the router configuration.”

Multiple network interfaces on one appliance

An IPv4 host can connect to more than one network. Internet host requirements describe how hosts handle multiple interfaces and addresses, with RFC 1122 providing a foundational reference for that behavior. On home equipment, you may not be able to see all the interfaces from the same place. A scan can still find more than one.

Separate LAN, guest, or management interfaces can explain multiple entries when their IP addresses are reachable within the scan’s scope. Ethernet and Wi-Fi bridged into one LAN do not by themselves create separate IP-scan entries. Some appliances also have a management address on a VLAN, a modem-facing address, or an extra interface for a separate service. The scan result doesn't tell you which arrangement you're looking at. It records the response received from the network and method you chose.

Separate interfaces normally have separate link-layer addresses. A MAC address belongs to a network interface, not necessarily the whole box. The Address Resolution Protocol associates an IPv4 address with a hardware address on a local network segment. It doesn't give all of an appliance's interfaces one universal, permanent identity. RFC 826 explains that local role of ARP.

So two different MAC addresses don't automatically mean two physical routers; they can belong to two interfaces on the same appliance. Matching vendor prefixes don't prove a connection either. A household may have a router, extender, switch, and smart device all made by the same company.

Router configuration as a cross-check

Use the established, authorized way to administer your router. Look for pages showing LAN settings, Wi-Fi radios, guest networks, mesh nodes, DHCP leases, or interface status, and compare their addresses with the two records. If the router documentation lists a management address or MAC address for a particular interface, record the exact match and when you saw it.

Check the default gateway on a computer connected to the affected network, too. The gateway IP is strong evidence that one record represents the path that client uses to leave its local subnet. That doesn't make the other record suspicious. A guest or IoT network can use a different gateway address. A mesh node may also appear as a separate network device even when you manage its configuration from the primary router.

If you don't recognize the range containing the second record, check the scan range and any added network ranges first. A scan covering more than one authorized subnet can legitimately find infrastructure in each. Don't add routes, disable isolation, or reset the router just to get a simpler list.

Scan methods and their limits

Discovery tools can use several techniques. A host may answer one and ignore another. The Nmap host-discovery reference documents ARP, ICMP, TCP, and other probes and explains their different purposes. When a record appears in one kind of scan but not another, that tells you something about the method and path. It isn't a complete verdict on health or security.

ARP-based discovery, for example, is limited to the local link. Results from a routed guest network or a downstream subnet may therefore differ from a direct local scan. A router's web interface can also respond on one address while another interface doesn't offer that service. Compare like with like. Before treating a changed list as a device change, run the same authorized scan from the same network.

Keep the investigation focused instead of broadening it into a scan of networks you don't administer. The question is specific: do these two records match documented interfaces, known mesh equipment, or an unexplained device on your own network?

Results and follow-up

Once you've compared the records, put the result into one of three categories:

Documented interface or known node. The router configuration, mesh overview, or gateway setting matches the record. Note the role and address so you have them for the next scan.
Inconclusive. You haven't matched the records, but there's no specific indication of a new device. Check again later from the same authorized network and avoid disruptive changes in the meantime.
Unexplained on your network. The address, MAC address, and location don't match the router, known mesh nodes, or expected equipment. Review the router's client list and Wi-Fi security settings. If the evidence supports removing an unauthorized client, follow the vendor's documented procedure.

DeviceShelf can provide another source of observations for a network you administer. Compare its labels and scan results with the router's own interface and client information. A single scan record can't establish that two entries belong to the same appliance or that an unknown entry is malicious.

Keep both observations and compare their network context before changing a configuration. A router appearing twice often comes down to normal interface design. When it doesn't, a small, dated record of the addresses and evidence gives you a better starting point than guessing from a device name.

Router Device List vs Network Scan: What Each One Can Tell You

DeviceShelf — Fri, 02 Oct 2026 09:00:06 +0000

A router lists a device as connected, but a network scanner can't find it. Or the scanner finds an address that doesn't appear in the router's list. That doesn't automatically mean either tool is broken. Each collects different evidence, and the observations may come from different times.

This guide is for a network you own or are authorized to administer. The goal is simple: compare the router's device list with a scan and find a useful next check. The comparison can't prove who owns a device, bypass network controls, or diagnose every connectivity problem from one screen.

The information behind each list

Most home routers keep a DHCP lease table, often displayed as a client or connected-device list. DHCP offers network settings, including an IP address, for a limited lease period. A record can include a client identifier or MAC address, a hostname, the offered address, and lease timing. It tells you what the DHCP server knows about an address assignment. RFC 2131

That's useful, but it isn't necessarily a live presence check. A client can still have a valid lease while asleep, unplugged, out of Wi-Fi range, or connected to a different access point. Some router interfaces hold on to entries that look historical longer than you might expect. A device with a manually configured address, meanwhile, may never appear as a normal DHCP lease.

A network scan checks something else: which hosts respond or leave discoverable evidence from the place on the network where you're running it? Depending on the tool, it may use ARP on a local IPv4 network, ICMP, TCP probes, neighbor tables, name-resolution records, or service announcements. Nmap's host-discovery documentation shows why both the selected probes and your position on the network affect the results. Nmap: Host Discovery Controls

The lists often overlap enough to be useful. They won't necessarily match exactly.

Devices in the router list that a scan misses

Timing is the simplest explanation. A lease can remain active while the device is sleeping or disconnected. Battery-powered sensors, phones with Wi-Fi power saving, and laptops with closed lids are common examples. Wait for the device's normal activity instead of repeatedly forcing it to reconnect just to get the lists to agree.

Then consider network boundaries. A scan from one VLAN, guest network, or Wi-Fi isolation zone may not reach hosts on another segment. A mesh controller may list clients that a computer on a guest SSID can't reach with ARP or probe traffic. Firewall rules can cause the same mismatch. The device has an assigned address, but the probe you've chosen gets no answer.

The scan method matters, too. A host might ignore ICMP echo but answer a local ARP request; while asleep, it might answer neither. ARP resolves an IPv4 address to a link-layer address on the local network and doesn't cross routed boundaries. RFC 826 Record how you scanned before deciding what a missing result means.

Addresses a scan finds outside the router list

The device may have a static address. Printers, NAS appliances, lab equipment, and old devices are sometimes configured locally rather than getting an address from DHCP. They can respond on the network without a current lease entry in the router.

You may also have more than one DHCP server. Another router, a misconfigured extender, a lab subnet, or a virtual-network service can hand out addresses independently. The router page you're looking at may simply not be the authority for that device's network. Before changing reservations or deleting entries, identify the DHCP server that actually serves the segment.

Or the scan may be showing stale local evidence. Operating systems keep ARP and neighbor-cache entries for a while. An entry means the machine learned a mapping, not that you have timestamped proof the device is still on the wire. Compare that entry with a fresh scan and with the device's normal service, such as its management page or a file share, where doing so is safe and authorized.

Fields for comparing devices

Router labels help, but they're weak identifiers. A label may come from a hostname, be assigned manually, get reused after a reset, or be cut short by the interface. Start with the IP and MAC addresses, writing each MAC address exactly as displayed. For a device with multiple network adapters, check that you're comparing the adapter used on this network.

A MAC vendor lookup provides only a clue to a device's identity. It may tell you which manufacturer owns an address block. It can't prove the model or who is using the device. Modern phones and computers can also use private Wi-Fi addresses, so the address you see on one SSID may differ from the hardware's factory address.

Keep a short comparison note. Include the observation time, the router page or controller you used, the scan machine and network, and the methods used. Those details make a vague disagreement reproducible. For example: “router lease at 10:15; ARP scan from wired LAN at 10:18; phone on guest Wi-Fi.”

A safe sequence for resolving a mismatch

Confirm that the router list covers the same LAN, VLAN, or SSID as the machine running the scan.
Compare the IP and MAC addresses, not just the device name. Note whether the router marks the lease as active, offline, or historical.
Run one fresh local discovery method appropriate to the segment, then record the time and result.
If the device should be online, check one ordinary service you're allowed to use, such as its local web interface or a known file share.
Check for guest isolation, VLAN rules, mesh nodes, extenders, a second router, or a static-address configuration before editing DHCP settings.
Leave the device alone if the remaining explanation is normal sleep or scheduled downtime. A missing scan response alone isn't a reason to reboot equipment.

Following this sequence avoids two common mistakes: assigning a new reservation to an address that belongs to another DHCP domain, and mistaking a legitimate sleeping device for an intruder. If you can't establish which network segment is involved, stop and map the topology before making changes.

Inventory tools and their limits

If you make this comparison regularly, an inventory tool can help you keep a dated record of addresses, names, and changes. DeviceShelf is one option for discovering devices on a local network and reviewing the results alongside router information. Treat it as another source of observations, not proof that a router, client, or network rule is wrong.

Usually, the comparison leaves you with a more specific question: is this a current DHCP lease, a reachable host on this segment, a cached observation, or a device behind a boundary? Once you've pinned that down, it's much easier to investigate the relevant router, switch, access-point, or device setting.

Why Your Router's Device List and a Network Scan Disagree

DeviceShelf — Wed, 30 Sep 2026 09:00:04 +0000

For example, you open your router's device list and count 18 clients. A scan of the same home network finds 14, or 23. Neither number is automatically wrong. The two tools answer different questions, at different times, and don't see the network the same way.

Before treating an extra entry as an intruder or assuming a missing device is offline, it helps to understand that difference. A router usually keeps records of addresses it assigned or devices it learned about. A scanner sends traffic or checks local network information to see what's there. Both are useful. Neither gives you a complete, permanent inventory on its own.

This guide is for a network you own or are authorized to administer. It covers common reasons the lists don't match, how to compare them without changing configuration, and what evidence to keep when a device needs investigation.

The router's device list

Labels such as Connected devices, Network map, DHCP clients, and Known devices can sound interchangeable. They aren't. A DHCP client list is mainly a record of address leases. DHCP defines how a client obtains and renews a configuration lease, and the router may keep that record until the lease expires. By then, the device may have gone to sleep, left the house, or switched networks. A remembered hostname or icon can outlast the connection it described. RFC 2131: Dynamic Host Configuration Protocol

Some routers also show clients learned from their Wi-Fi or Ethernet tables. Others put current and historical entries on the same screen. How this works depends on the router and firmware. Instead of relying on the total at the top of the page, look for a status indicator, last-seen time, connection type, IP address, and MAC address. An entry with no recent activity but a remaining lease is a clue about a past connection, not proof that the device is online now.

A network scan's view

A local scanner usually looks for hosts that answer while the scan runs. On an Ethernet or Wi-Fi LAN, it may use ARP to ask which device owns an IPv4 address. Depending on the tool and its settings, it can also use ICMP, TCP, UDP, or protocol-specific discovery. Nmap's documentation treats host discovery as a separate step and explains that different probes get different kinds of responses. A quiet or filtered host can be missed by one scan and found by another. Nmap: Host Discovery

Where you run the scan matters too. A laptop on guest Wi-Fi may be deliberately separated from devices on the main LAN, and a scan from one VLAN may not reach another VLAN. A phone using mobile data or a VPN isn't necessarily probing the same path as the router. Before comparing results, check that the scanning device is on the intended local network. Note its address and network name.

A scan doesn't ask a device to identify itself fully. The device might answer ARP but block ping, respond on one port but ignore another, or sleep between probes to save power. A scan can also find a router, access point, printer, NAS, or phone without finding a useful name for it. The result tells you what was observed at a particular time. It doesn't settle who owns a device or what it's for.

Common reasons for different counts

Timing is a good place to start. A phone may have joined Wi-Fi after the scan, or a tablet may have gone to sleep before it. Refresh the router page and run one new scan within a few minutes. A scan from today and a router screenshot from last week aren't a useful comparison.

Then compare addresses rather than names. Router names often come from DHCP, a device hostname, or a label an administrator entered. A scanner may obtain hostnames through reverse DNS, mDNS, or NetBIOS, and manufacturer labels through a MAC vendor lookup. Those sources can disagree. They can also be missing or out of date. The MAC address and current IP address are more useful for matching entries, though privacy features still need care.

Modern phones and laptops may use a private Wi-Fi address instead of their hardware MAC address. Apple documents that its devices can use a private Wi-Fi address per network to reduce tracking. If that address changes, a familiar phone can look like a new entry in the router's list. Don't block or delete an entry just because its vendor name is missing or its MAC address looks unfamiliar. Check the device's Wi-Fi settings first, including whether its private address was changed or reset. Apple: Use private Wi-Fi addresses

Scope matters as well. A mesh system may include a main router and several nodes, each with its own management address. A wired switch, access point, or virtualization host can expose more than one interface. Docker or other virtual networking can create addresses that mean something on the host but don't represent ordinary household devices. You don't need to force every entry into a one-to-one list. Record which entries represent infrastructure and which represent endpoints.

A comparison worksheet

Use a short worksheet you can repeat:

Record the date, time, timezone, network name, and the device from which the scan runs.
Export or screenshot the router list if the interface supports it. Otherwise, record the current IP, MAC, connection type, and last-seen value for each uncertain entry.
Run one local scan and save its timestamped result. Don't run repeated aggressive probes just to make the count match.
Match entries by current IP and MAC address first. Use names and vendor information as supporting clues.
Mark each mismatch as “router only,” “scan only,” “renamed,” “private address possible,” or “needs confirmation.”
Confirm an important unknown entry from a second source, such as a switch port, Wi-Fi access-point association, or the device's own network settings.

This gives you a calmer way to assess the differences than guessing from a count. A router-only entry whose last-seen time looks old is different from a scan-only device answering right now. An unfamiliar MAC address present in both views gives you stronger grounds to investigate. Even then, it could be a phone using a private address, a recently added smart device, or managed infrastructure.

Unfamiliar devices that need action

If a device is active in both views and you can't account for it, save the evidence before changing anything: current time, IP, MAC, connection type, router or access-point name, and any hostname. Check your own phones, tablets, media devices, work equipment, guests, and smart-home hardware. Ask household members before assuming the connection is unauthorized.

Before blocking a device or changing the Wi-Fi passphrase, identify the device you use to administer the router and your network infrastructure, and test an alternative connection to the router's management interface. Blocking the wrong entry can disrupt legitimate devices or cut off your management access. Expect Wi-Fi devices to need reconnection after a passphrase change. If you still can't identify it, use the router's normal access controls to remove or block the device. Then change the Wi-Fi passphrase if that's appropriate for your network, and reconnect known devices deliberately. Security changes vary by router. Follow its current documentation instead of using commands copied for another model. A single network scan can't establish who used a device or why it appeared.

For ongoing inventory checks, DeviceShelf is one local option that can discover devices and keep an inventory for comparison over time. Use it as another record alongside the router's information. A stale lease, an unclear hostname, or a sleeping device will still need some explanation. Product website

A baseline for future comparisons

Once you've matched the ordinary devices, set a simple routine for maintaining the inventory. Keep the device name, owner or location if appropriate, MAC address, normal IP behavior, and the reason you recognize it. Update the inventory when you add a camera, printer, NAS, access point, or guest network. Don't publish unredacted screenshots. Internal hostnames, addresses, and device names can reveal more about a home or small office than you intended.

The next time the router and scanner disagree, start with that baseline and the timestamps. Instead of an alarming count, you'll have a specific question: “why does this address appear now?” or “why is this known NAS not answering?” That's usually enough to decide whether to wait for a sleeping device, correct a label, inspect network segmentation, or take a security action.

Sources checked

Unknown device on your network? How to identify it, step by step

DeviceShelf — Tue, 22 Sep 2026 09:00:06 +0000

You open your router's device list, or a scanner app, and there it is: an entry you can't place. An IP address, maybe a cryptic name, and no idea whether it's your smart plug or your neighbor's laptop. Before you panic (or worse, ignore it), work through these steps. Most "intruders" turn out to be your own hardware.

1. Look up the MAC vendor first

Every network card carries a MAC address, and its first half identifies the manufacturer. A4:CF:12:… resolves to Espressif, which almost always means a smart-home gadget; Apple, Samsung or Amazon prefixes narrow things down fast. Your router shows the MAC next to each device, and any OUI lookup site translates it.

One catch has gotten bigger in recent years: phones and laptops now use randomized MAC addresses per Wi-Fi network by default. Those show up with a "locally administered" prefix and resolve to no vendor at all. An unknown MAC with no manufacturer is far more likely someone's iPhone with a private address than an attacker.

2. Check the hostname

A device that calls itself MacBook-Pro-von-Lisa or HS110 has identified itself already. Hostnames come from DHCP or mDNS and are visible in the router list or a scanner. No hostname? Not suspicious by itself: plenty of IoT devices simply don't announce one.

3. Let its services talk

This is where it usually clicks. Devices advertise what they are: a printer speaks IPP on port 631, a camera streams RTSP on 554, a NAS offers SMB on 445, a smart speaker announces itself via mDNS as _airplay or _googlecast. Checking open ports and mDNS/SSDP announcements identifies the majority of devices beyond doubt.

You can do this by hand with nmap if the terminal is your thing. Or let a scanner do all of the above in one pass: DeviceShelf combines MAC vendor, hostname, ports, mDNS/SSDP and a fingerprint database into a plain-language guess of what each device is. And it runs locally, without an account.

If you're on a Mac, note that macOS ships without a scanner of its own. We compared nine that run on macOS, three of them free.

4. The process of elimination

Still unclear? Turn off the suspect candidates one by one: smart plugs, e-readers, the TV, the robot vacuum. Watch which entry goes offline. Tedious, but it settles the question. A monitoring scanner also shows the moment a device drops off, so you don't have to keep refreshing the router page.

5. If it really doesn't belong to you

Found a device that is genuinely not yours after all that? Then act in this order:

Change the Wi-Fi password. That kicks every device off the network; only those with the new key come back. Use WPA2/WPA3 with a long passphrase.
Check your router's guest network — a forgotten open guest Wi-Fi is the most common entry point.
Disable WPS if it is still on; the PIN method is a known weak spot.
Re-scan afterwards and compare: everything you recognize should be back, and the stranger should be gone.

Get told about the next one automatically

The uncomfortable truth about a manual check: it only covers today. The unknown device you find next month has been on the network since whenever. This is what continuous monitoring is for — DeviceShelf watches your network in the background and sends a notification the moment a new device joins, so the next unknown entry announces itself. There is a free 7-day trial, no account needed.