Bundled arp-scan OUI database missing recent vendor entries (e.g. several Apple MAC blocks)

[gbomacfly]

Summary

The bundled arp-scan OUI vendor database (/usr/share/arp-scan/ieee-oui.txt) is missing entries for several currently-registered MAC prefixes, causing WatchYourLAN to show "Unknown" for devices whose vendor is actually known and correctly resolvable via other sources (e.g. the Wireshark manuf database, macvendors.com).

Environment

• WatchYourLAN image: aceberg/watchyourlan (latest as of Aug 2026)
• Dependency in use: arp-scan (vendor lookup comes from arp-scan's bundled /usr/share/arp-scan/ieee-oui.txt, not from WatchYourLAN itself)

Evidence

Three Apple devices on my network show as "Unknown" in WatchYourLAN, despite having entirely standard, non-randomized, IEEE-registered MAC prefixes:

Device	MAC prefix	arp-scan ieee-oui.txt	macvendors.com	Wireshark manuf
iPhone	78:3F:4D	NOT FOUND	Apple, Inc.	Apple, Inc.
iPad	14:20:5E	Apple, Inc. (found)	Apple, Inc.	Apple, Inc.
Apple Watch	EC:FF:3A	NOT FOUND	Apple, Inc.	Apple, Inc.

None of these are locally-administered/randomized addresses (the locally-administered bit is not set on any of them), so this isn't a case of MAC randomization — they're genuine, IEEE-registered Apple OUI blocks that are simply missing from the arp-scan database currently shipped in the image.

For contrast, plenty of other devices on the same network resolve correctly through the same database, confirming the DB is generally functional, just incomplete for some (possibly more recently registered) blocks:

• Xikestor 10G switch → Anhui Seeker Electronic Technology Co., Ltd. ✓
• Bambu Lab X1C → AMPAK Technology ✓
• Steam Deck → Quectel Wireless Solutions Co., Ltd. ✓
• Xiaomi smart fan → Beijing Xiaomi Mobile Software Co., Ltd. ✓
• Various BSH kitchen appliances → BSH Hausgeräte ✓
• Proxmox LXC containers (bc:24:11:xx:xx:xx) → Proxmox Server Solutions GmbH ✓

I also double-checked two other entries I initially suspected were wrong (not just missing) — both turned out to be correct on closer inspection, so this issue is specifically about missing/stale entries, not incorrect ones:

• pve (Proxmox host, 3C:78:95) → confirmed TP-Link Systems Inc. via macvendors.com (this host has a dedicated 10GbE NIC, not an onboard motherboard controller, so a TP-Link-branded card checks out)
• pbs (TrueNAS container, 10:66:6A) → confirmed Zabbly via macvendors.com

Root cause

arp-scan's bundled ieee-oui.txt (used for vendor lookups) is a static snapshot baked into the image and only updated when the arp-scan package itself is updated upstream (e.g. via Alpine's package repo). It appears to lag behind more actively-maintained sources like Wireshark's manuf file, which is regenerated weekly from the current IEEE registry.

Suggested fix

Generate a fresher OUI database at image build time instead of relying solely on the OS-packaged arp-scan database. A minimal example (tested locally, converts Wireshark's manuf file into arp-scan's expected format):

curl -fsSL -o manuf https://www.wireshark.org/download/automated/data/manuf
awk -F'\t' '
!/^#/ && NF>=3 {
  addr=$1
  prefixlen=24
  if (addr ~ /\//) {
    split(addr, parts, "/")
    addr=parts[1]
    prefixlen=parts[2]+0
  }
  gsub(":", "", addr)
  hexlen=prefixlen/4
  print substr(addr, 1, hexlen) "\t" $3
}' manuf > ieee-oui.txt

This produced ~58k entries (vs. the ~47k currently in the image) and correctly resolved all three previously-missing Apple prefixes above. Happy to open a PR adding this as a build step in the Dockerfile if that's the preferred approach — wanted to check first whether you'd rather handle this differently (e.g. a runtime update mechanism, a scheduled job, or pinning a newer arp-scan version instead).

Workaround (in the meantime)

Bind-mounting a manually-refreshed ieee-oui.txt over /usr/share/arp-scan/ieee-oui.txt works fine as a stopgap for anyone hitting this now.