Boot-to-cloud network-presence timeline · vendor OUI maps · on/off-network scenarios · RSSI-walk localization

5.1 About this volume

This is the Wi-Fi / IP camera deep dive — the headline target of the CameraDetection series, and the volume most directly useful in the short-term-rental and hotel sweep scenarios where Wi-Fi/IP cameras account for the overwhelming majority of documented covert placements.

What this volume does — and what it does not. Vols 2 and 3 established the detection-physics foundation: Vol 2 covered the RF and spectrum layer, Vol 3 covered the Wi-Fi network-analysis layer in full detail — the OUI fingerprinting pipeline, the four discovery protocols (mDNS/SSDP/WS-Discovery/ONVIF), RTSP/RTMP streaming mechanics, the traffic-rate/motion-correlation technique, and deauth-confirm. This volume does not re-derive those mechanisms. If you need the bit-level detail on VBR encoder physics, WS-Discovery SOAP wire formats, or the academic lineage of motion-correlation detection, go to Vol 3. What this volume does is apply those mechanisms operationally: tracing a camera’s complete network-presence timeline from boot to cloud heartbeat, mapping the practical vendor OUI landscape, working through the four on/off-network scenarios that determine what you can see in any given sweep situation, and walking you to the physical transmitter once detected.

The running theme for this volume — constraint #2, restated at the application level: OUI is fragile (MAC randomization, generic modules, white-label manufacturing). Traffic-rate / motion-correlation is the robust tell (see Vol 3 §5 for full treatment). Off-network and hidden-SSID cameras may expose only an encrypted radio frame stream — that is exactly when the RSSI-walk technique in §5 is the play.

Forward pointer. The RSSI-walk localization algorithm developed in §5 is the firmware algorithm that Vol 7 implements in the ESP32-S3 build. When you reach Vol 7, §5 here is the design specification.

Sourcing. All detection-range and timing claims are spec-sourced pending bench verification. Vendor OUI prefixes are cross-referenced to the IEEE OUI database and prior-volume verification; new entries are marked spec-sourced.

5.2 How IP cameras announce and behave

A Wi-Fi/IP camera is not a passive device. From the moment it powers on until the moment it is unplugged, it produces a sequence of network events that are individually detectable. Understanding this sequence — what each event is, when it happens, and what promiscuous-mode or active-probe tool catches it — is the prerequisite for understanding why any particular camera evades or is caught by any particular detection approach.

The timeline below covers a typical consumer-grade Wi-Fi camera in factory-default or lightly-configured state. A camera that has been deliberately hardened (discovery protocols disabled, cloud-only communication, isolated VLAN) suppresses individual events; §4 covers what remains detectable in those cases.

┌─────────────────────────────────────────────────────────────────────────────────┐
│             IP CAMERA NETWORK-PRESENCE TIMELINE                                  │
├──────────┬──────────────────────────────────────────┬───────────────────────────┤
│ Time (s) │ Event                                    │ Visible to sweeper?       │
├──────────┼──────────────────────────────────────────┼───────────────────────────┤
│  0       │ Power-on / firmware boot                 │ No — silent               │
│  1–3     │ 802.11 probe requests (scanning for SSID)│ Yes — wlan.fc.type=0      │
│  2–5     │ 802.11 assoc request / response          │ Yes — association frames  │
│  3–6     │ DHCP DISCOVER → OFFER → REQUEST → ACK    │ Yes — promiscuous / DHCP  │
│  4–7     │ Gratuitous ARP (ip.addr claim)           │ Yes — ARP table / arping  │
│  5–9     │ mDNS PTR/SRV/TXT (224.0.0.251:5353)     │ Yes — avahi-browse        │
│  6–10    │ WS-Discovery Hello (239.255.255.250:3702)│ Yes — onvif-probe         │
│  7–11    │ SSDP ssdp:alive NOTIFY (239.255.255.250) │ Yes — nmap -sU -p 1900    │
│  9–14    │ UPnP AddPortMapping to home router       │ Yes — router log / UPnP   │
│ 10–20    │ Cloud registration: DNS + TLS connect    │ Yes — sustained TCP/UDP   │
│ 15–30    │ RTSP server listening (554/TCP)           │ Yes — nmap -p 554         │
│ Ongoing  │ Cloud heartbeat (P2P keepalive, 30–60s)  │ Yes — traffic to ext. IP  │
│ On motion│ VBR uplink bitrate spike (2–5× baseline) │ Yes — tshark frame sizes  │
└──────────┴──────────────────────────────────────────┴───────────────────────────┘

Key insight: suppressing any one row in this table does not make the camera invisible. A camera with mDNS and ONVIF disabled still has its MAC address in every 802.11 frame header (OUI visible), still produces a DHCP transaction that appears in the router’s lease table, and still generates a cloud heartbeat uplink every 30–60 seconds. The traffic-rate spike on motion is visible in the encrypted frame stream regardless of which application-layer announcements are suppressed.

5.2.1 Boot sequence and DHCP

On power-on, the camera’s firmware initializes the Wi-Fi stack and scans for its configured SSID. Probe requests — 802.11 management frames broadcast on each channel seeking a named network — are emitted in sequence across the 2.4 GHz and 5 GHz bands (whichever the camera supports). These probe requests carry the source MAC address of the camera’s Wi-Fi interface in cleartext, in the 802.11 frame header. This is the earliest point at which the camera is detectable: a promiscuous-mode capture with airodump-ng or tshark captures the MAC before the camera has joined the network.

Once the camera finds its AP and completes the 802.11 open-authentication and association handshake, it requests an IP address via DHCP. The DHCP DISCOVER is broadcast at L2 and carries the camera’s MAC address. The camera’s hostname in the DHCP Option 12 (Hostname) field is often a recognizable string — HikIPCamera-XXXX, Reolink-CAM-XXXX, WyzeCam-XXXX, amcrest-ip-cam, C4PI_XXXXXXXX (Dahua firmware convention). The DHCP lease table on the router (accessible through the router admin UI if you control the router, or through the host’s router if they cooperate) is a reliable secondary confirmation channel.

After DHCP assignment, the camera sends a gratuitous ARP — an ARP announcement declaring ownership of its new IP address. This is visible to any host on the same L2 segment and populates their ARP cache. If you have a device on the network, arp -a after a minute shows all L2 clients, including any newly-joined camera.

5.2.2 mDNS and ONVIF Hello

Within seconds of IP assignment, a camera with factory-default settings broadcasts its presence on two discovery channels simultaneously.

mDNS (Multicast DNS, RFC 6762 / DNS-SD, RFC 6763): The camera sends a PTR record announcement to 224.0.0.251:5353 advertising its services — typically _rtsp._tcp, _onvif._tcp, and _http._tcp service types. The SRV record carries the camera’s hostname and port; the TXT record carries metadata including stream path fragments, vendor identifiers, and capability flags. This announcement is visible to any device on the same L2 segment using avahi-browse -at (Linux) or dns-sd -B _rtsp._tcp . (macOS).

WS-Discovery Hello (OASIS WS-DD, adopted by ONVIF): The camera sends a SOAP Hello message to 239.255.255.250:3702/UDP. This frame carries the device’s endpoint reference (a UUID-based URN), its Types (dn:NetworkVideoTransmitter for an ONVIF video source), and its XAddrs — the HTTP URL for the ONVIF device-management service. Any tool listening on port 3702 receives this announcement and can immediately query GetDeviceInformation at the returned XAddr URL to retrieve manufacturer, model, firmware version, and serial number without any scanning.

These two announcements together — when not suppressed — give a sweeper the camera’s MAC, IP, hostname, vendor, model, and RTSP stream URL within ten seconds of the camera booting. The detection problem in Case A (§4.1) is almost trivially easy precisely because of these two announcements.

5.2.3 RTSP stream opens

Between fifteen and thirty seconds after boot (varies by firmware complexity and system resources), the camera’s RTSP server becomes ready to accept connections on TCP port 554 (the IANA-assigned standard port). At this point:

nmap -p 554 <camera-ip> returns 554/tcp open rtsp — confirming the presence of a streaming server.
A DESCRIBE request to rtsp://<camera-ip>/ (or a vendor-specific path like rtsp://<camera-ip>/Streaming/Channels/101 for Hikvision) returns an SDP response containing the codec (H.264 or H.265), resolution, frame rate, and audio channel parameters.
If authentication is disabled (common factory default on many budget cameras — a separate security problem), the stream is accessible with ffprobe rtsp://<camera-ip>/Streaming/Channels/101 -v quiet -print_format json -show_streams or vlc rtsp://<camera-ip>/...

From a detection standpoint, a successful RTSP DESCRIBE to an anonymous camera returns vendor-confirming data in the SDP fields and definitively establishes that the host at that IP is a live video source. A 401 Unauthorized response is also confirmation — the RTSP server exists and requires credentials; the device is almost certainly a camera.

Sub-stream: Most cameras simultaneously open a second lower-bitrate RTSP stream (sub-stream, typically CIF or 360p at 256–512 Kbps) in addition to the main stream. This doubles the uplink traffic signature visible in promiscuous mode and provides twice the motion-correlation signal.

5.2.4 Cloud relay heartbeat

The feature that distinguishes modern IP cameras from earlier-generation cameras is cloud connectivity — the ability to view the camera stream from anywhere via a vendor app, without port-forwarding or a static IP. This cloud relay architecture has a persistent network-presence signature that is visible regardless of whether any ONVIF discovery or mDNS announcement is enabled.

Architecture: The camera contacts the vendor’s cloud infrastructure on boot, authenticates with a device-specific UID or serial number, and establishes a persistent outbound TCP or UDP connection. The viewer app (Hik-Connect, Reolink App, Wyze app, Tapo app, etc.) also contacts the same cloud, which then brokers a direct or relayed video path between the two. The specific relay technology varies by vendor.

P2P UID / heartbeat details by vendor architecture:

Table 1 — P2P UID / heartbeat details by vendor architecture:

Vendor	Cloud infrastructure	Relay technology	Heartbeat port	Keep-alive interval
Hikvision	`hik-connect.com` / AWS	CloudP2P (proprietary UDP + fallback relay)	443/TCP (TLS) + high UDP	~60 s
Dahua / Amcrest	`easy4ip.com`, `dahuap2p.com`	P2P (proprietary; similar to TUTK)	443/TCP, high UDP	~30 s
Reolink	`reolink.com` AWS endpoint	Proprietary P2P over UDP	443/TCP, 9000/UDP (spec-sourced)	~30 s
Wyze	AWS IoT (`mqtt.wyzecam.com`)	MQTT over TLS-443 + WebSocket	8883/TCP or 443/TCP	~60 s (MQTT PINGREQ)
Tapo (TP-Link)	`n.tplinkcloud.com`, `security.iotcl.com`	TP-Link Smart Home P2P	443/TCP	~60 s
Eufy (Anker)	`homebase.eufylife.com`	Anker proprietary relay	443/TCP (spec-sourced)	~60 s (spec-sourced)
Ring (Amazon)	`ring.com` AWS endpoints	AWS IoT + WebRTC relay	443/TCP + TURN/STUN	~30 s (spec-sourced)
Generic (TUTK-based)	`iotcam.com`, `cs2.iotcam.com`	TUTK Cameleon P2P (PPPP/CS2 protocol)	10000/UDP, 32100/UDP (spec-sourced)	~30 s

Callout — cloud heartbeat is always present: A camera that has had mDNS disabled, ONVIF discovery disabled, and UPnP disabled will still show sustained periodic outbound traffic to an external IP address. This is the cloud heartbeat. In a sweep context, monitoring outbound traffic from each client on the network and identifying any client that maintains a persistent connection to an external cloud IP — especially on port 443 or a high UDP port — is a reliable secondary detection signal even when all local-discovery mechanisms are suppressed.

TUTK PPPP/CS2 protocol (common in budget cameras): Many budget cameras sold under dozens of brand names (including some Amcrest variants, many Amazon-sold “P2P cameras”, and numerous white-label devices) use the ThroughTek (TUTK) PPPP SDK or its CS2 successor. The camera identifies itself to TUTK infrastructure with a 20-character ASCII UID (encoded in the QR code on the camera’s label). The protocol is unencrypted in many implementations — the heartbeat and P2P session setup are visible in plaintext in Wireshark. The iotcam.com nameservers resolve to TUTK infrastructure; capturing a DNS lookup for any *.iotcam.com or *.p2p.tutk.com hostname from a client on your network is a near-certain camera indicator.

5.2.5 UPnP port-map attempts

Cameras that implement UPnP use the WANIPConnection:1 or WANPPPConnection:1 service on the home router to punch external ports open for remote access without manual port-forwarding. The camera sends a SOAP AddPortMapping request to the router’s UPnP endpoint (typically http://192.168.1.1:1900/ or whatever the SSDP-advertised LOCATION URL resolves to), requesting that the router forward an external TCP port to its internal port 554 (RTSP) or port 80 (web UI).

Detection significance: UPnP port-map requests are visible in the router’s UPnP status table (if you control the router) and as SOAP HTTP traffic to the router’s LAN IP. If you can read the router’s NAT table via its admin UI and find unexpected port-forwarding rules for internal IPs on port 554 — especially newly-created rules that appeared around the time you think a camera was installed — that is strong circumstantial evidence of a camera.

What cameras do and don’t do:

Table 2 — What cameras do and don't do:

Behavior	Common?	Detection tool
UPnP AddPortMapping for RTSP (554)	Common — consumer cameras default to UPnP	Router UPnP table; nmap UPnP script
UPnP AddPortMapping for HTTP web UI	Less common (security risk; some suppress)	Router UPnP table
Direct outbound cloud connection (no UPnP)	Very common for cloud-relay cameras	Monitor outbound TCP/443
Manual port-forwarding by the host	Possible for fixed-IP cameras	Router NAT table
No external access (LAN-only recording)	Wired NVR / isolated VLAN scenario	No UPnP; check for NVR on LAN

Limitations: UPnP activity requires you to be on the same network as the camera’s router — Case A or Case B in §4. Cases C and D have no UPnP visibility.

5.3 Vendor OUI maps

5.3.1 The practical OUI reference

The OUI fingerprinting pipeline and its mechanics are documented in full in Vol 3 §2. This section is the applied reference: the practical lookup table with real OUI prefixes, cloud services, and default ports for the eight vendors most commonly associated with covert-camera placements.

OUI fragility caveat (see §3.2): every OUI below is a starting point, not a definitive identifier. A camera with a matching OUI is a suspected camera; the traffic-rate test (Vol 3 §5) is the confirmation. A camera with a non-matching OUI is not cleared — proceed to traffic-rate correlation. See §3.2 for the full fragility analysis.

Vendor OUI, cloud service, and port reference:

Table 3 — Vendor OUI, cloud service, and port reference:

Vendor	Registered entity	Confirmed OUI prefixes	Cloud service / relay	Key ports
Hikvision	Hangzhou Hikvision Digital Technology Co., Ltd.	`BC:AD:28` · `C0:56:E3` · `44:19:B6` · `54:8C:81` · `24:48:45` · `0C:75:D2` · `58:03:FB`^[`58:03:FB` is a confirmed IEEE MA-L registration for Hangzhou Hikvision Digital Technology Co., Ltd. (registered 2018-04-13). Device-level assignment to specific Hikvision camera models is unverified — spec-sourced; confirm against current IEEE OUI DB before treating as a camera fingerprint.]	`hik-connect.com` (CloudP2P) · iVMS-4200 client	RTSP 554, ONVIF 8899/80, Web 80/443, P2P 443
Dahua	Zhejiang Dahua Technology Co., Ltd.	`90:02:A9` · `3C:EF:8C` · `E0:50:8B` · `38:AF:29` · `08:ED:ED` · `4C:11:BF`	`easy4ip.com`, `dahuap2p.com` · DMSS app	RTSP 554, ONVIF 80, Web 80/8080, P2P 443
Wyze	Wyze Labs, Inc.	`2C:AA:8E` · (many use Espressif `EC:FA:BC` or MediaTek)	AWS IoT `mqtt.wyzecam.com` · Wyze app	RTSP 554 (opt-in), MQTT 8883/443
Reolink	Reolink Innovation Limited	`EC:71:DB`	`reolink.com` AWS · Reolink App	RTSP 554, ONVIF 80, Web 80/443, P2P UDP
Amcrest	OEM of Dahua hardware	Shares Dahua OUIs (`90:02:A9` etc.)	`amcrest.com` · Amcrest Cloud (Dahua-backed)	RTSP 554, ONVIF 8080, Web 80/443
Tapo (TP-Link)	TP-Link Technologies Co., Ltd.	`50:C7:BF` · `B0:BE:76` · `6C:5A:B5` · `AC:84:C6` (spec-sourced^[TP-Link OUI prefixes confirmed via IEEE OUI database for TP-Link Technologies Co. Ltd.; which prefixes ship specifically on Tapo camera hardware is spec-sourced pending device-level verification.])	`n.tplinkcloud.com`, `security.iotcl.com` · Tapo app	RTSP 554, Web 80/443, P2P 443
Eufy (Anker)	Anker Innovations Limited	`40:26:19` · `44:27:B5` · (spec-sourced^[Anker OUI prefixes confirmed in IEEE database; Eufy-branded camera hardware may present these or dedicated Eufy OUI blocks. Verify against live device before committing to fingerprint DB.])	`homebase.eufylife.com` · Eufy Security app	RTSP 554 (via HomeBase), P2P 443 (spec-sourced)
Ring (Amazon)	Ring LLC / Amazon Technologies, Inc.	`74:C2:46` · `7C:E9:D3` (spec-sourced^[Ring LLC and Amazon Technologies have multiple IEEE OUI registrations. The specific OUI prefixes that ship in Ring doorbell and security camera hardware are spec-sourced pending device-level verification from the IEEE OUI database.])	`ring.com` AWS IoT · Ring app	P2P 443, WebRTC TURN 443/3478

Additional OUIs of significance in camera sweeps:

Table 4 — Additional OUIs of significance in camera sweeps:

OUI prefix	Registered to	Camera context
`EC:FA:BC`	Espressif Systems	Generic ESP32 Wi-Fi module — any ESP32-based camera, smart lock, sensor, or IoT device; demands deeper investigation
`A4:CF:12`	Espressif Systems	Same as above (second Espressif MA-L block)
`74:DA:38`	Edimax Technology Co., Ltd.	Common in low-cost IP camera modules; several budget brands use Edimax modules
`9C:65:F9`	MediaTek Inc. (via Ralink)	MediaTek Wi-Fi chipset — common in mid-range cameras; white-label risk high
`00:E0:4C`	Realtek Semiconductor Corp.	Realtek WLAN — similar to MediaTek situation
`C4:B5:02`	Various (spec-sourced)	Appears in some Eufy and generic Chinese camera teardowns — verify against IEEE DB

ONVIF port reference (applies across all ONVIF-conformant vendors):

Table 5 — ONVIF port reference (applies across all ONVIF-conformant vendors):

Port	Protocol	Service	Notes
80	HTTP/SOAP	ONVIF device service	Dahua, NVRs, many generic
443	HTTPS/SOAP	Encrypted ONVIF	Hardened deployments
554	RTSP	Video stream control	Near-universal; Profile S mandates
8080	HTTP	Alternate web UI	Amcrest, some Dahua, many generic
8554	RTSP (alternate)	Same as 554	Hikvision NVR RTSP when 554 is NAT-mapped
8899	HTTP/SOAP	Hikvision ONVIF device service	Hikvision IP cameras specifically
1935	RTMP	Cloud video push	Cameras with live CDN/RTMP push enabled
3702	WS-Discovery	ONVIF Hello/Probe	All ONVIF Profile S devices
5353	mDNS	Bonjour service records	Reolink, Amcrest, some Hikvision
1900	SSDP	UPnP device advertisement	NVRs, UPnP-enabled cameras

5.3.2 OUI fragility — the caveat you must carry

Vol 3 §2.4 documents the three independent failure modes in detail. This section restates the essential message in operational form.

The OUI is a starting gun, not a finish line. A camera-vendor OUI match moves the client into the suspect queue for deeper investigation. An OUI non-match does not clear a client — it means the client did not immediately self-identify as a camera. Both outcomes require traffic-rate/motion-correlation (Vol 3 §5) to reach a confident conclusion.

What can fool the OUI layer:

Table 6 — What can fool the OUI layer:

Failure mode	How common	Consequence
Generic Wi-Fi module (Espressif, Realtek, MediaTek)	Very common in budget and white-label cameras	OUI resolves to chipmaker, not camera vendor; any ESP32 OUI could be a camera or could be a lightbulb
MAC randomization	Rare in dedicated cameras (most do NOT randomize once associated); possible in ESP32-based grey-market cameras	OUI lookup returns `02:xx:xx:xx:xx:xx` (LAA bit set) — completely meaningless; traffic-rate is the only detection path
White-label / grey-market OEM	Moderate — hundreds of Amazon-sold brands are Dahua or Hikvision hardware with different labels	May present Dahua OUI with “SOLIOM” or “ZOSI” in the DHCP hostname — or may not present any camera-vendor OUI if the reseller registered a separate block
Hikvision NVR (not a camera)	Low	Hikvision OUI on a network switch or NVR triggers a camera flag; ONVIF GetDeviceInformation or RTSP probe distinguishes NVR from camera

Bottom line: run OUI fingerprinting first because it is cheap and catches obvious cameras immediately. Do not stop there. Always apply traffic-rate correlation as the second pass, using the procedure in Vol 3 §5.4: set up a promiscuous capture on the target AP’s channel, watch per-client uplink frame sizes over a 1-second window, induce controlled motion in front of suspected hiding spots, and correlate a bitrate spike to a specific client MAC. That spike is the robust tell — it works regardless of whether the OUI resolved, regardless of whether ONVIF discovery returned anything, and regardless of whether the camera is using a randomized MAC.

5.3.3 Field OUI lookup workflow

In a sweep context, you typically do not have time for a full IEEE OUI database download. The practical field workflow:

# 1. Put your Wi-Fi adapter into monitor mode and scan the target network
sudo airmon-ng start wlan1
sudo airodump-ng --channel 1,6,11,36,40,44,48,149,153,157,161 wlan1mon \
    --write /tmp/sweep-cap --output-format csv,pcap \
    --band abg --update 1

# 2. While airodump-ng is running, extract unique client MACs from the CSV
# (airodump-ng STA lines appear after the AP list, separated by a blank line)
tail -n +12 /tmp/sweep-cap-01.csv | grep "," | \
    awk -F',' 'NF>10 {gsub(/ /,""); print $1}' | sort -u > /tmp/macs.txt
cat /tmp/macs.txt

# 3. Bulk OUI lookup against a local copy of the IEEE database
# (download oui.txt from https://standards-oui.ieee.org/oui/oui.txt first)
while read mac; do
    oui=$(echo $mac | tr -d ':' | tr 'a-f' 'A-F' | cut -c1-6)
    vendor=$(grep -i "^$oui" /path/to/oui.txt | head -1 | awk '{$1=$2=""; print $0}')
    echo "$mac  $vendor"
done < /tmp/macs.txt

# 4. Online fallback (requires network access) — macvendors.com REST API
while read mac; do
    result=$(curl -s "https://api.macvendors.com/$mac")
    echo "$mac  $result"
    sleep 0.5  # rate limit: free tier allows ~2 req/s
done < /tmp/macs.txt

What to flag immediately: any client whose OUI resolves to Hikvision, Dahua, Reolink, Wyze, Amcrest, Tapo, Eufy, Ring, Edimax, or any string containing “camera,” “vision,” “digital,” or a Chinese technology company name. Also flag OUIs resolving to Espressif or generic Chinese chipsets — these are not confirmed cameras but demand deeper investigation.

nmap MAC-vendor approach (alternative for small networks):

# nmap: scan the subnet, show MAC vendor for each host
# Requires being on the same L2 network (Case A or B) to see MACs
sudo nmap -sn 192.168.1.0/24 --script=mac-geolocation,targets-asn 2>/dev/null | \
    grep -E '(Nmap scan|MAC Address|00:)' | paste - -

5.3.4 Cloud services and P2P architectures

Understanding which cloud infrastructure a camera uses determines what external traffic signatures to look for during a sweep.

TUTK PPPP / CS2 (very common in budget cameras): The ThroughTek PPPP and its successor CS2 protocol are embedded in hundreds of millions of IP cameras sold under white-label brands on Amazon, AliExpress, and eBay. The camera encodes a 20-character device UID in its firmware and QR code label, and registers with TUTK’s infrastructure at cs2.iotcam.com, td-dev.iotcam.com, or regional variants. Traffic analysis signature: repeated outbound UDP datagrams to port 10000 or 32100 at external IPs, with a consistent 30-second interval (the PPPP keepalive). The ThroughTek infrastructure responds with relay session parameters. In older PPPP implementations (before TUTK’s 2021 security hardening), these packets were unencrypted and contained the camera UID in plaintext — a Wireshark capture revealing a clear-text 20-character UID in a UDP payload to 10.x.x.x:10000 or a public IP is a near-certain TUTK P2P camera fingerprint.

Hikvision CloudP2P: Hikvision’s relay uses a combination of proprietary UDP hole-punching and fallback HTTPS relay. The camera registers with hik-connect.com (resolves to Amazon CloudFront or AWS EC2 regional endpoints). The device serial number is the authentication token. Traffic signature: sustained TCP connection to port 443 at CloudFront IP ranges (54.xx.xx.xx, 52.xx.xx.xx) plus periodic UDP probes during P2P session establishment.

Wyze AWS IoT (MQTT): Wyze cameras use AWS IoT with MQTT over TLS on port 8883 (or MQTT over WebSocket on 443 as fallback). The MQTT broker URL is mqtt.wyzecam.com (resolves to AWS endpoints). Traffic signature: persistent TCP/TLS connection on port 8883 with regular MQTT PINGREQ/PINGRESP packets every 60 seconds — the PINGREQ is a fixed-size frame that appears as a small periodic uplink spike regardless of scene motion. Distinguishable from the motion-correlation signal because the heartbeat has a fixed interval and fixed size; the motion spike is variable and correlated with scene events.

5.4 On-network vs off-network cams

The single variable that most determines what a sweeper can detect — and which tools apply — is whether the camera is on a network you have joined (full L2 access) or a network you can only observe from outside (encrypted radio only). Four cases cover every real-world configuration.

┌─────────────────────────────────────────────────────────────────────────┐
│              ON-NETWORK VS OFF-NETWORK DECISION DIAGRAM                  │
└──────────────────────────────────┬──────────────────────────────────────┘
                                   │
                        ┌──────────▼──────────┐
                        │ Can you join the     │
                        │ camera's network?    │
                        └────┬────────────┬───┘
                             │YES         │NO
                             │            │
                ┌────────────▼──┐    ┌────▼───────────────────────┐
                │ Is it the     │    │ Is the camera's radio       │
                │ ONLY network  │    │ visible at all in scan?     │
                │ in the room?  │    └────┬────────────────────┬───┘
                └───┬──────┬───┘         │YES                 │NO
                    │YES   │NO            │                    │
                    │      │        ┌─────▼──────┐    ┌───────▼──────┐
                    │      │        │ CASE C      │    │ Hard case:   │
                    │      │        │ Own AP /    │    │ wired, SD-   │
                    │      │        │ hidden SSID │    │ only, or     │
                    │      │        │             │    │ isolated VLAN │
                    │      │        └─────────────┘    │ beyond your  │
           ┌────────▼──┐ ┌─▼──────────────────┐       │ scan range   │
           │ CASE A     │ │ CASE B              │       └──────────────┘
           │ Your own   │ │ Host's network;     │
           │ network;   │ │ you are a guest     │
           │ full L2    │ └─────────────────────┘
           └────────────┘
                │                   │                     │
                ▼                   ▼                     ▼
         Full visibility     Partial visibility     Radio-only (encrypted)
         OUI + ONVIF +       OUI + ARP + scan;     OUI from 802.11 header;
         RTSP + traffic-     limited capture;       traffic-rate visible;
         rate; all tools     no promiscuous          RSSI-walk is the play
                             (without 2nd adapter)

5.4.1 Case A — on your network

Configuration: You own the Wi-Fi network, or you know the PSK and have full admin access. The camera is joined to the same AP as your scanning device. This is the sweep condition when inspecting your own home, a hotel room where you’ve connected to hotel Wi-Fi (with the camera presumably connected to the same hotel AP), or an Airbnb where you’ve joined the host’s Wi-Fi.

What you can see:

Table 7 — What you can see:

Detection method	Works?	Tool	Notes
OUI fingerprinting (passive)	Yes — MAC in every frame	airodump-ng, tshark	Best run with adapter in monitor mode
DHCP hostname lookup	Yes	Router admin UI / DHCP log	Often reveals camera brand in Option 12 hostname
ARP table scan	Yes	`arp -a`, `nmap -sn 192.168.x.0/24`	Shows all L2 clients
mDNS / Bonjour scan	Yes	`avahi-browse -at`	Returns service type, hostname, IP, port
WS-Discovery / ONVIF probe	Yes	`onvif-probe` script, Vol 3 §3.3 Python snippet	Returns manufacturer, model, serial, RTSP URL
RTSP port scan (active)	Yes	`nmap -sV -p 554,8554,8899,8080 192.168.x.0/24`	Confirms streaming server presence
RTSP DESCRIBE (anonymous)	Possibly	`ffprobe rtsp://..., curl RTSP DESCRIBE`	Returns SDP with codec/resolution if auth disabled
Traffic-rate / motion-correlation	Yes	`tshark` in monitor mode; Vol 3 §5.4 procedure	Definitive behavioral confirm; works even if all discovery suppressed
Cloud heartbeat identification	Yes	`tshark -f "host <camera-ip>"` watching external IPs	TUTK, CloudP2P, MQTT signatures visible

Practical sweep procedure for Case A:

# Step 1: List all clients on the network (requires being joined to it)
sudo nmap -sn 192.168.1.0/24 | grep -E '(Nmap|MAC|report)'

# Step 2: Scan each discovered client for camera-characteristic ports
sudo nmap -sV -p 554,8554,1935,8080,8899,3702,5353 192.168.1.0/24 --open \
    -oG /tmp/portscan.txt 2>/dev/null
grep "554/open\|8899/open\|8080/open" /tmp/portscan.txt

# Step 3: Active ONVIF WS-Discovery probe
# (use the Python snippet from Vol 3 §3.3 or onvif-probe tool)
python3 onvif_probe.py --timeout 5  # broadcasts to 239.255.255.250:3702

# Step 4: Probe any RTSP server for anonymous access
ffprobe -v quiet -print_format json -show_streams \
    "rtsp://192.168.1.XX:554/" 2>&1 | head -30
# Or attempt vendor-specific path:
ffprobe -v quiet -print_format json -show_streams \
    "rtsp://192.168.1.XX:554/Streaming/Channels/101" 2>&1 | head -30

# Step 5: Traffic-rate motion-correlation (monitor mode adapter required)
sudo ip link set wlan1 down
sudo iw dev wlan1 set type monitor
sudo ip link set wlan1 up
sudo iw wlan1 set channel 6  # match the AP channel
tshark -i wlan1 -Y "wlan.fc.tods==1" \
    -T fields -e frame.time_epoch -e wlan.sa -e frame.len \
    -l 2>/dev/null | awk '{print $1, $2, $3}' > /tmp/uplink.log
# Then introduce motion and look for frame-size spikes in uplink.log

Case A summary: Maximum visibility. The camera is on your network; all detection layers apply. The OUI layer catches branded cameras immediately; ONVIF/mDNS gives model-level identity; RTSP confirms streaming capability; traffic-rate is the conclusive behavioral test that survives all application-layer suppression.

5.4.2 Case B — guest on the host network

Configuration: You are a guest on a network you did not create and whose PSK you received from the host. The camera (if present) is joined to the same AP and is thus on the same L2 segment. This is the most common Airbnb scenario: you connect to “AirbnbProperty_2G” and the host’s cameras are also on that network.

What changes from Case A:

You cannot access the router admin UI to read the DHCP lease table or NAT rules (unless the router has no password — check anyway).
Your scanning device is on the same network as the camera, so ARP, mDNS, SSDP, and RTSP probing all work normally.
Monitor mode / promiscuous capture: Your connected Wi-Fi adapter cannot simultaneously be in monitor mode and maintain the connection. You need a second Wi-Fi adapter (a second USB Wi-Fi dongle, or a second built-in card on a laptop) dedicated to monitor mode on the same channel. Without a second adapter, you can still do active scans but cannot do passive promiscuous capture of the camera’s frame-level traffic.
Traffic-rate correlation without a second adapter: You can observe the camera’s uplink indirectly — if you are performing the ARP/RTSP/ONVIF active scan from your connected device, you are generating traffic on the same network and can use a tool like iftop or nethogs to watch the total bandwidth utilization. A more targeted approach: after identifying the camera’s IP, run a sustained ping 192.168.x.XX -f -s 1400 flood and watch whether the camera’s response latency tracks with motion (a crude but sometimes useful correlation indicator).

What to run in Case B:

# Active scan — works from a connected device without monitor mode
# Scan the subnet for camera-characteristic ports
sudo nmap -sV -p 554,8554,8080,8899,3702,1900 192.168.1.0/24 --open 2>/dev/null

# mDNS sweep — works on connected interface
avahi-browse -at 2>/dev/null | grep -iE '(rtsp|onvif|camera|ipcam|hik|dahua|wyze|reolink|tapo|ring|eufy)'

# SSDP sweep — M-SEARCH for all UPnP devices
echo -e "M-SEARCH * HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nMAN: \"ssdp:discover\"\r\nMX: 3\r\nST: ssdp:all\r\n\r\n" | \
    nc -u -w 3 239.255.255.250 1900

# WS-Discovery active probe (script from Vol 3 §3.3)
python3 onvif_probe.py

# Once camera IP identified: attempt RTSP describe
curl -s --max-time 5 "rtsp://192.168.1.XX:554/" \
    --request DESCRIBE --header "CSeq: 1" --header "Accept: application/sdp"

Case B summary: Good visibility on the application layer (ARP, mDNS, ONVIF, RTSP probing all work). Limited passive-capture capability without a second adapter; traffic-rate correlation is possible but less clean than in Case A. You are one tool (a second monitor-mode adapter) away from full Case A visibility.

Practical tip: Carry a dedicated USB 2.4 GHz Wi-Fi dongle (MT7601U or RTL8188EUS chipset, $8–15 on Amazon) solely for monitor mode. Plug it in before checking in, put it in monitor mode on the AP channel, and run airodump-ng in the background while your laptop is connected normally on its built-in adapter. This gives you full Case A capability while you are a guest.

5.4.3 Case C — camera on its own AP

Configuration: The camera creates its own Wi-Fi AP — either as part of setup mode (many cameras create an “AP mode” during initial configuration and some remain in AP mode if never configured), or the host deliberately uses a second router/AP dedicated to camera traffic that you have not joined. Also covers the hidden SSID case, where the camera is on a network whose SSID is not broadcast in beacon frames.

What you can see without joining:

A camera’s AP — even one with a hidden SSID — broadcasts 802.11 beacon frames at roughly 10 Hz. Even if the SSID field in these beacons is null (hidden SSID), the beacon frames themselves are visible in monitor mode and carry:

The AP’s BSSID (the AP’s MAC address — and thus OUI of the AP radio)
The channel
The beacon interval and capabilities

If any clients are associated to the hidden SSID AP, their uplink frames (data frames with ToDS=1) are also visible in monitor mode, carrying the client MAC in the 802.11 header. A camera’s AP and the camera’s client association are typically the same device (the camera itself), so you will see the camera’s MAC in both roles.

Hidden SSID exposure: The SSID is revealed in:

Probe responses: when a client probes for the hidden SSID by name, the AP responds with the SSID in cleartext. If any camera-associated device (e.g., the host’s phone) probes for its network, you capture the SSID name.
Association requests: when a client associates to the hidden AP, its association request frame contains the SSID in cleartext. airodump-ng captures this in --hidden mode and fills in the SSID column once observed.

What the hidden/own-AP case means for detection:

Table 8 — What the hidden/own-AP case means for detection:

Detection method	Works without joining?	Tool
OUI identification (camera MAC)	Yes — MAC is in every 802.11 frame header	airodump-ng; tshark
SSID name discovery	Sometimes — needs probe response or assoc request capture	airodump-ng (fills in over time)
RTSP / ONVIF / mDNS probing	No — requires L2 access (joining the network)	—
Traffic-rate / motion-correlation	Yes — encrypted frame sizes are visible in monitor mode	tshark (filter by camera MAC)
RSSI-walk localization	Yes — monitor mode captures the camera radio signal	airodump-ng + walking

Traffic-rate with hidden SSID: The VBR motion-correlation technique does not require decryption or network access. From a monitor-mode adapter on the camera’s AP channel, filter uplink frames from the camera’s MAC address and measure the aggregate frame size per second. When you introduce motion in front of the suspected camera hiding spot, you will see the bitrate spike in the frame-level capture — even though the content is encrypted and the SSID was hidden. This is the technique described in Vol 3 §5, and it works in Case C exactly as well as in Case A.

5.4.4 Case D — isolated AP or VLAN

Configuration: The host has placed the camera on a dedicated network segment that is physically or logically separated from the guest Wi-Fi. This can be:

A second physical AP (a separate router or access point on a different IP subnet, dedicated to camera traffic — common in security-conscious hosts who have read “separate your IoT devices”)
A VLAN on a managed switch with the guest and camera networks on different VLANs with no inter-VLAN routing
A dual-band segregation: cameras on 2.4 GHz, guests on 5 GHz, with L3 isolation between bands

What you can see: The same as Case C — the camera’s radio is visible in promiscuous mode if you are in range, even though you cannot join its network. The isolated AP’s beacon frames, the camera’s uplink data frames (with ToDS=1 and the camera’s MAC), and the RSSI of the camera’s transmitter are all visible in monitor mode. The OUI is visible. The traffic-rate signature is visible.

What you cannot see: ARP responses, DHCP leases, mDNS/ONVIF announcements, and RTSP access — all require L2 membership on the camera’s segment.

Detection approach for Cases C and D:

Cases C and D reduce the detection problem to its essentials: you have a radio transmitter visible in promiscuous mode, and you need to determine (a) whether it is a camera and (b) where it is physically located.

(a) Is it a camera? OUI fingerprinting (camera-vendor OUI match → likely camera; Espressif/generic → possible camera). Traffic-rate/motion-correlation (Vol 3 §5): set up monitor mode on the AP channel, watch frame sizes from the suspect MAC, induce motion — a spike confirms a streaming device. This is the most useful confirmation available without joining the network.
(b) Where is it? RSSI-walk localization — §5 covers this in full. In Cases C and D, the RSSI-walk is often the only remaining tool for physical location once the traffic-rate test confirms the device is a camera.

Case comparison summary:

Table 9 — Case comparison summary:

Scenario	OUI visible	mDNS/ONVIF	RTSP probe	Traffic-rate	RSSI-walk
A — your network	Yes	Yes	Yes	Yes (monitor mode)	Yes
B — guest, same AP	Yes	Yes	Yes	Partial (second adapter)	Yes
C — camera’s own AP / hidden SSID	Yes (from 802.11 hdr)	No	No	Yes (monitor mode)	Yes
D — isolated AP / VLAN	Yes (from 802.11 hdr)	No	No	Yes (monitor mode)	Yes
Non-emitting (SD/wired)	No RF at all	No	No	No	No — see Vol 4

5.5 Walking to a detected camera

Once you have confirmed — via OUI fingerprinting, traffic-rate correlation, or ONVIF probe — that a specific Wi-Fi client is a camera, you face the physical location problem: the network tells you the camera exists and provides its MAC address; the room tells you nothing about where the camera is hidden. RSSI-walk localization bridges this gap.

Callout — RSSI-walk is the tool for Cases C and D: In Cases A and B you may be able to narrow down the camera’s location from mDNS/ONVIF/RTSP data (the RTSP stream itself shows what the camera sees, which constrains the mounting direction). In Cases C and D — where the camera is on a network you cannot join — RSSI-walk combined with traffic-rate correlation is the primary physical-location tool available. The Vol 7 firmware algorithm implements this procedure on an ESP32-S3 with a real-time RSSI display. The description in §5 is the algorithm specification.

[FIGURE SLOT — Vol 5, § 5] A biquad (“bowtie”) directional antenna for 2.4 GHz, constructed from copper wire soldered to a PCB reflector, connected to a USB Wi-Fi adapter via an SMA pigtail — showing a DIY field tool for RSSI-walk localization with angular bearing capability. Alternatively: a smartphone running the Fing network scanner app with the device list showing a Hikvision camera’s MAC address and IP alongside the signal-strength bar. Source: Photo Helper search “biquad directional antenna 2.4GHz DIY” or “smartphone Fing app network scan”. Caption when filled: “Figure 5.1 — A DIY biquad directional antenna for 2.4 GHz RSSI-walk localization. The biquad element gives ~10 dBi gain and a ~60° beamwidth, allowing bearing estimation to ±5° when rotated. Photo: File:Name.jpg by . .“

5.5.1 RSSI gradient localization

RSSI (Received Signal Strength Indicator) is the power level of a received radio signal, measured in dBm (decibels relative to 1 milliwatt). For a 2.4 GHz or 5 GHz Wi-Fi transmitter in an indoor environment, RSSI is an inverse function of distance:

Free-space path loss (Friis equation):

FSPL (dB) = 20·log₁₀(d_m) + 20·log₁₀(f_Hz) − 147.55

At 2.4 GHz (f = 2.437×10⁹ Hz), 1 m separation:
  FSPL = 20·log₁₀(1) + 20·log₁₀(2.437×10⁹) − 147.55
       = 0 + 187.73 − 147.55 = 40.2 dB

At 2 m: FSPL = 46.2 dB (6 dB more per doubling of distance)
At 4 m: FSPL = 52.2 dB
At 8 m: FSPL = 58.2 dB

Rule of thumb: every doubling of distance loses ~6 dBm of received signal.

Indoor environment: Multipath reflections, wall attenuation (2.4 GHz loses ~3–6 dB per drywall layer, ~10–15 dB per concrete wall), and furniture scattering make real RSSI noisier than the free-space model predicts. Typical indoor RSSI range for an AP to a device:

Table 10 — Indoor environment: Multipath reflections, wall attenuation (2.4 GHz loses ~3–6 dB per drywall layer, ~10–15 dB per concrete wall), and furniture scattering make real RSSI noisier than the free-space model predicts. Typical indoor RSSI range for an AP to a device

Distance	Approximate RSSI (2.4 GHz, line-of-sight)	Indoor with 1 wall
1 m	−30 to −40 dBm	−40 to −50 dBm
3 m	−45 to −55 dBm	−55 to −65 dBm
5 m	−55 to −65 dBm	−65 to −75 dBm
10 m	−65 to −75 dBm	−75 to −85 dBm

The gradient still exists indoors — it is just noisier. The RSSI-walk exploits the gradient: moving toward the transmitter increases RSSI (less negative); moving away decreases it. By following the gradient — binary-searching the space for the direction of increasing RSSI — you converge on the transmitter’s physical location.

Reading RSSI for a specific client with airodump-ng:

# Lock adapter to the camera's channel (e.g., channel 6 = 2437 MHz)
sudo iw wlan1mon set channel 6

# airodump-ng: show only the camera's BSSID/client and RSSI
# Replace XX:XX:XX:XX:XX:XX with the camera's AP BSSID or the camera's client MAC
sudo airodump-ng wlan1mon --bssid XX:XX:XX:XX:XX:XX --update 1 \
    | grep -E '(BSSID|XX:XX)'

# Alternative: tshark — read RSSI of frames from a specific transmitter MAC
# wlan.sa is the Source Address (the camera, uplink frames)
sudo tshark -i wlan1mon \
    -Y "wlan.sa == XX:XX:XX:XX:XX:XX && wlan.fc.tods==1" \
    -T fields -e frame.time_epoch -e wlan_radio.signal_dbm -e frame.len \
    -l 2>/dev/null | awk '{printf "%.1f  %s dBm  %s bytes\n", $1, $2, $3}'

The output gives you a real-time stream of [timestamp] [RSSI dBm] [frame size]. The RSSI is what you track as you walk; the frame size is what you watch for the motion-correlation spike.

5.5.2 Moving-average smoothing

Raw RSSI measurements — even from a stationary observer — fluctuate by ±3 to ±10 dBm due to multipath fading, fast fading (the transmitter or nearby objects moving slightly), and receiver noise. Walking while measuring adds body-shadow effects and near-field reflections from your own body. Averaging is mandatory.

Simple moving average (SMA): The most straightforward approach. Keep a sliding window of the last N RSSI samples and report the average:

RSSI_SMA(n) = (1/N) × Σ RSSI(k)   for k = n−N+1 to n

Recommended window: N = 5 to 10 samples
Sample rate: one sample per 200–500 ms (2–5 Hz)
Total averaging window in time: 1–5 seconds

A 5-sample window at 500 ms per sample averages over 2.5 seconds — long enough to remove fast fading, short enough to respond to a 1–2 m position change in 3–4 seconds.

Exponential moving average (EMA): Weighted toward recent samples, responds faster to position changes, simpler to implement in firmware:

RSSI_EMA(n) = α × RSSI(n) + (1−α) × RSSI_EMA(n−1)

α = 0.2:  slow response, heavy smoothing (recommended for initial search)
α = 0.3:  moderate response (recommended once you're close)
α = 0.5:  fast response, less smoothing (use when within 0.5–1 m)

The ESP32-S3 build (Vol 7 §6) implements an EMA with α stepped from 0.2 to 0.5 as the RSSI increases above −55 dBm (closer means less smoothing needed, faster feedback preferred).

What the smoothed RSSI gradient looks like during a walk:

Distance from camera (m)    Smoothed RSSI (dBm, approx.)
──────────────────────────────────────────────────────────
 10 m (start)               −75 to −80
  8 m (moving toward)       −70 to −75
  5 m                       −60 to −65
  3 m                       −52 to −58
  1.5 m                     −42 to −48
  0.5 m (near camera)       −32 to −38
  0.1 m (on the object)     −20 to −28 (saturates in many cards)

Each step toward the camera: +5 to +8 dBm improvement (warmer).
Each step away:              −5 to −8 dBm loss (colder).

The gradient does not invert — you cannot “walk past” the maximum unless you actually pass through the transmitter’s location (not possible for a camera hidden inside a smoke detector). Maximum RSSI is at the camera’s physical location. If RSSI peaks and then starts dropping as you continue in the same direction, you have passed the camera’s position — back up.

5.5.3 Directional antenna option

An omnidirectional adapter (standard USB dongle with a dipole or patch antenna) receives signal from all directions equally. The RSSI measurement it gives reflects only the distance gradient, not the bearing. For a rough RSSI-walk in a small room (< 5 m), this is sufficient. For a larger space, an unknown hiding region, or a case where multipath is strong enough to obscure the gradient, a directional antenna provides angular discrimination.

Biquad (“double biquad” or “bowtie”) antenna for 2.4 GHz:

Gain: 10–12 dBi (spec-sourced; varies with reflector size and construction)
Beamwidth (E-plane / H-plane): ~60° / ~60° half-power beamwidth
Construction: two square loop elements (each 31 mm × 31 mm for 2.4 GHz center frequency), connected back-to-back on a copper PCB reflector; fed at the center with 50 Ω coax
Approximate parts cost: $5–10 in wire and PCB material; SMA pigtail ~$5
Performance: adequate bearing resolution for a 10–15 m room

Yagi-Uda antenna for 2.4 GHz:

Gain: 12–15 dBi (7-element design), up to 17 dBi (14 elements)
Beamwidth: 30–40° (7 el.) to 20° (14 el.) — significantly sharper than biquad
Better for longer-range bearing work or through-wall situations
Commercial 9–12 dBi Wi-Fi Yagis available for $15–40 (TP-Link TL-ANT2409B class)

Using a directional antenna for bearing:

Point the antenna at a suspected hiding spot region; read RSSI.
Rotate slowly (5° per step) across the entire front wall, ceiling, or space under inspection.
The bearing to the camera corresponds to the peak RSSI on the directional antenna.
Move to a second position 2–3 m away; repeat the sweep.
Triangulate: the intersection of the two peak-RSSI bearings is the camera location.

Bearing accuracy: A biquad with a ~60° beamwidth gives angular resolution of approximately ±5–10° in practice. At 3 m range, ±10° corresponds to ±0.5 m lateral error — sufficient to narrow the search to a single object. A Yagi at 30° beamwidth narrows this to ±2–3° (±0.1–0.2 m at 3 m) — sub-object resolution.

Localization method comparison table:

Table 11 — Localization method comparison table:

Method	Accuracy (indoor)	Requires network join	Works on hidden SSID	Equipment	Cases
RSSI omnidirectional walk	0.5–2 m	No	Yes	Any Wi-Fi adapter in monitor mode	A/B/C/D
Biquad antenna bearing + triangulate	0.2–0.5 m	No	Yes	Biquad + pigtail + USB adapter	A/B/C/D
Yagi antenna bearing + triangulate	0.1–0.3 m	No	Yes	Yagi ($15–40) + pigtail + USB adapter	A/B/C/D
LocCams-style RSSI fingerprinting	0.5–1 m (lab)	No	Yes	Smartphone or adapter (research prototype)	A/B/C/D
Traffic-rate + RSSI correlation	0.5–1 m	No (promiscuous)	Yes	Monitor-mode adapter + motion induction	A/B/C/D
DHCP hostname → subnet → nmap	IP-to-device level	Yes	No	Joined network + nmap	A/B
ONVIF GetDeviceInformation	IP + model known	Yes	No	Joined network + ONVIF client	A/B
RTSP stream view (video tells you where lens points)	Camera FoV tells you	Yes	No	Joined network + RTSP client	A/B

5.5.4 The warmer-colder walk procedure

This is the operational step-by-step procedure for physically locating a detected camera using RSSI. It assumes you have:

Confirmed a specific MAC address as a camera (via OUI match, traffic-rate spike, or ONVIF response).
A Wi-Fi adapter in monitor mode on the camera’s channel.
A real-time RSSI display (airodump-ng RSSI column, or a script reporting the EMA continuously).

Procedure:

RSSI-WALK PROCEDURE — locate the physical transmitter

 Step 1  Setup
         └─ Adapter in monitor mode on camera's channel
         └─ Script or airodump-ng displaying EMA RSSI for camera's MAC
         └─ Note the current RSSI (call it R0)

 Step 2  Initial scan — identify the warmer quadrant
         └─ Face one wall; note RSSI (R_wall1)
         └─ Face opposite wall; note RSSI (R_wall2)
         └─ Face left wall; note RSSI (R_wall3)
         └─ Face right wall; note RSSI (R_wall4)
         └─ Walk 1 step (0.5–1 m) toward the highest RSSI wall

 Step 3  Gradient follow — iterate
         └─ At each position, take 5 RSSI readings (2 s of EMA)
         └─ Record the smoothed value
         └─ If RSSI increased from prior position → continue same direction (warmer)
         └─ If RSSI decreased → reverse (colder) and try a perpendicular direction
         └─ Continue until RSSI is > R0 + 15 dBm or you cannot go further

 Step 4  Vertical component
         └─ Raise adapter toward ceiling; lower toward floor
         └─ If RSSI increases toward ceiling → camera is elevated (ceiling mount / shelf)
         └─ If RSSI increases toward floor → camera is low (outlet, charging cable hiding spot)

 Step 5  Narrowing — within 1–2 m
         └─ Switch to directional antenna (biquad) if available
         └─ Rotate slowly to peak bearing; approach along that bearing
         └─ Switch to faster EMA (α = 0.5) for more responsive reading

 Step 6  Confirmation
         └─ At maximum RSSI position, examine every object in the beam center
         └─ Apply lens-glint check (red/IR light source) to all objects with lens apertures
         └─ Physical inspection of top 3–5 candidates by visual / tactile check

The key insight: you are following a gradient in 3D space. The gradient exists and is monotonically increasing toward the transmitter regardless of multipath — multipath adds noise to individual measurements but does not reverse the long-range gradient. EMA smoothing suppresses the noise. The walk converges because you are following a physics gradient with O(log₂ n) convergence where n is the room dimension in “RSSI step sizes.”

Why the walk stops at the camera: A camera hidden inside a smoke detector on the ceiling is transmitting through 30 cm of plastic and circuit board. The RSSI gradient still points toward the smoke detector because the camera’s antenna is inside it. The final RSSI at 10 cm from the smoke detector will be roughly 20–30 dBm higher than the RSSI from across the room — a completely obvious signal improvement that no multipath can obscure at that range.

5.5.5 Localization without network access

In Cases C and D you may not be able to join the camera’s network at all. The RSSI-walk still works because the camera’s radio is always transmitting — uplink data frames, management frames, and the AP’s own beacon frames all carry the camera’s signal regardless of encryption.

What to monitor for RSSI in the off-network case:

Camera-as-AP mode: The camera’s own AP beacon frames (they appear at ~10 Hz on the AP’s channel) are the most reliable signal source. They are always present, at a consistent power level (beacons are typically sent at the lowest mandatory rate with higher power than data frames), and do not depend on whether any client is associated.
Camera-as-client (on a host’s AP): The camera’s uplink data frames (wlan.fc.tods==1, wlan.sa == camera-MAC) and the AP’s downlink ACK frames to the camera are both visible. The uplink frames have higher signal strength (camera transmits at full power for reliability); the ACK frames from the AP are at the AP’s transmit power level.

airodump-ng RSSI column interpretation:

The PWR column in airodump-ng for a station (STA) entry shows the RSSI of the most recent frame received from that station, not from the AP. This is exactly what you want for the RSSI-walk: it tracks the camera’s transmit signal strength at your adapter’s position. Values become less negative (improve) as you approach the camera.

For an AP (BSSID) row, the PWR column shows RSSI of beacon frames from the AP. If the camera is in AP mode, follow the AP BSSID’s PWR value. If the camera is a client, follow the STA PWR value in the lower section of the airodump-ng display.

Combining traffic-rate with RSSI-walk: In Cases C and D, the traffic-rate test and the RSSI-walk are complementary. Run both simultaneously:

Set up monitor mode and confirm the suspected MAC’s traffic-rate spikes on motion (Vol 3 §5.4).
Once confirmed, switch to RSSI-walk mode (watch the EMA of the camera’s frame-level RSSI while walking).
Have a colleague stand near a suspected object and wave — you watch for a traffic-rate spike and an RSSI peak from the same direction. Both correlating simultaneously is a very strong indicator.

Forward to Vol 7 §6: The RSSI-walk algorithm described in §5.2–§5.4 maps directly to the ESP32-S3 firmware pipeline in Vol 7. The firmware implements: (1) a promiscuous-mode receiver that captures frames from a target MAC, (2) an EMA RSSI smoother with configurable α, (3) a bar-graph or needle display on an ST7789 IPS panel, and (4) an audio “warmer/colder” feedback tone that increases in pitch as RSSI improves. The optional directional-antenna port (SMA connector on the ESP32-S3 module) enables the bearing-estimation mode described in §5.3.

5.6 Resources

Standards and protocols

ONVIF Profile S specification — https://www.onvif.org/profiles/profile-s/ — defines WS-Discovery Hello/Probe, GetDeviceInformation, GetStreamUri, and RTSP/RTMP conformance for IP cameras.
RTSP RFC 7826 — Real Time Streaming Protocol 2.0, IETF 2016. The definitive specification for the DESCRIBE/SETUP/PLAY handshake documented in §2.3.
IEEE OUI / MAC Vendor Database — https://standards-oui.ieee.org/oui/oui.txt — downloadable as plain text; updated daily. The authoritative source for all OUI lookups in §3.
WS-Discovery 1.1 — OASIS WS-DD specification: http://docs.oasis-open.org/ws-dd/discovery/1.1/. The wire-format specification for the ONVIF Hello/Probe mechanism in §2.2.
RFC 6762 (mDNS) + RFC 6763 (DNS-SD) — the specifications for the mDNS/Bonjour service announcement mechanism in §2.2.

Vendor cloud and P2P references

Hikvision Hik-Connect (CloudP2P) — developer documentation at open.hikvision.com; the ISAPI and OpenAPI references describe the cloud registration flow.
ThroughTek (TUTK) P2P SDK — https://www.throughtek.com/; the PPPP/CS2 protocol is undocumented publicly but analyzed in the TUTK P2P security research (Nozomi Networks, 2021 — critical vulnerability advisory for devices using TUTK SDK versions prior to 3.1.10).
Wyze MQTT broker: discussed in community teardowns at forums.wyzecam.com; AWS IoT endpoint confirmed via strings on the Wyze Cam firmware binary.

Tools

airodump-ng (Aircrack-ng suite) — https://www.aircrack-ng.org/ — the standard tool for monitor-mode capture, client RSSI display, and channel-hopping sweeps used throughout §4 and §5.
avahi-browse (Avahi daemon) — standard on most Linux distributions; mDNS browser used in §2.2 and §4.1.
nmap — https://nmap.org/ — TCP/UDP port scanning used in §4.1 and §4.2; the nmap-mac-prefixes database ships with nmap and provides offline OUI lookup.
tshark (Wireshark CLI) — used for the traffic-rate/motion-correlation measurement in §5.1 and Vol 3 §5.4.
ffprobe (FFmpeg) — https://ffmpeg.org/ — the RTSP DESCRIBE probe in §4.1; ffprobe rtsp://<ip>/<path> returns SDP codec/resolution metadata.
maclookup.app — fast REST API for OUI lookups; free tier 2 req/s.

Academic research (camera localization and Wi-Fi detection)

LocCams — Wang et al., “LocCams: Detecting and Localizing Hidden Cameras with Smartphones via Wi-Fi Signals,” Proc. ACM IMWUT 2023. The research-grade RSSI fingerprinting + traffic-rate detection system that combines both localization and confirmation in a single passive pass. Explicitly scoped to transmitting cameras only.
CamLoPA — passive Wi-Fi traffic analysis for camera detection and coarse localization without joining the network. Spec-sourced; in the same research corpus as LocCams.
SpyDir — combines directional antenna sweeping with RSSI correlation and traffic-rate analysis. Transmitting cameras only. Spec-sourced.

The full academic lineage of traffic-rate/motion-correlation — including the VBR-encoder physics, the encrypted-traffic fingerprinting background, and the “Cheng et al. Your Wi-Fi Is Watching You” origin — is documented at Vol 3 §5.2. These papers are the foundation for both the RSSI-walk localization (§5) and the firmware algorithm in Vol 7 §6.

Hub tools and sibling volumes

ESP32 Marauder Firmware deep dive — the Wi-Fi promiscuous scan, OUI matching, and station-RSSI reporting capabilities of Marauder that make it the natural fork seed for the Vol 8 camera-finder build.
Nyan Box deep dive Vol 7 — documents the Nyan Box’s native hidden-camera detection feature with its 20+-brand fingerprint database; the most directly comparable existing implementation to what Vol 7 designs from scratch.
Vol 3 §5 (traffic-rate / motion-correlation) — the centerpiece technique that §4 and §5 of this volume operationalize. The stable anchor #5-traffic-rate-motion-correlation is cited throughout.
Vol 7 §6 (RSSI-walk localization firmware) — the ESP32-S3 implementation of the §5 algorithm; read Vol 5 §5 before Vol 7 §6.
Vol 12 §2–§3 (room-sweep playbook) — the full procedural integration of the techniques in this volume into a defensible multi-modality sweep.

Legal and ethics

The techniques in this volume — promiscuous Wi-Fi capture, OUI fingerprinting, RTSP probe, traffic-rate correlation, and RSSI-walk — are used in the context of counter-surveillance of a space you occupy: finding cameras someone else installed in a hotel room, Airbnb, or changing area. This is squarely defensive; the framing is consistent with the counter-surveillance posture established in Vol 1 §1 and documented in full at _shared/legal_ethics.md.

The deauth-confirm technique (Vol 3 §6) is not included in this volume’s operational procedures because it requires injecting management frames into a network, which is gated to consenting-environment use. Everything documented in this volume (passive promiscuous capture, active scanning of networks you have joined, RTSP probes to IPs on your subnet) is within the legal envelope of a normal network sweep in your own or your temporarily-occupied space — verify against your jurisdiction per _shared/legal_ethics.md.

This is Volume 5 of a fifteen-volume series. Next: Vol 6 covers the non-Wi-Fi camera deep dive — how to sweep for analog wireless cameras (1.2/2.4/5.8 GHz) using HackRF One or RTL-SDR, demodulate the FM-video carrier to see what the camera sees, handle cellular/4G cameras (the hard case), and work the wired-camera track (cable tracing, TDR, find-the-recorder, PoE/LAN detection). The RSSI-walk technique developed in §5 is implemented as firmware in Vol 7; the commercial detectors that implement Wi-Fi scanning for camera finding are surveyed in Vol 9.

CameraDetection Volume 5 — Wi-Fi / IP Camera Deep Dive