Comment by cantrevealname | Hacker News Reader

Comment by cantrevealname | Hacker News Reader

The key thing missing from this submission is: What is the intended use?

The only concrete usage example is on the deepmac.org home page where it says: For example, a CISCO device with a MAC prefix assigned in the 1990’s is more than likely an elderly model. OK, if I'm connecting to an ancient CISCO device, I suppose it might be handy to know that it might not support the latest protocols or might need updating.

But I think tracking people and network surveillance are the more likely uses. You connected with MAC address 3c:45:a3:6a:0d:76 at the coffee shop? That tells us that you were using an HP laptop manufactured in the October to November 2014 timeframe.

This database will be especially nice for finding people who spoofed their MAC address, and therefore deserve extra scrutiny. You used an impossible (never issued) MAC of ef:22:7b:09:09:ba to connect to the Internet. Or the MAC was issued in 1999 and it's unlikely that you're still using such an old laptop. Why are you changing your MAC address? We need to investigate you.

Maybe we can use this database "in reverse" to make sure all spoofed MAC addresses look real.

Your being conspiratorial...

In my job, I am cleaning up (maybe more like 95% throwing out than cleaning up) some 30 year old equipment pileup across 4 separate server rooms. Ancient workstations and servers, such as Sun SPARC's, SGI's, Sun Oracles, HP-UX, AIX, and even a mainframe or 2 that have sat turned on and running an OS and networked (so respond to ping), but are actually lying dormant, stuffed in a closed door rack and networked in (often with long forgotten passwords).

This tool was something I wished I had (and searched all over for) to quickly catalog the approximate age of each responding ping. I could use this to further say hey this set is 1-10, this one 10-20 yrs old, and the last set 20-30. I can safely de-rack the 10-30 now, and work on rooting in to the remaining 1-10 yr systems over time. Instead, I have to root one rack at a time, and guess/research at many of the ages of the systems, which increased the work significantly.

Why? A good question. Research scientists and interns deployed them for projects. And when the project was done, a research scientist doesn't want to lose valuable research data. Since they are paid for, why not just leave them up. That, and the old sysadmin just retired - think of The Bastard Operator From Hell, but in real life, 20 years on.

This seems like a really complex way to solve a simple problem. Have an intern spend a day creating Visio diagrams of each room capturing model numbers. Trying to do this from a network perspective just seems like an easy way to miss half the systems or whatever percentage isn't powered on or connected.

The MAC OUI archives are, as pointed out in the very first paragraph on the README, already public knowledge and have been for a very very long time. All competent MAC address randomizers have a function to keep the current OUI, and most have the function to manually set an OUI. I haven't heard of any that load a list of OUIs, but it's certainly theoretically possible.

The entire point is moot though. As far as I know, all standard MAC address randomizers set the "locally administered" bit, so it is trivial to identify them. In fact, googling quickly, apparently Cisco APs already have a function to prevent these devices from connecting.

This type of thing can be invaluable from a support perspective. For example, the ability to type in a company name and see a list of their OUI is a pretty nice feature I've not seen on other lookup tools like Wireshark's offering.

> finding people who spoofed their MAC address, and therefore deserve extra scrutiny

> Why are you changing your MAC address? We need to investigate you.

Both iPhones and Windows 10 have MAC randomisation built in for wifi. I hope you have a big budget for investigations.

It's trivially easy to limit your pool of possible spoofed macs to only "reasonable" ones.

Reply on news.ycombinator.com