This week The Register covered Linus Torvalds' latest position on AI in the Linux kernel: maintainers will stop asking whether a patch was written with AI assistance. If the developer is competent and the code is good, it merges — nobody is going to interrogate the tooling. What remains absolutely unacceptable is the 'drive-by' patch: a change dumped on the mailing list by someone who does not know the codebase, has not done the testing, and cannot explain what it touches or what it breaks.
Read that as an IT operations story and it should sting a little. The Linux kernel has a hard gate: nothing reaches production without being reviewed against the actual state of the tree. Your network has nothing. Anyone with a laptop and physical access to a wall port can merge straight into production — a $19 unmanaged switch under a desk, a consumer Wi-Fi router marketing bought on sale, a vendor's IP camera, a printer moved to a different closet overnight. Drive-by devices: unreviewed changes to production infrastructure that nobody documented and, in most environments, nobody monitors.
The other half of Torvalds' point matters just as much. Nobody cares who or what produced the change — what matters is whether the state is known, verified, and sound. Your network team should run on the same principle. You should not have to care who plugged in the device or why. You should have tooling that catches it in seconds, names the exact port it connected to, and shows you everything downstream of it.
Most IT teams cannot do that today. Here is why — and what to do about it.
The Problem: Your Monitoring Only Knows What You Told It
Agent-based RMM is blind by design. NinjaOne, ConnectWise RMM, Datto — all excellent at watching devices that carry the agent. The unmanaged switch does not take an agent. Neither does the IP camera, the badge controller, the HP LaserJet in accounting, or the vendor's laptop that visited for an afternoon. An RMM gives you deep truth about managed endpoints and complete silence about everything else — and everything else is where network incidents actually start.
Standalone monitoring watches a list, not a network. PRTG, SolarWinds, and LibreNMS poll exactly the devices somebody manually added. When a switch was installed during a hectic office move and never added, it does not exist — until the day it dies and takes fourteen desks with it, silently. Even for the devices you do monitor, a classic ping sensor returns 'host is down', not 'the uplink on port Gi1/0/17 of SW-FLOOR3-02 flapped and these twelve endpoints depend on it'. You get symptoms, never topology.
Discovery, where it exists, is a batch job. A nightly scan that exports a CSV nobody opens. By the time anyone reads it, three people have moved desks, a vendor installed a camera, and a switch got swapped. The map is a snapshot; the network is a stream.
Documentation is fiction with good intentions. The Visio diagram is from 2022, before the remodel. The port spreadsheet died with the last admin. The real map lives in one senior tech's head — the same tech who just booked two weeks of PTO.
The helpdesk has no network context. The ticket says 'Wi-Fi is slow on floor 3'. The technician has a queue, a ping tool, and questions: Which AP serves floor 3? What switch is it patched into? Is anyone else on that switch affected? Is this even wireless, or is an uplink degraded? Answering those questions means SSH sessions, show commands, and archaeology — before a single actual fix begins.
Why These Gaps Exist
They are architectural, not a skills problem. RMM, monitoring, ticketing, and documentation grew up as separate products, sold separately, so 'integration' usually means tab-switching and CSV exports. Discovery was designed as an inventory exercise — 'what do we own' — instead of a continuous verification process: 'what is actually connected right now'. And the network itself enforces no gate. DHCP will cheerfully hand a lease to a rogue router, and an unmanaged switch will silently bridge whatever gets plugged into it. The kernel rejects unreviewed patches; a wall port accepts anything.
What It Costs — Scenarios You Have Lived Through
- Rogue DHCP. Someone patches a consumer router's LAN port into the wall. Half a floor starts pulling 192.168.0.x addresses with the router as gateway. Connectivity dies for two to three hours while the team chases an 'ISP outage' theory, because nothing in the monitoring tool shows a DHCP conflict — the helpdesk queue just fills with 'no internet' tickets.
- Broadcast storm from a looped unmanaged switch. The core switch's ping sensor stays green, because the core is fine — the access layer is melting. VoIP calls break, and the first report comes from an angry sales manager, not from monitoring.
- Incident forensics. On a typical unknown-scope network incident, the first 15–30 minutes go to answering 'what is connected, through what path, and who is affected' — before one minute of fixing. That gap is the difference between a 20-minute outage and a 60-minute one.
- SLA reporting nobody trusts. The helpdesk says 98% on-time response. The monitoring tool logged three outages nobody ticketed. The IT manager presents a number the room does not believe.
- On-call dread. It is not caused by hard problems. It is caused by unknown ones — a 2 AM alert for an IP address with no name, no location, and no map.
How AlertMonitor Ends the Drive-By Device Problem
Continuous discovery, not quarterly archaeology. AlertMonitor continuously discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — using SNMP, ARP, and active scanning. Not a nightly batch: a continuously refreshed model of what is actually connected, updated the moment devices appear, move, or disappear.
A live topology map that reflects reality. The map always shows the real network state right now: which switch uplinks to which, what hangs off every port, where the APs are, and what is downstream of what. When a switch goes offline or a link drops, the map updates and the alert fires with the affected branch highlighted — scope is visible before anyone touches a keyboard.
Alerts with context, not just symptoms. A new device appears: the alert carries its IP, MAC, vendor (resolved from the OUI), and the port it connected to. An uplink flaps: the alert names the switch, the port, and the dependent devices. A switch goes offline: the alert includes what is downstream, so the on-call tech knows instantly it is a closet switch affecting one floor, not a core outage affecting the site.
The workflow difference is the whole difference. The old way: ticket arrives → open PRTG → check ping sensors → SSH into a switch → run show commands → consult the 2022 Visio → message the office manager to ask if anyone moved furniture → finally find the unmanaged switch. Twenty-five to forty minutes across four tools. The AlertMonitor way: the link drops on SW-FLOOR3-02 → alert fires in seconds with the port, the twelve downstream endpoints, and the topology branch highlighted → a ticket is created in the integrated helpdesk already carrying that context → the tech clicks through to the device and acts. Time-to-context: seconds. Time-to-fix: minutes.
For MSPs, this is one NOC view across every client. Discovery runs in each client environment automatically — no per-site tribal knowledge, no 'we never got a diagram from that client'. And because monitoring, RMM, helpdesk, and patch management share one data model, the ticket opened by a network alert already knows which devices are affected, whether they are patched, and how to reach them.
Practical Steps You Can Take Today
Before changing any tooling, measure the gap. These five checks take under an hour and tell you exactly how many drive-by devices you have.
1. Count what actually answers vs. what your inventory says
# Live sweep of a /24 — requires PowerShell 7 for ForEach-Object -Parallel
$subnet = "192.168.10."
$live = 1..254 | ForEach-Object -Parallel {
$ip = "$using:subnet$_"
if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { $ip }
} -ThrottleLimit 128
"Live hosts answering: $($live.Count)"
$live | Out-File "C:\Reports\live-hosts.txt"
If that number is meaningfully higher than your documented device count, you have drive-by devices. Most teams do.
2. Pull live MACs so you can identify vendors
# Export ARP entries — MAC OUI prefixes reveal who built each device
Get-NetNeighbor -AddressFamily IPv4 |
Where-Object { $_.State -in 'Reachable','Stale','Permanent' -and $_.IPAddress -notlike '169.254.*' } |
Select-Object IPAddress,
@{n='MAC';e={($_.LinkLayerAddress -replace '-','').ToUpper()}},
State, InterfaceAlias |
Sort-Object IPAddress |
Export-Csv "C:\Reports\arp-live.csv" -NoTypeInformation
Look up unrecognized MAC prefixes against the IEEE OUI list. A camera vendor's MAC sitting in a user VLAN, a router vendor's MAC in an office subnet — those are your rogues.
3. Diff live reality against documented inventory
From any Linux jump box:
# Everything answering that is not in the documented inventory
nmap -sn 192.168.10.0/24 -oG - | awk '/Up$/{print $2}' | sort > live.txt
sort documented-devices.txt > documented.txt
comm -23 live.txt documented.txt > undocumented-devices.txt
echo "Undocumented devices found: $(wc -l < undocumented-devices.txt)"
4. Hunt hidden unmanaged switches
Count MACs learned on access ports — more than a handful means something is hiding downstream:
# On the upstream switch: a long MAC list on an access port = unmanaged switch below it
show mac address-table interface GigabitEthernet1/0/17
5. Check for rogue DHCP servers
# Which DHCP server issued this lease? Anything that is not your DHCP server is an incident.
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\*" |
Where-Object { $_.DhcpServer -and $_.DhcpServer -ne '0.0.0.0' } |
Select-Object @{n='Adapter';e={$_.PSChildName}}, DhcpServer, DhcpIPAddress
Run these on a few representative machines — or push them through your RMM — and you will know within an hour whether your network has a drive-by problem.
6. Then make it continuous
Every script above is a point-in-time snapshot, and the network changes again tomorrow. That is the real lesson from the kernel: verification is not an event, it is a standing process — every patch reviewed against the live tree, continuously, forever. AlertMonitor applies the same discipline to your network: continuous discovery, a live topology map, and instant alerts whenever a device appears, a link drops, or a switch goes offline, each with the network context attached so response starts at fix, not at find-out-what-this-even-is.
Torvalds' rule for the kernel: no unreviewed changes, ever. The equivalent rule for your network: no unknown devices, ever. The first takes a maintainer. The second takes live visibility — and that you can switch on today.
Related Resources
AlertMonitor Network Monitoring & Visibility
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.