DEV Community: DeviceShelf

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.

Run a watchdog that doesn't live in the cloud it watches

DeviceShelf — Sun, 20 Sep 2026 09:00:04 +0000

The big outages of late 2025 had a pattern. When AWS's us-east-1 went down in October, and Cloudflare followed in November, plenty of teams learned that their monitoring lived on the same infrastructure as the things it monitored. Status pages lagged. Alerting SaaS tools were unreachable. For an hour or two, the honest answer to "what exactly is broken?" was a shrug.

The fix is old-fashioned and cheap: keep one monitor that depends on nothing but a box in your own building. It won't tell you why a hyperscaler is on fire, but it will tell you, from the outside, what is reachable and what isn't, while everyone else refreshes a stale status page.

What such a watchdog should check, roughly in this order:

Your internet uplink, against more than one anchor, so a single provider blip doesn't page you.
DNS for the domains you depend on.
Your public services, with real HTTP assertions (status code, a keyword in the body), not just "port 443 answers".
TLS certificates and domain expiry, the two outages everyone causes themselves.
The local infrastructure the cloud can't see anyway: containers, the hypervisor, the NAS that quietly lost a disk, temperatures.

Any self-hosted monitor covers some of this list. Uptime Kuma does the uptime part well and is free; Zabbix does all of it if you bring the time to build it. DeviceShelf Server is our take: one Docker container that discovers the network by itself, runs the checks above out of the box, and alerts through whatever channel you already use. Since 1.6.0 it also watches Docker, Proxmox, NAS health and hardware temperatures. There's an honest side-by-side with Kuma, PRTG and Zabbix if you want to pick for yourself.

Whichever tool you choose: put it on hardware you own, give it its own notification path, and let it be the one thing in your stack that has never heard of us-east-1.

Get notified when a new device joins your Wi-Fi

DeviceShelf — Fri, 18 Sep 2026 09:00:07 +0000

Sooner or later everyone with their own Wi-Fi asks the same question: would I actually notice if a stranger joined? For most people the honest answer is no. The router's device list gets looked at once a year. A notification at the moment a device joins fixes exactly that. Here's how to set one up, with what your router already has or with a scanner.

What routers offer out of the box

Some routers ship with this. AVM's FRITZ!Box can send a push email when a new device logs in (Internet → Push Service → Wi-Fi). UniFi controllers flag new clients in the app once you enable the notification. Many other consumer routers simply have nothing of the sort — then it's the device list, checked by hand.

The router route has two limits. First, it only reports Wi-Fi logins at that router: anything joining over Ethernet, a second access point or a mesh node may not show up at all, depending on the model. Second, it only tells you that something new arrived — not what it is.

The problem with randomized MAC addresses

Before you set up alerts, one expectation to calibrate: modern phones use a randomized MAC address per Wi-Fi network by default, and iPhones can even rotate it periodically in networks they don't trust. For detection this means the same device can come back as a "new device", even though it's your own tablet.

Every solution has to live with that, router or scanner. Two things help in practice: turn off the private address for your home network on your own devices (configurable per network on the iPhone), and limit alerts to unknown devices rather than every new MAC.

Alerts with a network scanner

A scanner with monitoring watches the whole network instead of just Wi-Fi logins: it also sees wired devices, second access points and everything behind mesh nodes, and it identifies the newcomer right away (vendor, type, open ports, name).

With DeviceShelf it works like this: the desktop app monitors the network while your computer is on and raises a notification for new or returning devices. If you want no gaps, run the server edition on a Raspberry Pi, NAS or mini PC around the clock. It sends alerts over email, ntfy, Gotify or webhooks, even with every computer asleep.

For the devices you own, you mark everything as "belongs here" once; from then on, only genuine strangers make noise.

Alerts that don't wear you down

The biggest risk in this setup isn't technical, it's fatigue: get a message for every event and you'll ignore all of them within two weeks. A few rules that hold up:

Alert on joins, not on every come and go. Your phone leaving the Wi-Fi at night is not news.
Batch into a digest when several events pile up. Otherwise one access point reboot fills your inbox.
Mute known devices. The robot vacuum may reappear daily without a beep.

DeviceShelf does this by batching events into a digest and routing by severity: an unknown device is a different message than a known one that was briefly offline.

The short version

Enable router push if yours has it (FRITZ!Box: Push Service). Better than nothing.
For real coverage, use a scanner with monitoring that also sees wired and mesh devices.
Plan for randomized MACs: private addresses off at home, alerts limited to unknowns.
Set up digests and muting so the one message that matters doesn't drown.

How to Find Every IoT Device on Your Network

DeviceShelf — Wed, 16 Sep 2026 13:56:53 +0000

To find every smart-home device on your network, scan the whole subnet and match each result on three signals: the MAC vendor (OUI), the mDNS/SSDP services the device announces, and its open ports. IoT gadgets rarely offer a useful hostname, so those three fingerprints do the identifying that a name usually would.

Why IoT devices are so hard to spot

A laptop tells you what it is. A €9 smart plug does not. Most cheap connected hardware ships without a meaningful hostname, so your router list fills up with blanks, IP addresses, or a generic string like ESP_A1B2C3. The chipsets underneath are shared across hundreds of brands, which is both the problem and the solution: a plug, a bulb and a doorbell might all run the same Espressif or Tuya module, so they look identical at first glance but carry a very recognizable vendor prefix.

Randomized MAC addresses muddy this further. Phones and tablets rotate their MAC per network, and some newer IoT firmware borrows the trick. A locally administered address that resolves to no vendor is usually a phone, not a rogue camera. Knowing that saves you from chasing ghosts.

Start with the MAC vendor (OUI)

The first three bytes of a MAC address are the Organizationally Unique Identifier, and they name the manufacturer of the network chip. This is the single most useful signal for IoT. Prefixes owned by Espressif (A4:CF:12, 24:0A:C4 and many more), Tuya, Sonoff/Itead, Shelly, Amazon, Google and Roku account for a large share of consumer smart-home gear. Your router shows the MAC beside each lease; any OUI lookup table turns it into a vendor name.

The vendor rarely tells you the exact model, but it narrows the field hard. An Espressif prefix means you are looking at a plug, sensor, bulb or DIY board, not a printer.

Let mDNS and SSDP announcements do the work

Here is where identification usually clicks. Well-behaved devices announce their services on the network, and those announcements are self-describing. A Chromecast or Google speaker broadcasts _googlecast._tcp over mDNS. Apple TVs and HomePods answer to _airplay and _raop. Printers advertise _ipp. Smart TVs, media receivers and many cameras respond to SSDP (M-SEARCH) with a device description URL that spells out make and model in plain text.

You can listen for these by hand. On macOS or Linux, dns-sd -B _services._dns-sd._udp or avahi-browse -a enumerates mDNS responders; nmap has SSDP and mDNS discovery scripts. Between the vendor prefix and a service announcement, most IoT devices identify themselves without any guesswork.

Open ports are a fingerprint too

Silent devices that announce nothing still expose services. An nmap -sV sweep against a suspect IP reveals what it is running: RTSP on 554 points to a camera, a stripped-down web server on 80 or 8080 is a typical plug or bridge admin page, MQTT on 1883 suggests a hub, and Telnet on 23 is a red flag on any modern gadget. The combination of open ports plus vendor is often enough to name a device the mDNS pass missed.

Doing all of this manually across a /24 is slow. A local scanner collapses the passes into one: DeviceShelf reads the MAC vendor, hostname, mDNS/SSDP announcements and open ports in a single sweep, then labels each device by type. It runs on your machine with no account and no telemetry. If you have compared it against Fing or LanScan, the feature-by-feature comparison and the Fing alternative page lay out where a local-first scanner differs.

Why the inventory matters: guest VLAN candidates

An IoT inventory is not busywork. Cheap connected hardware is patched rarely, ships with default credentials often, and sometimes phones home over ports you would never open on purpose. Once you know which devices are plugs, bulbs and cameras, the practical move is to isolate them: put IoT on a separate SSID or VLAN that has internet access but cannot reach your laptops, NAS or phones. If a camera firmware is ever compromised, the blast radius stops at the guest segment.

That segmentation only works if the list stays current. New gadgets arrive; old ones get re-flashed. DeviceShelf watches the network in the background and alerts you when a device you have not seen before joins, so the inventory maintains itself instead of going stale the day after you build it. There is a free 7-day trial, no account needed.

Network scanner for Linux, from the terminal or a GUI

DeviceShelf — Mon, 31 Aug 2026 09:00:02 +0000

On Linux you can scan your LAN two ways. From the terminal, nmap and arp-scan hand you a full host list, open ports and MAC vendors in seconds. A GUI makes sense once you'd rather read and sort results than re-type flags. Either route needs root or a setcap grant for the deeper probes.

Scanning your LAN from the terminal

Start with a fast sweep of who is alive. arp-scan is the bluntest tool for a local subnet because it works at layer 2 and returns the MAC vendor for free:

sudo arp-scan --localnet

That gives you IP, MAC and a vendor guess from the OUI (the first half of the MAC, which identifies the manufacturer). For a subnet nmap doesn't need root to do, a ping sweep:

nmap -sn 192.168.1.0/24

To see open ports and services on a host, go deeper. This is where the useful detail lives, because a printer speaking IPP on 631 or a NAS offering SMB on 445 tells you what a device actually is:

sudo nmap -sS -sV --top-ports 100 192.168.1.0/24

For hostnames, nmap already resolves DNS. mDNS names (the .local ones Apple and Chromecast devices announce) need avahi-browse -a, and NetBIOS names come from nmblookup. Piecing those three together by hand is the tedious part.

When a GUI helps

The terminal is fine for a one-off. It gets old when you want to watch a network over time, sort devices by vendor, or hand the result to someone who doesn't live in a shell. A GUI is worth it when you need presence monitoring (which device dropped off, which one is new), a topology view, or a security summary you don't have to assemble from four commands. Zenmap covers the nmap-visualisation case; it stops there.

What permissions does a Linux scanner need?

Raw packet capture and SYN scans need elevated rights on Linux. Running everything with sudo works but is heavy-handed. The cleaner approach is a file capability, which grants one binary the specific privilege without making it root:

sudo setcap cap_net_raw,cap_net_admin=eip /path/to/binary

cap_net_raw lets a process open raw sockets for ARP and SYN scanning; cap_net_admin covers interface-level operations. Without one of these, a scanner falls back to a plain TCP connect scan, which is slower, noisier and misses the MAC layer. Any Linux network scanner runs into this, so it's worth understanding rather than reflexively reaching for sudo.

Running DeviceShelf natively on Linux

DeviceShelf is a local-first scanner that does the terminal work in one pass and keeps the result. It resolves MAC vendor, hostname (DNS, mDNS and NetBIOS together), an OS and device-type guess, open ports and services, then rolls a prioritized security report on top: exposed Telnet or RDP, default-credential checks, risk scores. It also keeps watching, so a new device on the LAN triggers an alert instead of waiting for your next manual scan.

It ships as an AppImage, a .deb and an .rpm, so it runs on Debian, Ubuntu, Fedora and most of what's downstream. The Linux install page has the packages and the one setcap line to enable full capture. There's also a headless server edition (Docker or a systemd service) if you want a homelab box scanning around the clock. No account, no telemetry, and the license check works offline.

If you're weighing it against nmap, Fing or Angry IP Scanner, the comparison page lays out what each one does and doesn't do. The same comparison for macOS, where the built-in options are thinner: network scanners for the Mac.

You can try the full version on your own network first: there's a free 7-day trial, no account needed. One-time €59 after that, no subscription.

How to scan and identify every device on your Windows LAN

DeviceShelf — Sat, 29 Aug 2026 09:00:04 +0000

To scan a network on Windows, start with what ships in the box: arp -a lists the IP and MAC of every device your PC has recently talked to, and Get-NetNeighbor in PowerShell does the same with more detail. Both are instant and free. Neither tells you what those devices are. For names, vendors, open ports, and a security view you need a real scanner.

On a Mac the command-line half still works (arp -a is there too), but there has been no bundled graphical scanner since Network Utility was removed. We looked at nine that do run on macOS separately.

What Windows already gives you

Open a terminal and run arp -a. You get a table of IP addresses paired with MAC addresses for hosts in your ARP cache. It's the fastest possible answer to "what's on my network right now", but it only shows devices your machine has recently exchanged traffic with, so it misses quiet ones.

PowerShell goes a step further:

Get-NetNeighbor -AddressFamily IPv4 | Where-Object State -ne "Unreachable"

To force devices to appear, ping the whole subnet first so the ARP cache fills:

1..254 | ForEach-Object { Test-Connection -Count 1 -TimeoutSeconds 1 "192.168.1.$_" -ErrorAction SilentlyContinue }

The third free option is your router. Log into its admin page (usually 192.168.1.1) and open the DHCP client or connected-devices list. It sees everything that asked for a lease, including devices your PC never contacted. The catch is that router lists are often stale and label everything by hostname or a bare MAC, so a smart plug and a security camera look identical.

Turning a MAC address into a real device name

A raw scan gives you numbers. Identification is the work of turning a4:cf:12:... into "TP-Link smart plug". The first three bytes of a MAC are the OUI, an IEEE-assigned vendor code, so you can look up the manufacturer against the public OUI registry. Names come from a mix of reverse DNS, mDNS/Bonjour, and NetBIOS queries. Rolling that yourself is fiddly; it's exactly what dedicated scanners automate.

Free GUI scanners and where they stop

Advanced IP Scanner, Angry IP Scanner, and SoftPerfect are the usual free picks on Windows, and for a quick sweep they're fine. Where they tend to stop is depth. Most give you IP, MAC, hostname, and a vendor guess, then leave you there. They don't score which open ports are risky, they don't flag a device still answering on Telnet or exposing RDP, and they don't keep watching after the scan finishes. If you've outgrown that, the Advanced IP Scanner alternative rundown lays out what a deeper tool adds.

Live per-device bandwidth needs Npcap

One thing worth knowing before you expect too much: measuring how much bandwidth each device is using in real time requires packet capture, and on Windows that means the Npcap driver installed. No capture driver, no live per-device throughput. Any scanner promising bandwidth without it is estimating, not measuring. DeviceShelf prompts to install Npcap on first run for exactly this reason, and works without it for everything except live traffic graphs.

Where DeviceShelf fits on Windows

DeviceShelf runs as a native Windows app and does the identification, port enumeration, and security scoring in one pass. It discovers every device, resolves vendor and hostname, guesses OS and device type, lists open ports and services, and produces a prioritized report that flags exposed services, default-credential risks, and CVE hints. It keeps monitoring after the first scan, so a new device joining triggers an alert instead of going unnoticed. If you want a feature-by-feature look against the free tools, the comparison page covers it honestly.

It's local-first: no account, no telemetry, the license check works offline. There's a free 7-day trial with no account needed if you want to run it against your own network before deciding. A license is a one-time €59, not a subscription.

The short version

Start with arp -a and your router page to see what's there. Move to a GUI scanner when you want names and ports without typing. Reach for a monitoring tool when identification depth, a security view, and new-device alerts matter more than a one-off list. And remember that live bandwidth on Windows always needs Npcap underneath.

Is an open port dangerous? Which ones actually matter

DeviceShelf — Thu, 27 Aug 2026 09:00:03 +0000

An open port on its own is not a vulnerability. It means a program is listening for connections on that number. Whether it matters comes down to two things: what service sits behind it, and who can reach it. Open only inside your LAN, most ports are harmless. Exposed to the internet on an outdated or unauthenticated service, they become the way in.

What an open port actually is

When a device offers a service, such as file sharing, a web admin panel, or remote desktop, it binds to a TCP or UDP port and waits for connections. Port 443 serves HTTPS, 22 is SSH, 445 is Windows file sharing. A scanner reports a port as "open" when something answers on it; "closed" or "filtered" means nothing responded. The number itself is just a label. The software behind it is what can be attacked.

Which open ports are genuinely risky

Not every open port carries equal weight. A short watchlist worth checking first:

Telnet (23) sends everything, passwords included, in cleartext. There is no safe reason to run it. Replace it with SSH.
RDP (3389) is remote desktop, a constant brute-force and ransomware target. Never expose it directly to the internet; put it behind a VPN.
SMB (445) is Windows file sharing, the vector behind WannaCry. Fine on a trusted LAN, dangerous on the open internet.
Unauthenticated web panels on routers, cameras, NAS boxes and printers, still running default or blank admin passwords.
Exposed databases like MongoDB (27017), Redis (6379) or Elasticsearch (9200) bound to 0.0.0.0 with no authentication. Entire breaches have started here.

How to check what's really listening

Knowing a port is open is half the picture. You want the service and version behind it. nmap does this with the -sV flag:

nmap -sV 192.168.1.0/24

This scans the subnet and probes each open port to name the service and, often, its version. A result like 445/tcp open microsoft-ds Samba smbd 4.15 tells you far more than "445 open," and an old version is your cue to check for known CVEs.

Running nmap across a whole network and reading the raw output takes patience. DeviceShelf does the same enumeration in one pass and adds a plain-language risk report per device: it flags exposed services like Telnet and RDP, runs default-credential checks, and hints at relevant CVEs. It works locally, with no account. If you're weighing it against other tools, the scanner comparison lays out where each one stops, and the Fing alternative writeup covers that switch in particular.

LAN-only or internet-exposed? That's the real question

For most home and small-office ports, the honest answer to "is this dangerous" is: only if something outside can reach it. Check two things. First, is the service bound to 127.0.0.1 (localhost only), your LAN IP, or 0.0.0.0 (everything)? Second, does your router forward that port? Open the port-forwarding page and look for manual rules as well as any UPnP entries you never created. A database on 0.0.0.0 behind a router with no forward is exposed to your LAN, not the internet. Still worth fixing, but not a fire drill.

How to close or firewall a port

Three levers, roughly in order of preference:

Stop the service if you don't use it. A disabled Telnet or SMB service closes the port outright.
Rebind it to localhost or the LAN instead of 0.0.0.0 in the application's config.
Firewall it. Block the port at the host (Windows Firewall, ufw, pf) or at the router, and delete any port-forward or UPnP rule you didn't add on purpose.

Then re-scan and confirm the port now reads closed or filtered.

Keeping an eye on it after the fix

Auditing ports once is worth doing, but the exposure that actually bites is usually the one that appears later, when a new device joins or a service quietly auto-enables itself. DeviceShelf watches for that in the background and alerts you when a new listening service shows up. There's a free 7-day trial, no account needed.

Why does my phone show a random MAC address on Wi-Fi?

DeviceShelf — Tue, 25 Aug 2026 09:00:02 +0000

Your phone shows a random MAC address because modern operating systems generate a fake hardware address for each Wi-Fi network you join, so networks can't track your device across cafes, airports and offices by its permanent address. iOS 14, Android 10 and current Windows 10/11 all do this by default. It is a privacy feature, not a sign of an intruder.

What is MAC randomization?

Every network adapter ships with a burned-in MAC address, and its first three bytes (the OUI) identify the manufacturer. That address used to be broadcast on every network you touched, which turned it into a tracking cookie for the physical world. Retailers and public hotspots logged it to follow foot traffic.

Apple, Google and Microsoft closed that hole. Since iOS 14 and Android 10 in 2020, and in recent Windows, the OS invents a random MAC per SSID and presents that instead of the real one. Rejoin the same network and you usually get the same random address back. Join a new one and you get a fresh address. Some Android builds rotate it periodically even on a network you already trust.

How can I tell a MAC address is randomized?

Look at the second character. A randomized, "locally administered" address has a specific bit set in its first byte, which in practice means the first octet ends in 2, 6, A or E. So A2:..., 7E:... or 36:... are locally administered; a genuine vendor address like A4:CF:12 (an Espressif prefix) is not. The clearest tell in any device list is a MAC that resolves to no manufacturer at all. That is almost always a phone or laptop with private addressing switched on, not a mystery attacker.

Why does a random MAC break vendor lookup and allow-lists?

Two things stop working. Vendor identification through OUI lookup returns nothing, because the locally administered prefix belongs to no company in the IEEE registry. And MAC-based Wi-Fi allow-lists (the "only these addresses may connect" table in your router) become unreliable, because the same phone reappears under a different MAC after a reinstall, an OS update, or a "forget this network." MAC filtering was always weak security theater, and randomization has quietly finished it off. Bind access to a WPA2/WPA3 passphrase, not to hardware addresses.

How do I identify a device with a random MAC anyway?

The MAC is a dead end, so pivot to the signals randomization doesn't touch:

Hostname. DHCP and mDNS still carry a name. Lisas-iPhone or Pixel-7 identifies the device outright. nmap -sn or your router's client list will show it.
Behavior and services. Open ports and mDNS/SSDP announcements reveal the platform: an iPhone answers on _apple-mobdev, a Chromecast advertises _googlecast. Run nmap -sV against the IP to fill in the rest.
A name you assign once. The practical fix is a scanner that remembers a device across scans even when its MAC changes, so you label "Lisa's iPhone" a single time and it stays labeled.

DeviceShelf does all three in one local pass: hostname resolution over DNS/mDNS/NetBIOS, port and service enumeration, an OS and device-type guess, and persistent per-device naming that survives a MAC rotation. It runs on your own machine, with no account and no telemetry.

If you're weighing scanners on exactly this behavior, the feature comparison against Fing, LanScan and Angry IP covers how each one handles randomized addresses, and the Fing alternative writeup goes deeper on the local-first difference.

The short version

A random, vendor-less MAC on your network is the expected, healthy default for any recent phone or laptop. Don't chase it as a threat. Identify devices by hostname, by the services they run, and by a name you set once, then lock your Wi-Fi with a strong passphrase rather than a MAC allow-list. If you want that identification done in a single scan, DeviceShelf has a free 7-day trial, no account needed.

"How to Secure Your Home Network: A Practical Checklist"

DeviceShelf — Sun, 23 Aug 2026 09:00:02 +0000

Securing a home network comes down to a short, repeatable checklist: replace the router's default password, enable WPA3, isolate IoT devices on a guest network, disable WPS, close ports you don't need, patch firmware, and keep an eye on what's actually connected. None of it needs enterprise gear. Here is each step in the order that matters.

Prefer to tick it off as you go? There's a printable one-page version you can save or print.

Start by knowing what is on your network

You can't secure what you can't see. Open your router's admin page and look at the DHCP client or connected-devices list. It shows IP and MAC addresses, and often hostnames. Cross-check each MAC's first three bytes (the OUI) against a vendor lookup to guess the manufacturer. Anything you can't account for gets investigated.

For a fuller picture, nmap -sn 192.168.1.0/24 sweeps the whole subnet and lists live hosts. A dedicated scanner does the same faster and adds identification. DeviceShelf discovers every device on the LAN, resolves hostnames over DNS, mDNS and NetBIOS, guesses the OS and device type, and runs entirely on your machine with no account. If you already use Fing, the Fing alternative page covers what a local-first tool does differently.

Change the router's default password first

Default admin credentials are the single most exploited weakness in home networks. Log into the router, change the admin password to something long and unique, and while you're there rename the default SSID if it reveals the model. This is the one step that undoes the most common attacks, so do it before anything else.

Turn on WPA3, or at least WPA2

In the wireless settings, set encryption to WPA3 if every device supports it. Mixed networks can use WPA2/WPA3 transitional mode. Avoid WPA/WPA2-TKIP and never run an open network. Pick a Wi-Fi passphrase of at least 12 characters that isn't reused anywhere else.

Put IoT devices on a guest network

Smart plugs, cameras and TVs are the least trustworthy things you own, and many phone home constantly. Move them onto a guest or separate SSID that has client isolation enabled, so a compromised bulb can't reach your laptop or NAS. Most consumer routers support this in a few clicks; prosumer gear lets you split it into a proper VLAN.

Turn off WPS, and check UPnP

WPS (the push-button or PIN pairing shortcut) has a known brute-force weakness. Disable it. UPnP is more nuanced: it lets devices open inbound ports automatically, which is convenient for game consoles but can silently expose services to the internet. If you don't rely on it, turn it off and forward ports manually instead.

Find your exposed ports and risky services

This is where most home users are flying blind. A device with Telnet (port 23), an open RDP (3389), or an unauthenticated web panel is a real problem. Run nmap -sV 192.168.1.50 against a host to list open ports and service versions, then ask whether each one needs to be reachable.

DeviceShelf turns this into a prioritized security report: a risk score per device, flags for exposed services like Telnet and RDP, default-credential checks, and CVE hints tied to the software it finds. It won't fix anything for you, but it tells you where you actually stand. The DeviceShelf comparison page lines up how that reporting differs from other LAN scanners.

Keep firmware updated

Check the router first, since it's the gateway everything passes through, then work down to APs, NAS boxes and IoT hubs. Enable automatic updates where the vendor offers them and you trust the track record. Retire any device that no longer receives security patches.

Watch for devices you don't recognize

Security isn't a one-time scan. New devices appear, guests connect, and something unexpected shows up eventually. Continuous presence monitoring with new-device alerts catches that without you re-checking by hand, and per-device bandwidth helps spot a machine behaving oddly.

If you'd rather see all of this on one screen instead of stitching nmap output together, DeviceShelf offers a free 7-day trial, no account needed. Either way, run the checklist top to bottom once, then revisit it every few months.

Self-hosted network monitoring for homelab and office

DeviceShelf — Fri, 21 Aug 2026 09:00:05 +0000

Self-hosted network monitoring means running the software that watches your network on your own hardware, with the data staying on your LAN instead of a vendor's cloud. You get device discovery, uptime checks, and alerts from a box you control, with no external account and no telemetry leaving the building.

What does self-hosted network monitoring actually mean?

Two things separate it from a SaaS dashboard: the software runs on hardware you own, and the data never leaves your network. A cloud monitor pushes findings to someone else's servers; a self-hosted one keeps inventory, history, and alerts on a machine in your rack or on your desk. For a homelab or small office that means no per-device pricing, no account to lose access to, and nothing about your internal topology sitting in a third party's database.

You can assemble this from parts. nmap -sn 192.168.1.0/24 sweeps a subnet for live hosts. A cron job hitting ping or curl on critical boxes gives you crude uptime. Your router's DHCP lease table lists MAC addresses you can look up against the OUI registry to guess a vendor. It works, but you end up gluing scripts together and reading raw output.

What to monitor: uptime, discovery, and alerts

Three jobs cover most of what a homelab needs. Discovery answers "what is on my network right now": every device, its MAC/OUI vendor, hostname via DNS, mDNS or NetBIOS, an OS guess and a device type. Uptime answers "is it still reachable," ideally with history so you can see a pattern rather than a single failed ping. Alerts close the loop, so you know when something new joins the network or a known host drops without watching a screen.

DeviceShelf does all three from one local scan. It discovers and identifies each device, enumerates open ports and services, and runs continuous presence monitoring that fires a new-device alert the moment an unknown MAC appears. It also builds a prioritized security report flagging exposed services like Telnet or RDP and default-credential risks, which is the part hand-rolled scripts rarely cover.

How to run it 24/7 headless

Continuous monitoring only works if it is always on, which means a headless box rather than an app you open. The DeviceShelf server edition is built for that: it ships as a Docker image, a .deb package, or a Windows service, so you can run it on a NAS, a Raspberry Pi, a mini PC or a VM and leave it. Because it needs to see Layer 2 traffic for discovery, run the container with network_mode: host rather than a bridged network.

Set the scan interval to match your network's churn. A stable home LAN is fine every few minutes; a busier office might scan more often. Route alerts to ntfy, Gotify, a webhook or email so the box can tell you what changed while you were away.

If your current setup is Uptime Kuma and you want discovery and identification on top of the uptime checks, the Uptime Kuma alternative comparison lays out where the two overlap and where they differ.

Keeping the data on your own network

The point of self-hosting is control, so check what leaves the box. DeviceShelf is local-first: no account, no telemetry, and the license check works offline. Inventory, history and reports stay on the device. That matters when your network map is something you would rather not hand to a vendor, and it is often the deciding factor for regulated or air-gapped setups.

Querying your network with AI

If you want to ask questions instead of reading tables, the server edition can expose its live inventory to an AI assistant over MCP. The AI part is bring-your-own-key and entirely optional. Point it at Anthropic, OpenAI or a local Ollama model, or skip it. Nothing is sent anywhere unless you turn it on.

The server edition is young but usable, and it is included in the one-time €59 license rather than sold separately. If you want to try the always-on setup first, there is a free 7-day trial, no account needed.

Who Is on My Wi-Fi? See Every Device and Spot Intruders

DeviceShelf — Wed, 19 Aug 2026 16:30:53 +0000

To see who's on your Wi-Fi, open your router's admin page and look at its connected-devices list, or run a network scanner that pings every address on your subnet. Each entry shows an IP, a MAC address, and often a hostname. From there you match each device to something you actually own, and whatever's left over is worth a closer look. If one of those leftovers turns out to be real, changing your Wi-Fi password disconnects everyone at once.

Start with your router's device list

Type your router's address into a browser (often 192.168.1.1 or 192.168.0.1, printed on a sticker on the box). Log in, then find a section called Attached Devices, DHCP Clients, or Connected Devices. You get a table of everything the router has handed an address to: IP, MAC, and sometimes a name.

This is the fastest free check, but router lists have limits. They often miss devices on a guest network or a second access point, they drop stale entries slowly, and the names are frequently blank or cryptic.

Read the MAC address and vendor (OUI)

Every network device has a MAC address, six pairs of hex like a4:83:e7:2b:19:0c. The first three pairs are the OUI (Organizationally Unique Identifier), assigned to the manufacturer. a4:83:e7 maps to Apple, for instance. Look the prefix up in any OUI database and an anonymous row becomes "some Apple device."

Vendor alone rarely finishes the job. A house full of Apple gear turns into a wall of "Apple, Apple, Apple," and you still have to work out which entry is the iPhone and which is the Apple TV.

Get real names with hostnames and mDNS

Hostnames close some of that gap. Many devices announce a name over DHCP or mDNS/Bonjour, like Christofs-MacBook or living-room-tv. NetBIOS does the same on older Windows networks. A scanner that queries all three resolves far more names than the router shows on its own.

Why randomized MAC addresses confuse things

Since iOS 14, Android 10, and recent Windows builds, phones use a random MAC per network by default, and some rotate it over time. The upside is privacy. The downside for you is that a phone can show up under a vendor prefix that no longer maps to its maker, and a device you already trust can look brand new after a rotation.

This is also the wrinkle most likely to fake an intruder. Before you assume the worst, test it directly: turn Wi-Fi off on a phone you suspect and watch whether the mystery entry disappears. Look at the vendor too. A randomized MAC often reads as "locally administered" or an unknown vendor rather than a clean Apple or Samsung block. And if an entry only shows up when one particular family member is home, it is theirs.

The broader fix is to match on hostname and behavior rather than MAC alone, and to name devices in a tool that remembers them across scans, so a rotated address doesn't reset your whole inventory. If the randomization itself is what puzzles you, we've covered why your phone shows a random MAC address separately.

Name everything in one pass with a scanner

Doing all of the above by hand is slow. A scanner sweeps the whole subnet, collects MAC/OUI vendor, hostname, an OS guess, and open ports, then hands you one labeled inventory. nmap does this from the command line (nmap -sn 192.168.1.0/24 for a quick host sweep). GUI tools do the same with less typing.

DeviceShelf is one such scanner. It discovers every device on your LAN or Wi-Fi, identifies each by vendor, hostname, and type, and lets you rename and pin the ones you recognize so the list stays meaningful next time. It runs locally, with no account and no data leaving your machine, which is why people looking for a private alternative to Fing tend to land on it. If you're weighing tools, our comparison of network scanners shows where each one fits.

Match every device against hardware you own

Now the tedious but decisive part. Walk through the place and count: phones, laptops, tablets, the TV, a streaming stick, the console, printer, robot vacuum, smart plugs, thermostat, doorbell, speakers, the router itself, and any range extenders. Write them down, then cross each one off the scan.

The MAC vendor is your best clue here. A prefix that resolves to Amazon is probably an Echo or Fire TV. Espressif or Tuya usually means a cheap smart-home gadget. Apple, Samsung, and Google cover most phones and laptops. Line up hostnames where you can. Smart-home gear is the hardest group to pin down, so there's a separate walkthrough on finding IoT devices on your network.

Once every entry is named, the unknowns stand out. Go one by one: power a suspect device off and see which row drops, or check the vendor against what you own. A camera vendor you don't recognize, an open Telnet port, or a host that only appears at odd hours all deserve a second look. Open ports are worth understanding before you judge them, and our guide to what an open port actually means covers which ones matter.

What to do if someone really is on your Wi-Fi

If a device survives all of that and you're confident it isn't yours, the fastest fix is to lock everyone out and let your own gear back in.

Change the Wi-Fi password. This kicks every device off instantly, the intruder included, and they can't rejoin without the new key. Reconnect your own hardware afterward.
Switch to WPA3, or at least WPA2-AES. Never run WEP or an open network. WPA3 makes offline password guessing far harder.
Disable WPS. Its 8-digit PIN is brute-forceable and a well-known way in.
Move IoT gadgets to a guest network. A cheap camera with weak firmware has no business sharing a subnet with your laptop.

Changing the password is the step that actually disconnects someone. The rest stops them from coming back. For the full pass over your router settings, work through the home network security checklist.

Why a one-time check isn't enough

A manual sweep only catches whoever is connected the moment you look. It says nothing about last night or next week. Someone who joins at 2am and is gone by morning never appears in a check you run at noon.

Continuous monitoring closes that gap. The network gets watched around the clock, you approve the devices you own once, and an alert fires only when a genuinely new one shows up. DeviceShelf does this on the desktop while your computer is awake, or 24/7 on a Raspberry Pi or NAS with the server edition. That always-on watch is one of the main things separating it from a pull-to-refresh phone app.

You can do every step here with free tools and some patience. If you'd rather get the labeled list and the alerts in one pass, DeviceShelf has a free 7-day trial, no account needed.