Let the network tell you where you are: a nerd snipe story
I was successfully nerd-sniped a few days ago and figured I'd share my proposed solution with everyone just in case they could benefit from it. I've added a few of my own constraints based on expectations for how things could go wrong. So, if this seems familiar, maybe it is, but I've made it a little more complicated.
The situation is basically this: there's a large space with a bunch of dumb Linux boxes which are attached to displays of some sort. Different things are displayed depending on where it is in the space. This means the Linux boxes need some sense of identity to be able to tell the server "I need this particular set of stuff". They're "hands off" - nobody wants to log in to them to manage them.
So now let me present some of the issues:
Problem: relying on IP assignments is no good, since the DHCP mechanisms for that network can't be trusted. Things are sufficiently flaky to where you can't rely on it, and part of this is from the next item.
Problem: the hardware is wonky enough to where it gets replaced sometimes, so the MAC addresses also end up changing. This means any other on-board identifier (board id, cpuid, whatever) would also change. It would be nice if someone didn't have to keep updating mappings on the server every time the hardware got shuffled around.
Problem: it's a PITA to stamp out unique images for these things. The goal is to be able to stamp out a single image that's identical for all of them, and then have them all boot from that and figure out their identities some other way. (The same goes for netbooting, if you're thinking of that already.)
Problem: any other "ID marker" type solution that involves twiddling the set of installed hardware somehow means that you have to be sure each one ends up in a specific spot. If you have relatively unskilled people running around installing these things, this might not be what you want. It's easier to just say "make sure there's one plugged in at every space on this list" without worrying about matching specific units to specific spots, in other words.
Wouldn't it be cool if you could just grab a box, plug it in a given spot, and it would somehow start displaying the right set of media? That's what I was thinking when I came up with this idea.
So, how do you do it? My "solution" (which has its own caveats) comes in the form of LLDP.
For those who haven't encountered it yet, here's the scoop: certain higher-end Ethernet switches have the potential to _multi_cast identifying frames every so often. Any given station on such a switch might get a LLDP frame from it a couple of times per minute.
In that frame, you can see interesting things, like the MAC address(es) of the switch, its name, what OS it might be running (!), the management IP addresses (!!), and, finally, what the name of YOUR PORT is.
Port Description TLV (4), length 4: eth2
Port Description TLV (4), length 8: Gi1/0/24
0x0000: 4769 312f 302f 3234
Yep, that's right, if you're on such a switch, you might well have something arriving on your interface every so often that says "oh by the way, you are connected to me on my Gi1/0/24". Another device on that same switch would get nearly the same announcement, but it might say "Gi1/0/48" or whatever else.
The point is: if you're that derpy little display machine, you now have a way to tell yourself apart from your "coworkers". You could build a tuple of (switch name, switch port) and kick that at the display server, and let it figure out what set of images/videos you're supposed to run.
Now, there's always a catch, and here it is: this assumes that you're not changing the mapping between ports on the switch and the actual RJ45s in the space. I'm assuming that port 23 on your switch will always be over there by the front door, port 24 will always be next to the bathrooms, and 25 will be by the patio door. You get the idea.
If those change, then yeah, you get to reconfigure everything, but at least it's still only on the server, and you don't have to deal with the dumb little display machines.
How do you see this? Well, tcpdump would be a start. A filter of "ether proto 0x88cc" will do the job, but make sure you stick a -v on there to make it actually expand the details (or it'll be pretty dull).
Some other things: a relatively low-end switch won't do anything in this space. It won't generate it, and it won't "absorb" it from other sources. So, if your listening post running tcpdump is plugged into such a beast, it might hear LLDP stuff coming from multiple other sources but it won't see anything from the switch itself. Yep, it's more than switches which potentially send these out. "Server class" systems with their own little management device ("BMC") glued onto them tend to do this, too.
Normally, such traffic would not cross the switch, but that requires a switch that actually "gets" it and knows to not forward it. Ordinary dumb switches will treat it just like any other bit of traffic and will send it on down the line.
I should also note that other protocols exist which serve similar purposes and it depends a lot on which switch vendor you've chosen. It might not be LLDP but it might be something else which ends in "DP".
If in doubt, sniff the network and find out!