Solved. I’m leaving this instead of editing, in case anyone runs in to the same thing and finds this as a search result. Very likely considering how little I found searching.
The problem was the device names that I was trying.
First problem, and something that I will report as a bug, is that net.Interfaces() uses the display name for the Name property. This may have been intentional. If so, the bug is in the arpscan.go example (https://github.com/google/gopacket/blob/master/examples/arpscan/arpscan.go) where the property is used for the device name when initializing the handle with pcap.OpenLive()
Second problem is that Windows is a horrible operating system, and gives us no way (that I found) to get the actual interface name. Powershell get-netadapter gets close.
get-netadapter | where {$_.Name -eq “Ethernet”} | Select-Object -Property *
where “Ethernet” is the display name for the adapter I care about, gave
DeviceName : \Device{13044533-0543-4AF5-9E3C-85EBBC7C04BB}
and a few other properties that contain the GUID.
However, that isn’t the name that we need.
ipconfig, where it should be, is useless.
getmac /fo csv /v
gives me
\Device\Tcpip_{13044533-0543-4AF5-9E3C-85EBBC7C04BB}
Still not it.
I honestly still don’t know a consistent way to get the actual device name from every Windows box, but I noticed that some other systems that I looked at had the name format
\Device\NPF_{13044533-0543-4AF5-9E3C-85EBBC7C04BB}
(note the NPF_ that didn’t show up anywhere that I looked on this system)
So, in desperation, I gave it a shot. That’s what worked for me on this one pc that I’m working on today.
Unfortunately, without a way to get this name from something like net.Interfaces(), net.InterfaceByName(), or net.InterfaceByIndex() it will be hard to build something that will run on a machine that is isn’t tailor made for.
I blame Windows, but I hope google can give us the tools to work around it.