Series index · Previous: Wireless reliability · Next: Suspicious traffic
18 September 2026 · Official documentation source-checked; exercises have not been run on THL hardware. Baselines and results described here are proposed measurements, not claims about any product’s behavior.
Question: Which destinations does my device contact, when, and how much does it send? Outcome: A small inventory separating directly observed facts from privacy hypotheses.
Use this to troubleshoot traffic, check telemetry settings, and document dependencies. Misuse includes watching household members, inferring routines, or profiling colleagues. Limit the exercise to your own activity on your device or a specifically authorized test device. Owning the router does not settle consent to inspect everyone who uses it.
Choose a capture point that can answer the question
The easiest starting point is an app on the computer running Wireshark. For a separate IoT device, use an existing capture function on a gateway or an authorized mirrored port that actually carries that device’s traffic. A capture from another laptop on the same switched or wireless network usually cannot provide the device’s complete conversations. Do not add interception, impersonation, or radio monitoring to compensate for the wrong location. Wireshark capture setup
Record the device’s current IPv4 and IPv6 addresses from its settings or the gateway’s device list. Capture before address translation; a shared public address makes attribution difficult. If you cannot isolate the device, use an app on your computer instead.
Use a private capture folder. Close other apps: IP filtering identifies a device, not a process, so background services can appear. Generate test events yourself.
Build a repeatable baseline
-
Write down the app/device version, capture interface, addresses, test start time, and one harmless action such as opening a settings page or refreshing device status. Make a simple event log with “idle,” “action,” and “idle again.” Keep device conditions comparable between runs.
-
Open Capture → Options at the selected capture point. Set a capture filter covering the device’s addresses, such as
host 192.0.2.20 or host 2001:db8::20, replacing both examples. Include all active addresses. Capture two minutes idle, perform the action once, then capture two more minutes and stop. For a gateway’s built-in capture, use its documented controls and open the exported file with File → Open. -
Apply
ip.addr == 192.0.2.20 or ipv6.addr == 2001:db8::20, again substituting actual addresses. Open Statistics → Conversations, check Limit to display filter, and inspect the IPv4/IPv6 and TCP/UDP tabs. Record peer addresses, direction, bytes, and duration. The two endpoints in a conversation and the direction columns are more useful than a single total. Conversations window -
Add
and dnsaround a parenthesized device filter—for example(ip.addr == 192.0.2.20 or ipv6.addr == 2001:db8::20) and dns. Expand query names and response answers. Associate a name with an address only when the captured answer supports it. Cached answers, shared addresses, and DNS over HTTPS can prevent or weaken this association. Encrypted DNS hides the DNS message contents from an ordinary on-path observer. DNS fields, DNS over HTTPS specification -
Use the device filter with
and (tls.handshake.extensions_server_name or quic)to inspect available encrypted-connection metadata. Record a visible name as an observation, not proof of every service using that connection. ECH can conceal the intended server name; a visible outer name may identify shared infrastructure. TLS fields, ECH specification -
Open Statistics → I/O Graphs. Set one graph’s Display Filter to the device filter, choose Bytes for Y Axis, select a one-second interval, and turn Avg over Time off for totals per interval. Compare bursts with the event log. These counts include captured packet bytes, not just uploaded application content. Use the same settings in subsequent runs. I/O Graphs controls
-
Repeat with one optional telemetry setting changed through the device’s normal controls, if such a setting exists. Keep the action and duration the same, and restore your preferred setting afterward. Run another comparison if an automatic update or unrelated activity disrupted the test.
Write observations without inventing meaning
Use one row per destination or conversation:
| Evidence | Record |
|---|---|
| Identity | Peer IP, observed DNS/SNI name, or “name unavailable” |
| Timing | First/last packet and nearby logged action |
| Volume | Bytes in each direction and capture duration |
| Interpretation | Possible purpose, confidence, and alternative explanation |
“A 12 KB outgoing burst followed my refresh” is an observation. “The manufacturer uploaded my microphone recording” requires substantially different evidence. Metadata cannot reveal an encrypted payload’s contents or establish data retention. A recognizable cloud hostname does not establish which customer or application owns the exchange. Repeated timing can suggest a hypothesis, but correlation alone is insufficient.
For an owned test device using plaintext MQTT, mqtt may expose application fields. Treat any identifiers or messages as sensitive; missing decoded MQTT does not mean there is no telemetry, because it could use TLS or another protocol. MQTT fields
Mitigation and completion exercise
Disable unnecessary telemetry through supported controls, keep firmware current, and isolate devices where appropriate. Before blocking a destination, check whether it supports essential functions or updates; use a reversible change and retest. Retain only the evidence needed for the question.
Completion exercise: Inventory up to five observed destinations, give two observations tied to packet numbers or timestamps, and state one unresolved hypothesis. Explain the capture point’s blind spots and how you would verify the hypothesis using vendor documentation, your own application logs, or another consented test.