How to see what a device on your network connects to

Every answer to this tells you how to list the devices on your network. Fing, your router's app, the ISP's portal: they all show you that the TV is there. None of them shows you what the TV talks to, which is the question. For that you need a copy of the packets, taken somewhere the device's traffic passes, and then something to read them. This is how to get one from a device you cannot install anything on, what it will and will not tell you, and the step nobody mentions: turning the setting off and capturing again, to find out whether it did anything. WIRE reads the capture in your browser, with nothing uploaded, which matters because a capture of your home network is a record of your household.

Two different questions

"What is on my network" and "what is my TV connecting to" sound like the same question and are not. The first is answered by a scan, takes thirty seconds, and is where every article stops. The second needs the traffic itself.

It matters because the first question cannot detect anything you would actually want to know. A TV sending a screen capture to a content-recognition company every few seconds looks, to a device scanner, exactly like a TV.

Getting a capture off a device you do not control

Four ways, in the order of how likely you are to be able to use them.

1. Make your laptop the network the device joins. The most accessible route, and the one nobody suggests, because half the internet writes about capture tools and the other half writes about smart TVs.

   On a Mac, turn on Internet Sharing over Wi-Fi, join the TV to that network, and capture the bridge interface:

   sudo tcpdump -i bridge100 -w tv.pcap

   On Windows 10 or 11, start the mobile hotspot, join the device to it, and use pktmon, which has been built in since 2020 and needs nothing installed. It records to .etl and has a command to convert that to a capture file a reader can open; pktmon help will name it for your build, because it has changed.

2. Your router, if it can. OpenWrt, pfSense, OPNsense, AsusWRT-Merlin, MikroTik and Ubiquiti will all run a capture and hand you the file. Most firmware supplied by an ISP will not. Look for "packet capture", "diagnostics" or tcpdump; if it is not there, it is not hidden, and the first option is quicker than fighting it.
3. A Raspberry Pi in between. Bridge its two interfaces, put the device on one side and the network on the other, and capture the bridge. More setting up than the laptop, and more control: the device sees an ordinary network and nothing has to be changed on it.
4. A managed switch with port mirroring, if the device is wired and you happen to have one. Nothing to configure on either end.

Whichever you use, capture for long enough to be worth reading. Half an hour with the device doing what it normally does says far more than two minutes of it booting.

What a capture actually tells you in 2026

Almost everything is encrypted now, and people take that to mean a capture is useless. It is not, but you should know exactly what you are getting.

And that is usually enough. "This television contacts a content-recognition company every forty-five seconds, all day, including when nothing is playing" is the finding. Nobody needs the payload to have it.

Two things are closing even the names, and it is worth knowing which you are up against. Encrypted Client Hello hides the hostname in the TLS handshake. DNS over HTTPS hides the lookups, because the device resolves names through an encrypted connection your router never sees. With both in use you are left with IP addresses, which still tell you which company owns them, and that is frequently the whole answer.

Reading it

Open the file in WIRE. It lists the conversations, the names that were looked up, the server names from the TLS handshakes, and anything contacting the same place on a timer, which for a device phoning home is the line you are looking for. Here is a capture built to demonstrate this rather than taken off a real television:

One device, one destination, forty connections, one every forty-five seconds for the length of the capture. Nothing a person does looks like that. Pair it with the DNS query that resolved the address and you have both the name and the behaviour, and you did not need to decrypt anything.

One caveat that applies to this and to every other tool: the timer is measured between TCP connection starts, so a device beaconing over QUIC will not appear in that particular list. Its conversations and its names are still there.

The step everybody leaves out

Search for smart TV privacy and you will be told, correctly, to turn off automatic content recognition. Not one of those pages suggests checking whether it worked.

It is the only part of this that is genuinely simple:

1. Capture for half an hour with the setting as it is. Note who it contacts and how often.
2. Turn the setting off.
3. Capture for another half an hour, doing the same things.
4. Compare.

Either the connections stop, in which case the toggle does what it says and you know it, or they do not, in which case you have learned something that no privacy policy was going to tell you. This is the only way to find out, and it takes an afternoon.

Why this runs in your browser

A capture of your home network is a record of your household: which devices exist, when somebody is at home, what is on, when the children's tablet is in use. The usual advice (upload it to an analysis service) hands all of that to a company in order to find out which company your television is handing things to.

WIRE parses it in the tab and nothing leaves the device; once the page has loaded it works with the network switched off, which is a thing you can check. Alongside: BEACON does the timing analysis properly if you have a connection log rather than a capture, and how to spot beaconing explains what the numbers mean.