NetLay: Learning the network with nothing but what Windows already has

When nobody gives you the exports#

The importer two posts ago assumes somebody hands you a running configuration. Sometimes nobody will. You have no command line access, there may be no SNMP community you are allowed to know, and what you do have is a server sitting on the network with a perfectly good view of it.

So what can NetLay work out on its own, using nothing that is not already on a Windows machine?

Quite a lot, as it turns out, and none of it individually is clever.

Five cheap sources, stacked up.#

The first is a ping sweep. You give it subnets, either in CIDR form, as a range like 10.0.1.1-50, or as single addresses, and it works through them sixty four at a time. There is a cap of four thousand or so addresses, because somebody will eventually type a /16 in there and I would rather the app said no than spent an hour pretending.

The second costs nothing at all, which is the operating system's own ARP table. Your machine already knows the MAC address of everything it has spoken to recently, and arp -a prints it. A host that answers ARP but ignores pings is still a real device, and that is a category this tool was previously blind to.

The third is reverse DNS, because quite often the name is right there and nobody thought to look.

The fourth is the MAC vendor prefix. There is a built-in table of around three hundred and forty prefixes covering the kit you actually meet on a small network, and an option to download the full official list.

That last part had two amusing problems. The IEEE's own server replies with HTTP 418, "I'm a teapot", to anything that does not look like a browser, which is a genuinely funny way to be refused. Sending a normal browser user agent fixes it, and there are two mirrors behind it in case that stops working, each in a different file format. And the built-in names deliberately win over the downloaded ones, because the official entries are things like "Cisco Systems, Inc" with the registered address attached, while mine just say Cisco and map cleanly onto a device type. While I was in there I also found the name shortener had been trimming "Cisco" down to "Cis".

The fifth source is a handful of TCP ports. Twelve of them, with a short timeout. Ports 9100, 515 and 631 open means printer, and it is a printer, every time. 445 and 3389 means a Windows machine. SSH or HTTPS on something with a Cisco MAC prefix is almost certainly a switch.

Writing SNMP by hand.#

The one thing I did build from scratch is a small SNMP version 2c client, about two hundred and thirty lines, doing BER encoding and decoding, GET, GETNEXT and a simple walk.

That sounds like reinventing a wheel, and I thought about it for a while before doing it. The reasons it won: the three values I actually want are the system name, the system description and the object identifier, the last of which contains the vendor's enterprise number and therefore tells you who made the thing. That is a tiny subset of SNMP. Pulling in a full library would have meant a dependency with its own compiled parts, which fights directly with the promise that this application unzips into a folder and runs with no installer.

And it works more often than you would expect, because printers, UPSs, access points and switches are very often still answering on public whatever anybody intended.

Honest guessing.#

Everything above is evidence, not proof, so the classification is openly a set of heuristics. Print ports first because they are the most reliable, then the SNMP description, then the vendor, then the hostname, and only then the weaker patterns like remote desktop plus file sharing or a web interface on its own.

Every guess carries its reason with it in a tooltip. If the app thinks something is a printer it will tell you it thinks so because port 9100 is open, and you can disagree with it. A tool that guesses silently is a tool that quietly fills your documentation with confident nonsense.

Getting from a list to a map.#

Discovered hosts are kept, and matched against devices you already have by address or MAC, so running it again does not produce duplicates of everything.

Anything new has a place button, which creates the device on a switch port you choose, filling in the name, type, address, MAC, the vendor as the make, and the SNMP description in the notes.

The one thing this whole approach cannot possibly know is which switch port something is on. Nothing in a ping sweep, an ARP table or an SNMP description will ever tell you that. So you put it somewhere sensible, and when the switch output finally arrives, the reality check from post ten moves it to where it really is.

Which I think is quite a nice shape for a tool to have. Learn what you can from where you are standing, write it down honestly, and correct it later when better evidence turns up.

Next time, the half of the network with no cables at all.

NetLayNetworking