Skip to content

On-Premise Device Discovery by MAC OUI

On-premise device discovery by MAC OUI is a field technique used by Astradial engineers to locate a specific network appliance — such as a Grandstream analog telephone adapter (ATA), a Matrix Comsec PBX, or an IP phone — on an unfamiliar client local area network (LAN), without prior knowledge of its IP address. The method identifies devices by the Organizationally Unique Identifier (OUI), the first three octets of a hardware MAC address, which the IEEE assigns to each manufacturer. It relies only on standard operating-system networking utilities and is designed to be non-intrusive, making it suitable for sensitive environments such as hospitals and diagnostic ("scan") centres.

Type Network reconnaissance / field procedure
Layer Data link (L2 ARP) + application probe (HTTP)
Primary tools arp, ping, nc, curl, ipconfig/ip
Reference script find-grandstream.sh
Platforms macOS (primary), Linux (NUC/Debian)
Intrusiveness Low — 1 ICMP + 1 TCP SYN per host
Key data source IEEE OUI registry

Overview

When an engineer arrives at a client site, a target device (PBX, ATA, intercom, camera NVR) is frequently already installed but its IP address is undocumented. Because every Ethernet device must answer Address Resolution Protocol (ARP) requests to communicate on its subnet, its MAC address — and therefore its vendor OUI — can be observed even when the device blocks ICMP "ping" or exposes no obvious service. Matching the observed OUI against a known vendor prefix isolates the target among dozens of unrelated hosts (workstations, cameras, medical equipment).

The procedure has three stages: populate the ARP cache with a gentle sweep, match the cache against the target vendor's OUI, and probe the matched host's web interface to confirm the model.

Background

Organizationally Unique Identifier

A 48-bit MAC address is divided into a 24-bit OUI (vendor) prefix and a 24-bit device-specific suffix. The IEEE publishes the full registry of assignments. Two caveats affect field use:

  • Stale free-API results. Public lookup services (e.g. api.macvendors.com) often return the original historical registrant of a legacy block. For example 00:C0:2D resolves to "Fuji Photo Film", a 1980s assignment. For authoritative results, grep the IEEE CSV directly by company name.
  • OEM network chips. Some appliances ship with a third-party NIC OUI rather than the brand's own. A device whose application identifies as one vendor may carry an ECS, Realtek, or similar OUI.

Layer-2 visibility limits

ARP is confined to a single broadcast domain. A scan of 192.168.1.0/24 issues ARP requests only for 192.168.1.x targets; a device statically configured on a different subnet (e.g. 192.168.0.x) or VLAN, even while plugged into the same physical switch, will not reply and is therefore invisible. Absence from one subnet sweep is not proof the device is absent from the premises.

Methodology

Stage 1 — Populate the ARP cache

A device is only listed in the ARP table after the host has resolved its MAC. To force resolution gently, send a single ICMP echo and a single TCP SYN to port 80 of every host in the subnet. ARP resolution precedes the IP packet, so the target's MAC is learned even if it blocks ICMP and runs no web server.

for i in $(seq 1 254); do
  ( ping -c1 -W1 "192.168.1.$i" >/dev/null 2>&1 & )
  ( nc -z -G1 "192.168.1.$i" 80 >/dev/null 2>&1 & )
done
sleep 5

Stage 2 — Match the OUI

arp -a -n | grep -iE "ec:74:d7|c0:74:ad|0:b:82"   # Grandstream

BSD arp (macOS) prints MACs with leading zeros trimmed (0:b:82), whereas Linux ip neigh zero-pads (00:0b:82); a robust regex matches both forms.

Stage 3 — Probe and confirm

Most appliances expose an HTTP configuration interface. A curl of the root page yields an HTTP status and often a <title> or model string, distinguishing, say, a Grandstream HT814 from a GXP desk phone — though Grandstream reveals the exact model only on the post-login Status page.

curl -s -m5 -o /dev/null -w "%{http_code}" "http://192.168.1.5/"

Vendor OUI reference

OUIs encountered in Astradial field work:

Vendor OUI(s) Typical device
Grandstream Networks 00:0B:82, C0:74:AD, EC:74:D7 HT8xx ATA, GXP/GRP phones, UCM PBX
Matrix Comsec Pvt Ltd 00:1B:09 EPABX / COSEC access control / SATATYA NVR
Hangzhou Hikvision / Prama Hikvision India 28:57:BE, bc:ad:28, e0:ca:3c, 24:b1:05, … CCTV cameras / NVR
Zhejiang Uniview 48:EA:63 CCTV cameras

To confirm or extend this table authoritatively:

curl -s https://standards-oui.ieee.org/oui/oui.csv | grep -i "grandstream"

Special case: direct device-to-laptop connection

When an appliance is cabled directly to a laptop (no router/DHCP between them), no DHCP server exists on the point-to-point link. macOS self-assigns a link-local 169.254.x.x (APIPA) address, but Grandstream HT-series adapters do not reliably do the same and may end up with no IP at all — leaving nothing to discover. Options:

  1. Re-cable through the site router, let the device obtain a DHCP lease, then run the OUI scan (preferred — fastest, no host changes).
  2. Run a DHCP server on the laptop via macOS Internet Sharing (System Settings → General → Sharing), which leases the device a 192.168.2.x address recorded in /var/db/dhcpd_leases.
  3. Use the device IVR: connect an analog handset to FXS port 1 and dial * * * then 02 to hear the IP spoken aloud.

Reference implementation: find-grandstream.sh

A self-contained script implementing the full procedure is maintained at AstradialDevelopment/Scripts/find-grandstream.sh.

./find-grandstream.sh                 # auto-detect subnet from default route
./find-grandstream.sh 192.168.1       # scan 192.168.1.0/24
./find-grandstream.sh 192.168.1 en0   # scan via a specific interface

It auto-detects the active interface and subnet (macOS and Linux), performs the gentle sweep, matches the three Grandstream OUIs, and prints each device's IP, MAC, HTTP status, and model/title. Because site routers reassign DHCP leases between visits, devices should be tracked by MAC, not IP — a unit's address may differ on each scan.

Operational notes

  • Sensitive sites. At hospitals and scan centres, restrict activity to the single-SYN sweep above; never run aggressive port scans against medical equipment.
  • Re-run for completeness. A device may miss the ARP window on a single pass; a second run catches stragglers. Persistent absence indicates a different subnet/VLAN or a powered-off unit, not a script fault.
  • Router cross-check. When a device cannot be found at L2, the site router's DHCP client list and reserved-IP table provide a second source — though statically configured devices may not appear there either.

See also

References