We took over a site we hadn’t installed.
The server room was a mess. Cables unlabelled, no documentation, and nobody left on site who knew what was plugged in where. Hand-tracing every cable would have taken days — on site, in a working office, while staff were trying to get on with their jobs.
There are tools that map a network like this. Almost all of them are a monthly subscription, charged per device, forever. We would rather not rent software to solve a problem we can build ourselves.
So, we built our own, in an afternoon.
It is one command, run from a laptop plugged into the network. It comes back with four things.
Every device on the network, and who made it
Every piece of network hardware carries its manufacturer’s identifier inside its MAC address. Cameras, printers, tills, recorders, access points, switches — all identified without touching a single device or interrupting anything.
The physical switch port each device is connected to
This is the part that matters. The tool queries the switch’s own forwarding tables to build a wiring map without anyone opening a cable bundle.
It also reports the speed every port has negotiated and flags any that have quietly dropped below gigabit. That usually means damaged cabling, and it usually shows up long before anyone can explain why the network feels slow.
How many devices are handing out IP addresses
There should be exactly one. If there is more than one, the tool prints the fault in bold, along with the fix.
That single problem causes more ‘the internet keeps dropping’ support calls than almost anything else, and it can sit unnoticed for months.
Which IP ranges are genuinely available
When a CCTV installer needs eight addresses, we can give them a block we know is safe — instead of guessing, and accidentally creating a conflict that takes tills, printers or cameras offline a week later.
Two things that nearly caught us out
Worth saying, because they are the sort of detail that separates a network map you can trust from one that just looks professional.
The standard approach didn’t work. The protocol normally used to ask a switch what is connected to each port returned absolutely nothing on this model. We had to fall back to a newer method that it did support. If we had taken the first answer at face value, we would have concluded the switch had nothing plugged into it.
Port numbers lie. The port numbers a switch reports internally are not the numbers printed on the front panel. There is a translation step between the two. Get that wrong and you produce a very professional-looking document that sends the next technician to the wrong port — which is worse than having no document at all.
What we found
- A complete port map, with every device identified and located.
- An unauthorised device handing out IP addresses and redirecting traffic. It had been sitting on the network for months.
- A guest Wi-Fi network that had never worked since the day it was installed. The access point was running and the password was correct, but the network name was not being broadcast, so nobody could see it to connect.
That last one is the kind of fault that gets reported once, gets written off as user error, and then quietly stays broken for years.
The point
A network that was completely undocumented in the morning was fully mapped by the end of the day.
No cables untied. No downtime. Nothing purchased.
We build tools like this because the alternative is paying a subscription in perpetuity for something we only need to be right about once — and because a tool you have written yourself is a tool you can trust, fix and explain.