Vendor-OUI fingerprinting · mDNS/SSDP/WS-Discovery/ONVIF chatter · RTSP/RTMP streaming · traffic-rate/motion-correlation (the robust tell) · deauth-confirm

3.1 About this volume

This is the second of three detection-physics volumes (Vols 2–4) that underpin the rest of the series. Vol 2 established the RF and spectrum layer — what broadband power detectors measure and where the spectrum sweep lives. Vol 4 will close the arc by tackling the hardest case: cameras that emit nothing and must be found by optical, thermal, or NLJD means. This volume covers the Wi-Fi network layer: the full set of techniques for detecting an IP camera through its network presence rather than its RF signature alone.

The network-analysis arc is where the robust tell lives. OUI fingerprinting is a fast first pass but breaks badly under MAC randomization, generic chipsets, and white-label manufacturing. ONVIF/mDNS discovery chatter gives rich metadata when it works but is silenced by a single firewall rule. RTSP port probing confirms a stream is present but requires you to already be on the camera’s network. The technique that survives all of these failure modes — traffic-rate / motion-correlation — works because the physics of variable-bitrate video encoding makes a streaming camera’s uplink traffic envelope a passive sensor on the scene in front of its lens. Inducing motion and watching for a correlated uplink spike produces a confirm even when you have no MAC entry, no mDNS record, and no access to the camera’s management interface.

Chapter map:

§2 dissects OUI fingerprinting: what an OUI is, the IEEE database, real camera-vendor prefixes for Hikvision, Dahua, Wyze, Reolink, and Amcrest, the lookup flow, and why the technique breaks more often than camera-detection tutorials admit.
§3 walks the four discovery protocols an IP camera uses to announce itself — mDNS, SSDP, WS-Discovery, and ONVIF — at the message-level: what each frame contains, what address and port it uses, and how to listen for or provoke each.
§4 covers RTSP and RTMP as streaming-protocol artifacts: the RTSP DESCRIBE/SETUP/PLAY handshake, port 554 (and its variants), RTMP push at 1935, and how a network scan surfaces both.
§5 is the centerpiece: the traffic-rate / motion-correlation technique in full depth — VBR encoder theory, academic research lineage, what promiscuous-mode capture reveals without decryption, the test procedure, robustness analysis, and failure modes. This section is cited by Vols 5, 7, 8, 10, and 12; the anchor #5-traffic-rate-motion-correlation is stable.
§6 documents deauth-confirm — the consenting-environment-only confirmation technique that verifies a suspected device is a live Wi-Fi client by observing its disconnect-reconnect behavior after a management-frame injection.

Running theme — constraint #2 (restated here at the physics level):

Wi-Fi detection is fingerprint + behavior — not magic. OUI is fragile under MAC randomization, generic modules, and white-label cameras. Traffic-rate / motion-correlation is the robust tell. Off-network, hidden-SSID, and isolated-AP cameras may expose only an encrypted radio; the RSSI-walk technique in Vol 5 §5 handles that case.

All detection-range and reliability claims in this volume are spec-sourced pending bench verification.

3.2 Vendor-OUI fingerprinting

3.2.1 The IEEE OUI database

A MAC address (Media Access Control address) is a 48-bit identifier assigned to every Wi-Fi network interface at manufacture. Its structure is fixed:

  MAC address:  BC : AD : 28 : 7F : 4A : E1
                ├───────────┤   ├───────────┤
                    OUI         Device-specific
                (bits 0–23)       (bits 24–47)

The first 24 bits are the OUI — Organizationally Unique Identifier — assigned by the IEEE Registration Authority to the company that manufactured the chipset or end product. The IEEE maintains this database at standards-oui.ieee.org, updated multiple times daily, currently tracking over 30,000 registered 24-bit OUI blocks (MA-L), plus a smaller-allocation MA-M (28-bit) and MA-S (36-bit) tier.

Three assignment types appear in MAC lookups:

Table 1 — Three assignment types appear in MAC lookups

Type	Block size	Identifier bits	Common use
MA-L (OUI, /24)	16,777,216 MACs	24	High-volume manufacturers: camera vendors, chipmakers
MA-M (OUI-28, /28)	1,048,576 MACs	28	Mid-volume manufacturers
MA-S (OUI-36, /36)	4,096 MACs	36	Small manufacturers, niche products

Most camera vendors hold one or more MA-L assignments. A vendor with multiple product lines often holds multiple OUI blocks — Hikvision, for example, holds more than six registered MA-L assignments in the IEEE database.^[Current count verifiable at standards-oui.ieee.org by searching “Hangzhou Hikvision Digital Technology.” The number grows as product volume increases; any fixed count in this text should be treated as a lower bound.]

Practical lookup tools:

standards-oui.ieee.org — the authoritative source; searchable by OUI or company name; downloadable as oui.txt or oui.csv for embedding in tools.
maclookup.app — fast REST API and web UI; useful for ad-hoc lookups during a sweep.
macvendors.com — another API-accessible lookup with a free tier.
Local nmap database (nmap-mac-prefixes) — ships with nmap; updated in each release; suitable for offline use.

The IEEE OUI database is the foundation of vendor-OUI fingerprinting, but it maps OUI to manufacturer, not to device type. The camera-vendor classification layer — knowing which manufacturers make cameras — is a separate lookup table that must be built and maintained by the tool.

3.2.2 Camera-vendor OUI examples

The following table lists a representative sample of OUI prefixes registered to major camera vendors. It is not exhaustive — each vendor holds multiple OUI blocks, the database is updated continuously, and a new product line may use a new block. Always pull a fresh copy of the IEEE OUI database before a build or a sweep.

Table 2 — 2.2 Camera-vendor OUI examples

Vendor	Registered legal entity	Sample OUI prefixes	Notes
Hikvision	Hangzhou Hikvision Digital Technology Co.,Ltd.	`C0:56:E3` · `BC:AD:28` · `44:19:B6` · `54:8C:81` · `24:48:45` · `0C:75:D2`	Largest single-vendor camera OUI footprint in the IEEE database; 6+ MA-L blocks confirmed^[Verified against IEEE OUI database and maclookup.app/cleancss.com, June 2026.]
Dahua	Zhejiang Dahua Technology Co.,Ltd.	`90:02:A9` · `3C:EF:8C` · `E0:50:8B` · `38:AF:29` · `08:ED:ED` · `4C:11:BF`	Multiple confirmed MA-L blocks^[Confirmed via cleancss.com MAC lookups, June 2026.]; cameras shipping under 100+ OEM brand names may present Dahua OUIs
Wyze	Wyze Labs, Inc.	`2C:AA:8E`	Single registered block; many Wyze Cam models also use Espressif (`EC:FA:BC`) or MediaTek chipsets whose OUIs resolve to the chipmaker, not Wyze^[Spec-sourced pending IEEE OUI DB verification; cross-check against live IEEE lookup.]
Reolink	Reolink Innovation Limited	`EC:71:DB`	Single MA-L allocation (16.8M addresses)^[Confirmed via MAC vendor lookup cross-reference, June 2026.]; newer PoE models may present chipset OUIs
Amcrest	OEM from Dahua	shares Dahua OUIs	Amcrest is primarily a Dahua hardware OEM; firmware, chipsets, and OUIs are typically identical to Dahua products; some US-registered models may present separate Amcrest OUIs — verify against the IEEE DB

White-label note: Chinese camera manufacturers supply hardware to hundreds of Western brands (Swann, ZOSI, Montavue, LaView, Lorex budget tier, Night Owl, and many Amazon-sold brands). All of these may present the OUI of the underlying manufacturer (often Dahua or Hikvision), the chipset maker (Hi3516/Hi3518/HiSilicon is not separately OUI-registered but the PCB partner may be), or an entirely generic module OUI. No OUI list is complete for the white-label market.

3.2.3 OUI lookup flow

The OUI fingerprinting pipeline from captured MAC address to detection flag:

┌─────────────────────────────────────────────────────────────────────────┐
│                     OUI FINGERPRINTING PIPELINE                          │
└─────────────────────────────────────────────────────────────────────────┘

  Wi-Fi network            Promiscuous-mode capture, ARP table,
  client activity ──────►  DHCP lease, beacon, or probe-response frame
                                         │
                                         ▼
                              Extract 6-byte MAC address
                                  e.g.  BC:AD:28:7F:4A:E1
                                         │
                                         ▼ Take first 3 bytes (24 bits)
                              OUI = BC:AD:28
                                         │
                                         ▼
                    ┌────────────────────────────────────────┐
                    │     Camera-vendor OUI lookup table      │
                    │  (IEEE OUI DB filtered to cam vendors)  │
                    ├──────────────────┬─────────────────────┤
                    │  MATCH FOUND     │  NO MATCH           │
                    │  BC:AD:28        │  2C:AA:8E → Wyze    │
                    │  → Hikvision     │  (Wyze is in list)  │
                    │  → CAMERA LIKELY │  EC:FA:BC → Espressif│
                    └────────┬─────────┴──────────┬──────────┘
                             │                     │
                             ▼                     ▼
                     FLAG for further        GENERIC MODULE:
                     investigation:          might be a camera,
                     ONVIF probe,            might be anything.
                     RTSP test,              Deeper inspection
                     traffic-rate watch      required. See §5.
                             │
                             ▼
                    Discovery (§3) → RTSP probe (§4) → Traffic-rate (§5)
                    Any single layer's failure is not a clear.

The key insight in this diagram: a camera-vendor OUI match is not a detection — it is a flag that moves the suspect client further down the investigation pipeline. An OUI mismatch is not a clear — it means the client did not immediately identify itself by brand. Both paths require the deeper techniques in §3–§5.

3.2.4 Fragility: where OUI fingerprinting breaks

OUI fingerprinting is a useful first pass but an unreliable sole method. Three independent failure modes can produce a legitimate IP camera that shows no camera-vendor OUI match, and one more can produce false positives.

Failure mode 1 — MAC address randomization. IEEE 802.11-2020 standardized a locally administered MAC (LAA) bit (bit 1 of the first octet, xx:xx:xx:xx:xx:xx where bit pattern xxxxxx10 in the first octet indicates LAA). Modern Android, iOS, and Windows devices randomize their MAC per-SSID to limit cross-network tracking. Most IP cameras — particularly purpose-built models from Hikvision, Dahua, Reolink — do not randomize their MAC once associated with a network; the OUI remains stable across reboots. However, generic ESP32-based cameras (popular in DIY and grey-market products) inherit the ESP32 SDK’s behavior, which can include per-boot or per-association randomization in some firmware configurations. Distinguish a randomized MAC by checking the LAA bit:

Table 3 — Failure mode 1 — MAC address randomization. IEEE 802.11-2020 standardized a locally administered MAC (LAA) bit (bit 1 of the first octet, xx:xx:xx:xx:xx:xx where bit pattern xxxxxx10 in the first octet indicates LAA). Modern Android, iOS, and Windows devices randomize their MAC per-SSID to limit cross-network tracking. Most IP cameras — particularly purpose-built models from Hikvision, Dahua, Reolink — do not randomize their MAC once associated with a network; the OUI remains stable across reboots. However, generic ESP32-based cameras (popular in DIY and grey-market products) inherit the ESP32 SDK's behavior, which can include per-boot or per-association randomization in some firmware configurations. Distinguish a randomized MAC by checking the LAA bit

First-octet binary (low 2 bits)	Meaning
`...x0` (bit 0 = 0)	Unicast (normal)
`...1x` (bit 1 = 1, LAA bit set)	Locally administered — OUI is not an IEEE assignment

A MAC like 02:xx:xx:xx:xx:xx or 12:xx:xx:xx:xx:xx with the LAA bit set cannot be matched against any OUI database entry. The OUI is meaningless; traffic-rate correlation (§5) becomes the only Wi-Fi-layer detection path.

Failure mode 2 — generic Wi-Fi module OUI. A large fraction of budget IP cameras use off-the-shelf Wi-Fi chipsets whose OUI resolves to the chip vendor, not the camera manufacturer:

Table 4 — Failure mode 2 — generic Wi-Fi module OUI. A large fraction of budget IP cameras use off-the-shelf Wi-Fi chipsets whose OUI resolves to the chip vendor, not the camera manufacturer

Chip / module OUI	Vendor	What it might indicate
`EC:FA:BC`, `A4:CF:12`, `84:F7:03`	Espressif Systems (ESP8266/ESP32)	Any ESP-based device: cameras, locks, sensors, lightbulbs
`00:90:4C`, `C4:5B:BE`, `28:2C:02`	Realtec / Realtek	Any Realtek Wi-Fi chip product
`9C:65:F9`, `4C:00:00`	MediaTek (via Ralink)	Any MTK-based router, camera, or IoT device
`74:DA:38`, `00:E0:4C`	Edimax Technology	IoT modules, cameras, access points

Any of these OUIs demands that you proceed immediately to discovery (§3) and traffic-rate (§5) — the OUI layer has told you nothing definitive about device type.

Failure mode 3 — white-label and grey-market cameras. The Chinese camera manufacturing ecosystem produces hardware under hundreds of brand names from a small number of underlying manufacturers. A “SOLIOM” or “Rraycom” camera bought on Amazon is frequently a Dahua or Hi3516-platform device with a different logo silk-screened on the enclosure. If the reseller registered their own OUI block (some do; many do not), the Dahua OUI will not match. If they used the underlying Dahua OUI, the brand will not resolve to the visible label. Either way, the OUI lookup gives ambiguous or misleading output.

False positive — legitimate IoT devices. A Hikvision NVR on the same network as a Hikvision IP camera will present a Hikvision OUI. A Hikvision network switch — yes, they make them — also presents a Hikvision OUI. The OUI match flags a client as “Hikvision device,” not “Hikvision camera.” ONVIF probing (§3) or RTSP access (§4) is required to confirm the device type.

Callout — OUI fragility under MAC randomization: In any environment where you do not control the devices (the typical sweep scenario — you’re a guest), you must assume the camera may not present a camera-vendor OUI. OUI matching is a fast pre-filter; it is not a method by itself. Any sweep protocol that stops at OUI and declares “nothing found” has not ruled out a camera with a generic, randomized, or white-label MAC. Traffic-rate / motion-correlation (§5) is the technique that survives all three fragility modes.

3.3 Discovery chatter: mDNS, SSDP, WS-Discovery, ONVIF

An IP camera, once it joins a network, announces itself in several ways before a single human looks at a frame. These announcements — collectively “discovery chatter” — are the involuntary side-channel through which a camera can be identified and enumerated. Four protocols carry this chatter: mDNS/Bonjour (service records), SSDP/UPnP (device description), WS-Discovery (the ONVIF discovery mechanism), and the ONVIF device-information API itself. Each has a distinct wire format, multicast group, and port.

Discovery protocol reference table:

Table 5 — Discovery protocol reference table:

Protocol	Transport	Multicast / Unicast	Port	What the camera sends	Tool to probe it
mDNS / Bonjour	UDP	224.0.0.251 (IPv4) / ff02::fb (IPv6)	5353	PTR/SRV/TXT records for `_rtsp._tcp`, `_onvif._tcp`, `_http._tcp` service types; includes hostname, IP, port, and TXT metadata	`avahi-browse`, `dns-sd`
SSDP / UPnP	UDP	239.255.255.250	1900	NOTIFY and M-SEARCH responses; UPnP device description URL (points to an XML descriptor)	`nmap -sU -p 1900`, `curl` of the descriptor URL
WS-Discovery	UDP	239.255.255.250	3702	`Hello` frame on join; `ProbeMatch` response to client Probe; carries XAddrs (ONVIF service URL) and Types	`onvif-probe`, Python socket, `wsdd`
ONVIF GetDeviceInformation	TCP (HTTP/SOAP)	unicast	80 or 8899	Manufacturer, model, firmware, serial number, hardware ID	`onvif-util`, `curl` SOAP POST

3.3.1 mDNS and Bonjour

Multicast DNS (mDNS, RFC 6762) allows devices to resolve hostnames and discover services on a link-local network without a dedicated DNS server. DNS Service Discovery (DNS-SD, RFC 6763) defines the service-type naming convention that rides over mDNS. Apple branded their implementation “Bonjour”; it is the same protocol.

How it works on the wire:

The camera joins the network and sends an mDNS announcement (Multicast DNS announcement or PTR record) to 224.0.0.251:5353 declaring that service instance "HikIPCamera-7F4AE1._rtsp._tcp.local" is available on its IP at port 554.
Any client on the same L2 segment can send a PTR query for _rtsp._tcp.local to 224.0.0.251:5353; the camera responds with its PTR, SRV (hostname + port), and A (IPv4 address) records.
The TXT record may carry additional metadata — path components for the RTSP URL, vendor identifiers, or stream capabilities.

Camera-relevant mDNS service types:

Table 6 — Camera-relevant mDNS service types:

Service type	Meaning	Cameras that use it
`_rtsp._tcp`	RTSP streaming endpoint	Reolink, Amcrest, many Hikvision / Dahua variants
`_onvif._tcp`	ONVIF device management	Some Hikvision / Dahua network cameras
`_http._tcp`	HTTP (web UI)	Most cameras with a browser interface
`_airplay._tcp`	Apple AirPlay	Smart TV cameras, not typically IP cams
`_nvstream._tcp`	NVIDIA VideoLAN-class streaming	Rare in camera context

# Discover all mDNS services on the current L2 network and filter for camera-relevant types
avahi-browse -at 2>/dev/null | grep -iE '(rtsp|onvif|camera|ipcam|hikvision|dahua|wyze|reolink)'

# Watch for new RTSP service announcements in real time (Ctrl-C to stop)
avahi-browse -r _rtsp._tcp 2>/dev/null

# One-shot: resolve all RTSP service instances and show IP + port
avahi-browse -rpt _rtsp._tcp 2>/dev/null | \
    awk -F';' '/^=/{printf "%-40s  %s:%s\n",$4,$8,$9}'

# macOS alternative (dns-sd / Bonjour):
dns-sd -B _rtsp._tcp .      # browse — streams instances as they appear/disappear
dns-sd -B _onvif._tcp .     # browse ONVIF service instances

What to expect: A typical Reolink camera on a home network announces _rtsp._tcp with a TXT record pointing to its stream path. A Hikvision NVR with cameras attached announces its own _rtsp._tcp and may additionally announce _http._tcp for the web UI. No response at all means the camera either does not implement mDNS (common on cameras configured for cloud-only mode or on firmware revisions that suppress it) or sits on a different L2 segment.

3.3.2 SSDP and UPnP

Simple Service Discovery Protocol (SSDP) is the discovery transport for UPnP (Universal Plug and Play). It operates over UDP to the multicast group 239.255.255.250:1900. Cameras and NVRs that implement UPnP use SSDP in two modes:

Passive (NOTIFY): The camera spontaneously multicasts ssdp:alive NOTIFY frames when it joins the network and at a regular interval (typically every 30–1800 seconds). These frames contain the UPnP device type URN and a location URL pointing to the XML device descriptor.
Active (M-SEARCH): A client sends an M-SEARCH * HTTP/1.1 to 239.255.255.250:1900 with a search target (ST) header. Devices matching the ST respond via unicast with their LOCATION URL.

Wire format of an M-SEARCH probe:

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 3
ST: ssdp:all

(Blank line terminates the request. Sent as a single UDP datagram to 239.255.255.250:1900.)

Key ST values for camera hunting:

Table 7 — Key ST values for camera hunting:

ST value	Matches
`ssdp:all`	All UPnP devices (broad sweep)
`urn:schemas-upnp-org:device:Basic:1`	Basic UPnP device (catch-all)
`urn:schemas-upnp-org:device:MediaServer:1`	UPnP media servers (NVRs sometimes appear here)
`urn:dial-multiscreen-org:service:dial:1`	DIAL-capable devices (some smart-cam platforms)

A camera responding to M-SEARCH returns its LOCATION URL; a curl or wget to that URL retrieves the UPnP XML descriptor which typically contains manufacturer, model name, and sometimes firmware version.

SSDP limits: Many IP cameras implement UPnP port-mapping for NAT traversal (camera punches a hole in the router so the vendor’s cloud can reach it) but do not implement the device discovery side. Conversely, some cameras announce SSDP but immediately suppress it when locked down by the host. SSDP traffic does not cross L3 router boundaries without explicit multicast forwarding — cameras on a separate VLAN will not respond.

3.3.3 WS-Discovery

Web Services Dynamic Discovery (WS-Discovery, WS-DD) is the OASIS-standardized multicast discovery protocol adopted by ONVIF as its primary device-discovery mechanism. It uses the same multicast address as SSDP (239.255.255.250) but a different port (3702/UDP).^[WS-Discovery specification: OASIS WS-DD Version 1.1, 2009. ONVIF Profile S mandates WS-Discovery compliance for devices claiming Profile S conformance.]

WS-Discovery operates on two message types:

Hello / Bye: Devices send an unsolicited Hello message to the multicast group when they join the network, and Bye when they leave. The Hello contains the device’s endpoint reference (UUID-based URN), supported Types (e.g., dn:NetworkVideoTransmitter), Scopes (structured metadata), and XAddrs (the HTTP URL for the ONVIF device service).
Probe / ProbeMatch: A client sends a Probe to the multicast group specifying a Types filter. All matching devices respond with a ProbeMatch containing the same fields as Hello. This is the active-discovery mechanism.

Wire format: the WS-Discovery Probe (UDP, sent to 239.255.255.250:3702):

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
    xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
    xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"
    xmlns:dn="http://www.onvif.org/ver10/network/wsdl">
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe
    </a:Action>
    <a:MessageID>uuid:11111111-1111-1111-1111-111111111111</a:MessageID>
    <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
  </s:Header>
  <s:Body>
    <d:Probe>
      <d:Types>dn:NetworkVideoTransmitter</d:Types>
    </d:Probe>
  </s:Body>
</s:Envelope>

A camera responding with a ProbeMatch identifies itself as an dn:NetworkVideoTransmitter — the ONVIF type for a device capable of streaming video. The XAddrs field in the response contains the URL for the ONVIF device service (typically http://<camera-ip>/onvif/device_service or similar).

Python implementation — active WS-Discovery probe:

import socket, uuid

MULTICAST_ADDR = "239.255.255.250"
MULTICAST_PORT = 3702

PROBE = f"""<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
            xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
            xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"
            xmlns:dn="http://www.onvif.org/ver10/network/wsdl">
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe
    </a:Action>
    <a:MessageID>uuid:{uuid.uuid4()}</a:MessageID>
    <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
  </s:Header>
  <s:Body>
    <d:Probe>
      <d:Types>dn:NetworkVideoTransmitter</d:Types>
    </d:Probe>
  </s:Body>
</s:Envelope>"""

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 2)
sock.settimeout(5)
sock.sendto(PROBE.encode(), (MULTICAST_ADDR, MULTICAST_PORT))

print(f"WS-Discovery Probe sent to {MULTICAST_ADDR}:{MULTICAST_PORT}")
while True:
    try:
        data, addr = sock.recvfrom(65535)
        print(f"\n--- ProbeMatch from {addr[0]} ---")
        # Extract XAddrs (ONVIF device service URL) from the SOAP response
        import re
        xaddrs = re.findall(r'<[^>]*XAddr[^>]*>([^<]+)<', data.decode('utf-8', errors='replace'))
        types  = re.findall(r'<[^>]*Types[^>]*>([^<]+)<',  data.decode('utf-8', errors='replace'))
        print(f"  XAddrs : {xaddrs}")
        print(f"  Types  : {types}")
    except socket.timeout:
        break
sock.close()

3.3.4 ONVIF Profile S discovery

Once a WS-Discovery ProbeMatch returns an XAddrs URL (or you already know the camera’s IP and the standard port), the ONVIF device-information API provides manufacturer-confirmed identity:

ONVIF GetDeviceInformation — HTTP POST to http://<ip>/onvif/device_service (port 80 or 8899, depending on camera configuration):

POST /onvif/device_service HTTP/1.1
Host: <camera-ip>:8899
Content-Type: application/soap+xml; charset=utf-8
Content-Length: <length>

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
            xmlns:tds="http://www.onvif.org/ver10/device/wsdl">
  <s:Body>
    <tds:GetDeviceInformation/>
  </s:Body>
</s:Envelope>

A conformant camera responds with:

Table 8 — A conformant camera responds with

Field	Example value	Detection significance
Manufacturer	`Hikvision`	Confirmed vendor identity — no OUI inference required
Model	`DS-2CD2143G2-I`	Specific model enables vulnerability cross-reference
FirmwareVersion	`V5.7.5 build 221208`	Firmware cross-reference for CVEs
SerialNumber	(unique per unit)	Asset tracking; useful in a sweep report
HardwareId	(chipset or PCB revision)	Chipset identification

ONVIF also specifies GetCapabilities and GetStreamUri, which return the list of ONVIF profiles supported and the RTSP URL for each stream. This is the authoritative way to retrieve the RTSP path for any ONVIF-conformant camera without guessing URL conventions.

ONVIF port conventions (common, not universal):

Table 9 — ONVIF port conventions (common, not universal):

Port	Protocol	Commonly used by
80	HTTP/SOAP	Hikvision NVRs, many Dahua cameras
8899	HTTP/SOAP	Hikvision IP cameras (device service)
8080	HTTP	Amcrest and some Dahua web UIs
80 or 443	HTTPS	Secure ONVIF implementations

ONVIF does not standardize the port; the XAddrs URL returned in the WS-Discovery ProbeMatch is the authoritative service endpoint.

3.3.5 What defeats discovery

Discovery chatter operates at the application layer and is trivially suppressed by configuration. A camera with tightened firmware settings produces no mDNS, SSDP, or WS-Discovery output and responds to none of the probes above. Specific defeat mechanisms:

Table 10 — Discovery chatter operates at the application layer and is trivially suppressed by configuration. A camera with tightened firmware settings produces no mDNS, SSDP, or WS-Discovery output and responds to none of the probes above. Specific defeat mechanisms

Discovery protocol	How it is suppressed	Result from sweep
mDNS / Bonjour	mDNS disabled in camera settings (common in “enterprise” firmware)	`avahi-browse` returns nothing from that device
SSDP / UPnP	UPnP disabled in camera or router settings	No NOTIFY frames; M-SEARCH returns no response from camera
WS-Discovery	WS-Discovery disabled (less common but possible); VLAN isolation	No Hello on join; Probe returns no match
ONVIF API	Authentication required (no anonymous GetDeviceInformation); port not 80/8899	Probe returns 401 or connection refused
All chatter	Camera on a different L2 segment / VLAN (mDNS and SSDP don’t cross L3)	Invisible to all discovery protocols from guest network

The critical insight: any camera that has been deliberately hidden is unlikely to leave mDNS/ONVIF chatter enabled. A paranoid host will disable all discovery protocols on the camera and put it on a separate VLAN or a second router not visible to the guest Wi-Fi. In those configurations, §2 and §3 produce nothing — and that is precisely why §5 (traffic-rate / motion-correlation) matters. The traffic envelope exists whether or not the camera announces itself.

[FIGURE SLOT — Vol 3, § 3.3] Wireshark capture of a WS-Discovery Probe and ProbeMatch exchange on the local network, showing the SOAP XML in the packet detail pane with the dn:NetworkVideoTransmitter Types field and the camera’s XAddrs URL highlighted. Source: Photo Helper search “Wireshark ONVIF WS-Discovery ProbeMatch packet capture” — or a screenshot from a controlled test environment. Caption when filled: “Figure 3.1 — Wireshark packet detail showing an ONVIF WS-Discovery ProbeMatch from a Hikvision camera. The XAddrs field carries the ONVIF device-service URL used for subsequent GetDeviceInformation and GetStreamUri queries. Photo: File:Name.jpg by . .“

3.4 RTSP / RTMP

3.4.1 RTSP on the wire

Real-Time Streaming Protocol (RTSP, RFC 7826) is the control protocol for video streams from IP cameras. It is not itself a streaming protocol — it does not carry video data — but it negotiates the parameters of the stream and controls play, pause, and teardown. The video data flows over RTP/RTCP (typically on adjacent ephemeral UDP ports, or interleaved over the same TCP connection in TCP mode).

RTSP session establishment follows a strict four-method sequence:

CLIENT                                         CAMERA
   │                                               │
   │  DESCRIBE rtsp://<ip>/stream1 RTSP/1.0        │
   │  CSeq: 1                                      │
   │  Accept: application/sdp                      │
   ├──────────────────────────────────────────────►│
   │                                               │
   │  RTSP/1.0 200 OK                              │
   │  CSeq: 1                                      │
   │  Content-Type: application/sdp                │
   │  [SDP body: codec, clock rate, payload type]  │
   │◄──────────────────────────────────────────────┤
   │                                               │
   │  SETUP rtsp://<ip>/stream1/track1 RTSP/1.0    │
   │  CSeq: 2                                      │
   │  Transport: RTP/AVP;unicast;client_port=49152-49153│
   ├──────────────────────────────────────────────►│
   │                                               │
   │  RTSP/1.0 200 OK   [assigns server_port]      │
   │◄──────────────────────────────────────────────┤
   │                                               │
   │  PLAY rtsp://<ip>/stream1 RTSP/1.0            │
   │  CSeq: 3                                      │
   │  Range: npt=0.000-                            │
   ├──────────────────────────────────────────────►│
   │                                               │
   │  RTSP/1.0 200 OK  [RTP stream begins]         │
   │◄──────────────────────────────────────────────┤
   │                                               │
   │  ≡≡≡≡≡≡≡ RTP video/audio data ≡≡≡≡≡≡≡≡≡≡≡≡≡   │

RTSP URL conventions vary by vendor. Common patterns:

Table 11 — RTSP URL conventions vary by vendor. Common patterns

Vendor	Main stream URL pattern	Sub-stream URL pattern
Hikvision	`rtsp://<ip>/Streaming/Channels/101`	`rtsp://<ip>/Streaming/Channels/102`
Dahua	`rtsp://<ip>/cam/realmonitor?channel=1&subtype=0`	`?subtype=1`
Reolink	`rtsp://<ip>//h264Preview_01_main`	`//h264Preview_01_sub`
Wyze	`rtsp://<ip>/live` (after enabling RTSP in-app)	N/A (single stream)
Generic ONVIF	Returned by GetStreamUri; often `/onvif/stream1` or `/live`

Most cameras require HTTP-digest or basic authentication on the RTSP URL: rtsp://user:password@<ip>/.... When authentication is disabled (a common factory default on budget cameras), the stream is accessible anonymously — which is both a security problem and a sweep opportunity.

RTSP port conventions:

Table 12 — RTSP port conventions:

Port	Usage
554	IANA-assigned RTSP standard port; default for almost all cameras
8554	Alternate; common on cameras where 554 is mapped via UPnP to a high port externally
1024–65535 (high)	Sometimes used for RTSP interleaved over HTTP (RTSP-over-HTTP, RFC 2326 §10.12)

3.4.2 RTMP and cloud relay

Real-Time Messaging Protocol (RTMP) is Adobe’s proprietary streaming protocol, originally designed for Flash video delivery, now widely used by cameras to push video to cloud servers, CDN ingest points, and vendor relay infrastructure. Port 1935 is the standard; RTMPS (TLS-wrapped) runs on 443.

The camera-to-cloud RTMP flow:

Camera (RTMP publisher)          Vendor cloud relay / CDN ingest
        │                                        │
        │  RTMP connect (port 1935)              │
        ├───────────────────────────────────────►│
        │                                        │
        │  publish "live/camera-UID-xxx"          │
        ├───────────────────────────────────────►│
        │                                        │
        │  ═══ H.264/AAC FLV video tags ═════   │
        ├──────────────────────────────────────►│
                                                 │
                                 Cloud viewer pulls HLS/DASH from CDN

From a detection standpoint, RTMP is most visible as sustained outbound TCP traffic to port 1935 at external IP addresses (the vendor’s CDN). In a sweep context this means: if you can see the camera’s traffic (i.e., you’re on the same L2), you see TCP connections to port 1935 external — the motion-correlation technique in §5 applies just as well to the RTMP bitrate envelope as to RTSP RTP. Fully P2P relay architectures (Wyze Peer-to-Peer, Hikvision CloudP2P, Reolink Go Plus) use proprietary UDP tunneling on high ports rather than standard RTMP, but the bitrate-motion correlation still holds.

3.4.3 Surfacing RTSP cameras on the network

Once you know the IP range of the network under inspection, an RTSP port scan confirms whether any discovered clients are running streaming services:

# nmap: scan the /24 for RTSP (port 554) and ONVIF-common ports
# -sV for service version detection; -p for targeted ports
nmap -sV -p 554,8554,8080,8899,80 192.168.1.0/24 --open 2>/dev/null | \
    grep -E '(Nmap scan|554|8554|rtsp|onvif|open)'

# tshark: capture RTSP traffic and show method + URL
# Run on the monitoring interface (wlan0mon in monitor mode, or eth0)
tshark -i wlan0mon -f "tcp port 554" \
    -Y "rtsp" \
    -T fields -e ip.src -e ip.dst -e rtsp.method -e rtsp.url \
    -l 2>/dev/null

# tshark: watch for any RTSP DESCRIBE request — confirms a client pulling a stream
tshark -i wlan0 -Y "rtsp.method == \"DESCRIBE\"" -T fields \
    -e frame.time_relative -e ip.src -e ip.dst -e rtsp.url -l 2>/dev/null

# curl: attempt an anonymous RTSP DESCRIBE to a suspected camera IP
curl -s --max-time 5 "rtsp://192.168.1.XX:554/" \
    --request DESCRIBE --header "CSeq: 1" \
    --header "Accept: application/sdp"
# HTTP 200 + SDP body confirms an open RTSP server.
# HTTP 401 confirms RTSP exists but requires authentication.
# Connection refused or timeout = port closed or filtered.

Port and protocol reference — Wi-Fi IP camera full table:

Table 13 — Port and protocol reference — Wi-Fi IP camera full table:

Port	Protocol	Transport	Purpose	Coverage
554	RTSP	TCP	Video stream control	Near-universal (ONVIF Profile S mandates it)
8554	RTSP (alternate)	TCP	Same; used when 554 conflicts with NAT mapping	Hikvision, Dahua variants
1935	RTMP	TCP	Push video to cloud relay / CDN ingest	Cloud-enabled cameras (Wyze, Reolink Go, Tapo)
443	RTMPS / HTTPS	TCP	Encrypted RTMP push; vendor HTTPS API	Hardened cloud cameras
3702	WS-Discovery	UDP	ONVIF device discovery (§3.3)	All ONVIF Profile S cameras
5353	mDNS	UDP	Service announcement (§3.1)	Reolink, Amcrest, some Wyze/Hikvision
1900	SSDP	UDP	UPnP device advertisement (§3.2)	NVRs, UPnP-enabled cameras
80	HTTP / SOAP	TCP	Web UI; ONVIF device service (§3.4)	Most cameras with a web interface
8899	HTTP / SOAP	TCP	Hikvision ONVIF device service	Hikvision IP cameras
8080	HTTP	TCP	Alternate web UI port	Amcrest, some Dahua, many generic
443	HTTPS	TCP	Encrypted web UI	Enterprise / hardened cameras

3.5 Traffic-rate / motion-correlation

This is the centerpiece technique of Vol 3 — and of the entire Wi-Fi detection arc. OUI fingerprinting (§2) and discovery chatter (§3) are useful pre-filters but brittle in deployment. RTSP probing (§4) requires network access and risks alerting the camera. Traffic-rate / motion-correlation works from a passive, promiscuous-mode position; does not require decryption; does not require the camera to be on your network; does not require a camera-vendor OUI match; and produces a behavioral confirm that is independent of all the fingerprinting-layer failure modes. It is the reason a Wi-Fi IP camera is fundamentally detectable in a way that a well-configured wired or SD-only camera is not.

Callout — traffic-rate / motion-correlation is the robust tell: A streaming camera’s uplink bitrate tracks the motion in front of its lens. This is a consequence of how variable-bitrate (VBR) video compression works, not a quirk of any particular vendor’s implementation. The effect is visible in encrypted Wi-Fi traffic without decryption, because frame sizes and inter-frame intervals in the air-interface stream reflect the encoded bitrate. Induce motion in front of a suspected camera; watch for a correlated uplink-bitrate spike from the suspected client. This technique works regardless of whether the camera has a camera-vendor OUI, regardless of whether it responds to ONVIF probes, and regardless of whether you can access its RTSP stream.

3.5.1 The VBR encoder as an accidental sensor

Modern IP cameras compress video with H.264 (AVC) or H.265 (HEVC) using variable bitrate (VBR) encoding. In VBR mode, the encoder allocates bits proportional to the complexity of each frame — the fundamental trade-off that makes VBR more efficient than constant bitrate (CBR) for storage and bandwidth. Understanding this at the codec level reveals why the uplink traffic becomes a passive motion sensor.

H.264/H.265 frame types:

Table 14 — H.264/H.265 frame types:

Frame type	Contains	Typical size	Scene condition
I-frame (keyframe)	Complete frame; all blocks encoded independently	10–50× larger than P-frame	Forced at GOP interval or on scene change
P-frame (predicted)	Only the difference from the previous reference frame	Small if scene is static	Continuous compression: most frames
B-frame (bidirectional)	Interpolated between two reference frames	Varies; intermediate	Used in some profiles for higher compression

The motion-to-bitrate chain:

Scene in front of lens
        │
        │  (more moving objects = more pixels changing per frame)
        ▼
  Camera sensor captures each frame
        │
        ▼
  H.264/H.265 encoder computes residuals
  (difference between current frame and prediction)
        │
        │  Static scene → tiny residuals → few bits needed per macroblock
        │  Motion → large residuals → more bits per macroblock
        ▼
  VBR rate controller adjusts QP (quantization parameter)
  to hit a target quality metric, not a target bitrate
        │
        ▼
  Output bitrate ∝ scene complexity
  (motion → complex → high bitrate; static → simple → low bitrate)
        │
        ▼
  Encoded NAL units → RTP packetization → TCP/UDP transport
        │
        ▼
  Uplink Wi-Fi traffic rate ∝ encoder output ∝ scene complexity

The chain is direct and physics-governed: if the scene is moving, the encoder must spend more bits, and those bits appear as larger and more frequent packets on the uplink. The encryption layers — DTLS-SRTP for RTP, TLS for RTMPS, WPA2/WPA3 at the Wi-Fi layer — encrypt the payload but cannot hide the existence and size of the packets. From a passive observer in promiscuous mode, the encrypted frame stream reveals the uplink bitrate envelope, which reveals the scene motion level.

CBR mode caveat: Some cameras are configurable for CBR output, which pads or drops frames to maintain a constant bitrate. CBR mode partially defeats the motion-correlation technique — a CBR stream at a constant 2 Mbps uplink looks the same whether the scene is static or busy, because the encoder is hitting a fixed-rate target rather than letting complexity drive the bitrate. Most consumer-grade cameras default to VBR; CBR is more common in enterprise NVR installations where network bandwidth budgets are fixed. If motion-correlation produces no spike on an otherwise suspected client, check whether the camera is in CBR mode.

3.5.2 Academic lineage

The observation that network traffic flow characteristics reveal information about encrypted video content has a multi-decade lineage in the traffic-analysis and network security literature.

Foundational work — encrypted traffic fingerprinting: The broader field of using packet sizes and inter-packet timing to infer information about encrypted traffic (keystrokes, web pages, video resolutions) was established in work on SSL/TLS traffic fingerprinting in the 2000s and accelerated in the 2010s. The specific application to encrypted video streams — inferring quality level, resolution, and scene content from bitrate variation — is well-documented: Dubin et al.^[Dubin, R., Shallat, J., Dvir, A., “I know what you streamed last summer: a fingerprinting attack on Netflix, YouTube, and Amazon Prime Video,” arXiv:1703.05882, 2017.] demonstrated scene inference from encrypted Netflix streams using only packet timing and size; subsequent work extended this to encrypted RTSP streams.

Motion-correlation in the camera-detection context: The research line that directly exploits the VBR-motion coupling to detect and locate hidden Wi-Fi cameras includes:

LocCams (Wang et al., ACM IMWUT 2023)^[Wang, Z. et al., “LocCams: Detecting and Localizing Hidden Cameras with Smartphones via Wi-Fi Signals,” Proc. ACM Interact. Mob. Wearable Ubiquitous Technol. (IMWUT), 2023. Spec-sourced; bench-verify paper claims against the specific lab conditions described.]: Uses a combination of Wi-Fi traffic-rate observation and RSSI fingerprinting to both detect hidden cameras and estimate their physical location from a single scanning device. Demonstrates that the uplink bitrate variation induced by motion in front of the camera provides enough statistical signal for detection. Works on transmitting cameras only — explicitly not applicable to SD-only or wired cameras.
CamLoPA (“Camera Localization via Passive Wi-Fi”)^[IEEE S&P 2025 (arXiv 2409.15169). Web-verified.]: Takes a purely passive approach — no active probes sent; only the ambient Wi-Fi traffic from the camera is observed. Demonstrates that passively sniffed uplink traffic rate from a streaming camera correlates with controlled motion events introduced in front of the lens, achieving detection and coarse localization without joining the network or sending any probe frames.
SpyDir^[arXiv 2602.00411 (2026 preprint). Web-verified.]: Another approach in the same research lineage, using directional antenna motion and RSSI correlation alongside traffic analysis. Transmitting cameras only.
The Cheng et al. “Your Wi-Fi Is Watching You” lineage^[Referenced in the academic camera-detection literature; specific full citation pending bench-verification.]: Describes the general principle of using Wi-Fi traffic observation to infer surveillance camera behavior and location.

Important scope flag for all of the above: Every paper in this lineage is explicitly scoped to transmitting cameras — cameras that are actively streaming video over Wi-Fi. SD-only cameras (no uplink traffic) and wired cameras (no Wi-Fi radio) are completely outside the scope of these techniques. The technique is powerful precisely because it does not require decryption or network access; it is limited precisely because it requires an active Wi-Fi radio and an active uplink stream.

3.5.3 What you see in promiscuous mode

In promiscuous 802.11 monitor mode, your adapter receives all frames on the current channel regardless of destination. For a Wi-Fi camera streaming in the background, the following are visible without decryption:

Table 15 — In promiscuous 802.11 monitor mode, your adapter receives all frames on the current channel regardless of destination. For a Wi-Fi camera streaming in the background, the following are visible without decryption

Observable	Visible without decrypt?	What it tells you
Transmitter MAC address (`wlan.sa`)	Yes	Identifies the client; correlates across time
Frame length (`frame.len`)	Yes	Payload size; proportional to encoded video payload
Frame timing (inter-frame interval)	Yes	Together with frame size → instantaneous bitrate estimate
BSSID (AP the client is associated with)	Yes	Establishes the network context
Traffic direction (uplink vs downlink)	Yes, via BSSID/receiver MAC analysis	Uplink frames (from client to AP) carry the camera’s encoded video
Payload content (video data)	No (WPA2/WPA3 encrypted)	Cannot decrypt without the PSK
RTSP session parameters, ONVIF data	No (TLS-encrypted in most deployments)	Cannot read headers

Uplink vs downlink disambiguation: In infrastructure mode (camera associated to an AP), the wlan.fc.tods and wlan.fc.fromds bits in the 802.11 frame control field identify direction:

ToDS=1, FromDS=0 — client-to-AP (uplink, the camera sending video)
ToDS=0, FromDS=1 — AP-to-client (downlink, the camera receiving commands or cloud ACKs)

Filter for wlan.fc.tods == 1 && wlan.sa == [suspected-MAC] to isolate the camera’s uplink stream.

What the bitrate envelope looks like:

A streaming camera at a typical 1–4 Mbps VBR main stream produces, from a promiscuous observer’s perspective:

Static scene: regular, small frames at a low rate — the P-frames carrying tiny residuals. Measured aggregate uplink: roughly proportional to the stream’s CBR floor or VBR minimum, typically 100–500 Kbps for a 1080p main stream on a static scene.
Motion event: burst of large frames — I-frames forced by scene change detection plus high-residual P-frames. The measured aggregate uplink spikes 3–10× above the static baseline within 1–3 seconds of the motion starting and returns to baseline 2–8 seconds after the motion stops (latency depends on GOP size, encoder latency, and network buffering).
Sub-streams: many cameras maintain a low-bitrate sub-stream (CIF or 360p at 256–512 Kbps) for mobile viewing alongside the main stream. This doubles the uplink traffic but also doubles the correlation signal.

3.5.4 The test procedure: induce motion, watch the flow

The motion-correlation test is conceptually simple: create a controlled motion event in front of a suspected camera placement and observe whether any Wi-Fi client on the current channel exhibits a correlated uplink-bitrate spike.

Prerequisites:

Wi-Fi adapter in monitor mode on the same channel as the suspected camera’s AP (or sweeping channels with channel dwell time long enough to catch a bitrate sample).
A tool that can report per-client aggregate uplink frame bytes per second — tshark with appropriate filters, airodump-ng, or a custom Python script using scapy.
A controlled way to introduce motion in front of suspected camera positions without tipping off anyone who might be watching the stream.

Measurement setup with tshark:

# Put adapter in monitor mode (Linux — replace wlan1 with your adapter)
ip link set wlan1 down
iw wlan1 set monitor none
ip link set wlan1 up
# Lock to the AP channel (e.g., channel 6 = 2437 MHz)
iw wlan1 set channel 6

# tshark: report per-station uplink bytes summed over 1-second intervals
# -i: interface  -a duration:60: capture 60s  -q: suppress packet dump
# Uplink frames: wlan.fc.tods == 1
tshark -i wlan1 -a duration:60 -q \
    -z "io,stat,1,\
COUNT(frame)frame&&wlan.fc.tods==1,\
SUM(frame.len)frame&&wlan.fc.tods==1" \
    2>/dev/null | head -80

# Alternative: per-STA uplink rolling count using field extraction
tshark -i wlan1 -T fields \
    -e frame.time_epoch -e wlan.sa -e frame.len \
    -Y "wlan.fc.tods == 1" -l 2>/dev/null | \
    awk '{
        sta[$2] += $3
        if ($1 != last_sec) {
            if (last_sec != "") {
                for (s in sta) printf "%.0f %-20s %d B/s\n", last_sec, s, sta[s]
                delete sta
            }
            last_sec = $1
        }
    }' | sort -k1,1 -k3,3rn

Bitrate-vs-motion time series — ASCII chart:

The following represents observed uplink bytes per second for a single Wi-Fi client (a streaming 1080p VBR camera) across a 60-second window. A controlled motion event (person walking past the camera’s FOV) was induced at T=20s and ended at T=35s.

Uplink kBps
    │
600 ┤                    ╔═══════════════╗
    │                   ╔╝               ╚╗
500 ┤                  ╔╝                 ╚╗
    │                 ╔╝                   ╚╗
400 ┤                ╔╝                     ╚╗
    │               ╔╝                       ╚╗
300 ┤             ╔═╝                         ╚═╗
    │           ╔═╝                             ╚═╗
200 ┤        ╔══╝                                 ╚══╗
    │      ╔═╝                                       ╚═╗
100 ┤━━━━━━╝   Static baseline (≈ 80 kBps)           ╚━━━━━━━━━━━
    │
  0 ┼────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────►
    0    5   10   15   20   25   30   35   40   45   50   55   60
                         │◄ MOTION EVENT ►│
                        T=20s            T=35s

  Legend:
  ━━━  Static-scene baseline (P-frames only; low residuals)
  ╔╗   Motion-response peak (I-frames + high-residual P-frames)
       Peak: ≈ 600 kBps (7.5× above baseline)
       Rise time: ≈ 2s (encoder + network latency)
       Fall time: ≈ 4s (tail from GOP boundary completion)
  Note: values are representative (spec-sourced); verify on bench
        with an actual camera. VBR behavior depends on GOP size,
        scene content, stream bitrate setting, and encoder chipset.

Reading the chart: The baseline at ~80 kBps represents the VBR floor during a static scene — mostly P-frames carrying near-zero residuals. The motion event at T=20s forces the encoder to generate high-residual P-frames immediately, followed by an I-frame forced by scene-change detection, followed by more high-residual P-frames tracking the moving subject. The peak at ~600 kBps is the combined effect of these larger frames hitting the network. After the motion stops at T=35s, the encoder continues generating high-residual frames for one to two GOP periods before settling back to the baseline.

[FIGURE SLOT — Vol 3, § 5.4] Wireshark capture showing an IP camera’s uplink bitrate spiking on induced motion vs. its idle baseline. Source: Photo Helper search “wireshark camera bitrate spike” — or a bench capture. Caption when filled: “Figure 3.M — Motion-correlated uplink bitrate spike in a Wi-Fi camera’s RTSP/RTP stream. Photo: bench capture (author’s own).”

Test procedure step-by-step:

Establish a per-client baseline. Run the tshark capture for 30 seconds with no deliberate motion. Record the uplink bytes/second for each client on the channel. Most client devices (phones on a couch, laptops in standby) show an uplink that is near-zero between keepalive frames. A streaming camera shows a non-zero, relatively stable baseline at its VBR floor.
Identify candidate clients. Any client showing sustained uplink traffic above ~50 kBps while you are stationary is a candidate. Cross-reference against the OUI table (§2) and discovery results (§3) — but do not require a camera-vendor OUI match.
Introduce a controlled motion event. Wave a hand or walk slowly past suspected camera placements, one at a time. This is the “blind walking” version of the test — you are correlating your position and motion against the traffic spike you observe.
Observe correlated spikes. Look for any candidate client whose uplink bytes/second increases within 1–5 seconds of your motion and returns to baseline within 5–15 seconds of you stopping. The tighter the temporal correlation, the stronger the evidence.
Repeat at multiple positions. If a client shows a spike only when you walk past a specific object (the smoke detector, the USB charger), that object is the prime suspect.
Confirm with other techniques. A traffic-rate spike is strong behavioral evidence but not a 100% certain identification — it rules out almost all non-camera clients but cannot definitively confirm. Follow up with discovery probing (§3), an RTSP access attempt (§4), and/or deauth-confirm (§6). Physical inspection (the lens-glint technique from Vol 4) provides the final ground truth.

3.5.5 Robustness vs. fragility

Why traffic-rate / motion-correlation is the most robust Wi-Fi detection technique:

Table 16 — Why traffic-rate / motion-correlation is the most robust Wi-Fi detection technique:

Challenge	OUI fingerprinting	Discovery probing	Traffic-rate correlation
MAC randomization / LAA MAC	Breaks (OUI is meaningless)	Breaks (can’t correlate client to probe response)	Survives (observing frame rate doesn’t require knowing the MAC’s manufacturer)
Generic chipset OUI (ESP32, Realtek)	Breaks (OUI resolves to chipmaker)	Partially survives (device may still respond)	Survives (VBR behavior is independent of chipset OUI registration)
mDNS/ONVIF disabled	N/A	Breaks (no discovery response)	Survives (traffic exists regardless of service discovery config)
Camera not on your network (guest/host isolation, hidden SSID)	Breaks (can’t see ARP table or DHCP leases)	Breaks (multicast probes may not reach the camera)	Partially survives — encrypted 802.11 frames visible in monitor mode even from a camera on a different SSID; correlation still works if you can identify the camera’s transmitter MAC by BSSID observation
White-label / no-brand camera	Breaks (no camera-vendor OUI entry)	May survive (if ONVIF-conformant)	Survives (VBR physics applies regardless of brand)

The key insight: traffic-rate correlation is a behavioral technique, not a fingerprinting technique. It does not rely on the camera identifying itself; it exploits the physics of the video encoding pipeline. A camera that has been specifically hardened against fingerprinting (randomized MAC, mDNS disabled, ONVIF authentication required) cannot harden against VBR physics without switching to CBR mode — which wastes bandwidth and is not the default on any consumer camera.

The off-network case: When the camera is on a network you cannot join (the host’s separate AP, a hidden-SSID AP, or a client-isolation VLAN), you cannot observe the camera’s traffic via a joined DHCP client. However, if you are in monitor mode on the AP’s channel, you can still see the 802.11 frames from the camera’s radio. The transmitter MAC is visible in unencrypted 802.11 header fields even on WPA3-encrypted traffic; you cannot read the payload, but you can count bytes per second per transmitter MAC. The motion-correlation technique applies at this layer. Forward pointer: if the camera’s radio is visible but the traffic is insufficiently accessible for correlation (very low bitrate sub-stream, strong obstructions), the RSSI-walk technique in Vol 5 §5 handles localization once the radio is detected.

3.5.6 Failure modes

Traffic-rate / motion-correlation has four failure modes that a sweep protocol must account for:

Table 17 — Traffic-rate / motion-correlation has four failure modes that a sweep protocol must account for

Failure mode	Condition	Detection gap	Mitigation
Camera in standby	Camera uses motion-trigger activation: no stream when scene is static	No baseline traffic; motion event may start the stream but with unpredictable latency	Test twice: first pass establishes baseline, second pass introduces sustained motion from all angles
CBR mode	Camera configured for constant-bitrate output	No spike on motion; uplink is flat regardless	CBR stream still shows sustained constant uplink (non-zero baseline unlike idle phones); the baseline itself is a signal; follow up with RTSP probe
SD-only camera	Camera records locally; no Wi-Fi radio at all	Completely invisible to all Wi-Fi methods	Requires optical (lens-glint), thermal, NLJD, or physical inspection — see Vol 4
Low-density motion / stale channel	Motion event not detected because monitoring adapter was dwelling on a different channel	Correlation missed	Use channel locking once a candidate client is identified; sweep all channels before locking

The SD-only failure mode is structural: this technique — like all Wi-Fi techniques — cannot detect a camera with no radio. Constraint #1 applies. The motion-correlation technique is the most powerful tool in the Wi-Fi-layer arsenal; it is not a substitute for the non-emitting methods in Vol 4.

3.6 Deauth-confirm

3.6.1 How deauth-confirm works

Deauthentication (deauth) in 802.11 is a management-frame notification that a station or AP terminates an existing authentication/association. A deauth frame is 802.11 management type 0, subtype 12 (0x0C), sent unencrypted in 802.11 pre-WPA3 deployments. In WPA3-SAE networks, management frame protection (MFP) encrypts and authenticates these frames; unprotected deauths are rejected. In WPA2 networks (the majority of deployed consumer gear), management frames are unauthenticated and unprotected, meaning a third party can forge a deauth frame with any source address.

Deauth-confirm procedure:

Monitor interface (you, wlan1mon)
        │
        │  Step 1: Observe all clients on target AP channel
        │  Identify suspected camera MAC: BC:AD:28:xx:xx:xx
        │
        │  Step 2: Send a deauth frame
        │  Source: spoofed as the AP (BSSID of the camera's AP)
        │  Destination: camera MAC or broadcast
        │
        ▼
  aireplay-ng -0 1 -a <BSSID of AP> -c <suspected-camera-MAC> wlan1mon
        │
        │  Effect (if target is a live Wi-Fi client on that AP):
        │  Camera receives deauth → drops association → re-probes → re-associates
        │
        │  Observable: probe-request frames from the camera MAC immediately
        │  after the deauth, followed by association-request and DHCP request
        │
        ▼
  Result:
  ├── Probe + re-associate observed → live Wi-Fi client confirmed
  │   (may still not be a camera — OUI + traffic-rate needed to confirm type)
  │
  └── No probe / no re-associate → MAC is not an active Wi-Fi client
      (may be ARP-table ghost, MAC in router lease but not online, spoofed entry)

Observable deauth/re-associate sequence in tshark:

# Capture on monitor interface while the deauth is sent
# Look for: (1) deauth frame, (2) probe request from target MAC, (3) assoc request
tshark -i wlan1mon \
    -Y "(wlan.da == <target-MAC> && wlan.fc.type_subtype == 0x0c) || \
        (wlan.sa == <target-MAC> && (wlan.fc.type_subtype == 0x04 || \
                                     wlan.fc.type_subtype == 0x00))" \
    -T fields -e frame.time_relative -e wlan.fc.type_subtype \
    -e wlan.sa -e wlan.da -e wlan.ssid \
    -l 2>/dev/null
# 0x0c = deauth; 0x04 = probe request; 0x00 = association request

The reconnect latency (time from deauth to re-associate) is typically 2–15 seconds for an IP camera, depending on firmware’s backoff and retry behavior.

3.6.2 What it tells you — and what it does not

Table 18 — 6.2 What it tells you — and what it does not

Outcome	What it confirms	What it does NOT confirm
Re-associate observed (probe → assoc → DHCP)	The MAC is an active 802.11 client; it is genuinely connected to the AP	That the device is a camera; OUI + discovery + traffic-rate still needed
No re-associate	The MAC is NOT an active 802.11 client (was an ARP ghost, a wired device with a cached entry, or a MAC that was never actually on-air)	That the address space has no camera; a camera on a different channel or a different SSID would not be affected
Re-associate but traffic-rate correlation shows nothing	Device is a real Wi-Fi client but is not streaming video (phone in standby, smart plug, etc.)	That there is no camera at all

Deauth-confirm’s unique value is in ruling out phantom entries: when a MAC shows up in an ARP table or a DHCP lease list but you are not sure the device is actually online and transmitting, a deauth clears the ambiguity. It cannot distinguish a camera from any other Wi-Fi device — that determination requires the techniques in §2–§5.

3.6.3 Consenting-environment gate

Callout — deauth-confirm is consenting-environment-only: Sending a deauth frame to a client on a Wi-Fi network you do not own is a form of management-frame injection that disrupts the association of the targeted client. In most jurisdictions this constitutes unauthorized interference with a network — potentially a criminal offense under computer-fraud statutes (the Computer Fraud and Abuse Act in the US; Computer Misuse Act in the UK; similar statutes elsewhere) — even if the ultimate intent is defensive counter-surveillance. The technique is documented here for use in a network you own and control, or for which you have explicit written authorization from the network owner.

This constraint is not a formality. In the typical sweep scenario — you are a guest at an Airbnb or hotel, on a network you do not own — deauth-confirm is not authorized. Your sweep in that context uses passive techniques only: OUI lookup, passive mDNS/SSDP listening, passive traffic-rate correlation in monitor mode. Active injection (deauth, probe injection, ARP poisoning) requires consent.

Legitimate uses in a consenting environment:

You own the network and the equipment in the space (your own home, your own lab)
You are a professional TSCM operator with written authorization from the property owner and network administrator
You are testing your own DIY detector device in a controlled environment you own

See _shared/legal_ethics.md for the full hub-wide legal and ethics framework. Cross-reference: Vol 13 (Operational posture, legal & ethics) expands the regional-rules discussion and the find-vs-make line.

WPA3 / Management Frame Protection note: On WPA3-SAE networks with mandatory MFP (management frame protection, IEEE 802.11w), spoofed deauth frames from an unauthorized third party are rejected by the client — the client checks the MIC on the management frame and ignores frames that fail authentication. This means the deauth-confirm technique is unavailable on properly configured WPA3 networks regardless of authorization. Most consumer cameras as of 2026 still deploy WPA2; WPA3 adoption is growing but not universal in the camera segment.

3.7 Resources

Standards bodies and specifications

ONVIF — Open Network Video Interface Forum: https://www.onvif.org/ — Publishes Profile S (streaming), Profile T (advanced streaming), and Profile G (recording and search) specifications. Profile S defines the WS-Discovery mechanism (§3.3), GetDeviceInformation (§3.4), and GetStreamUri (§4.1) APIs used throughout this volume.
IETF RFC 7826 — RTSP 2.0: https://datatracker.ietf.org/doc/rfc7826/ — The authoritative RTSP 2.0 specification covering DESCRIBE/SETUP/PLAY methods, SDP negotiation, and interleaved-over-TCP mode (§4.1).
IETF RFC 6762 / RFC 6763 — mDNS and DNS-SD: https://datatracker.ietf.org/doc/rfc6762/ and rfc6763/ — The wire-format specifications for mDNS service discovery used in §3.1.
IEEE OUI / MAC vendor database — https://standards-oui.ieee.org/ — The authoritative OUI-to-vendor mapping. Download oui.txt or oui.csv for embedding in tools. Updated multiple times daily; the camera-vendor subset used in §2.2 is derived from this database.
OASIS WS-Discovery — https://docs.oasis-open.org/ws-dd/ns/discovery/2009/01 — The WS-DD 1.1 specification for the discovery mechanism used by ONVIF (§3.3).

Academic research (detection-physics lineage)

LocCams — Wang et al., “LocCams: Detecting and Localizing Hidden Cameras with Smartphones via Wi-Fi Signals,” ACM IMWUT, 2023. Demonstrates uplink traffic-rate / motion-correlation for transmitting camera detection and localization. Spec-sourced pending bench review.
CamLoPA — Passive Wi-Fi traffic analysis for camera localization; companion work to LocCams. IEEE S&P 2025 (arXiv 2409.15169); web-verified.
SpyDir — Directional scanning + Wi-Fi traffic analysis for camera location. Transmitting cameras only. arXiv 2602.00411 (2026 preprint); web-verified.

Tools and libraries

avahi-browse / avahi-daemon — Linux mDNS service browser; apt install avahi-utils. avahi-browse -at lists all discovered services. avahi-browse -ar _rtsp._tcp resolves RTSP endpoints. Used in §3.1.
onvif-util — Python-based ONVIF command-line tool for GetDeviceInformation, GetCapabilities, GetStreamUri. pip install onvif-zeep. Used in §3.4.
python-onvif-zeep — Python library for ONVIF interaction via the Zeep SOAP client: github.com/FalkTannhaeuser/python-onvif-zeep. Underlies the WS-Discovery probe in §3.3.
tshark / Wireshark — The Wireshark command-line capture and analysis engine; available in all major Linux distributions. The traffic-rate monitoring filters in §4.3 and §5.4 use tshark with io,stat and field-extraction modes.
nmap — Network scanner; nmap -sV -p 554,8554,8899 for RTSP/ONVIF port detection (§4.3). The nmap-mac-prefixes database provides an offline OUI lookup useful in field conditions without internet.
aireplay-ng / aircrack-ng suite — The deauth-frame injection tool used in §6.1. Consenting-environment only; see §6.3.
wsdd — WS-Discovery daemon for Linux; github.com/christgau/wsdd. Can send discovery probes and listen for ProbeMatch responses (§3.3).

Hub tools and cross-references

ESP32 Marauder Firmware deep dive — Wi-Fi station scan + OUI lookup in firmware; the fork foundation for the DIY build path in Vol 8. The ESP32 Marauder Firmware deep dive documents the scanning and OUI infrastructure this series extends.
Nyan Box deep dive — Native hidden-camera detection with a 20+ brand fingerprint DB; the closest off-the-shelf implementation of the OUI fingerprinting + discovery techniques in §2–§3. See the Nyan Box deep dive Vol 7 for the fingerprint database architecture.
Vol 5 of this series — Wi-Fi / IP camera deep dive: synthesizes the techniques in this volume into the practical camera hunt, including on-network vs. off-network scenarios and the RSSI-walk localization algorithm (Vol 5 §5).
Vol 7 of this series — the ESP32-S3 from-scratch design: implements the OUI fingerprint DB (§5) and the traffic-rate watch (§4 firmware pipeline) based on the physics in this volume.
Vol 8 of this series — the Marauder fork and Raspberry Pi sniffer path: the Pi sniffer implements the full traffic-rate / motion-correlation technique (§5) with a larger OUI DB and a web UI.
_shared/legal_ethics.md — Hub-wide legal and ethics framework; the gate document for deauth-confirm (§6.3) and for the defensive counter-surveillance framing throughout this series.

This is Volume 3 of a fifteen-volume series. Next: Vol 4 tackles the hardest detection problem — cameras that emit nothing. The power-state capability matrix organizes every non-RF method (optical lens retroreflection, IR-emitter spotting, thermal, NLJD, incidental EMI side-channel, acoustic, magnetometer, X-ray, borescope) by what state the camera must be in for the method to work. The robust tell established in this volume (traffic-rate correlation) is explicitly scoped to transmitting cameras; Vol 4 covers the case it cannot reach.

CameraDetection Volume 3 — Detection Physics II: Wi-Fi Network Analysis