Packet Capture From My Philips TV
I recently bought a new TV for our house, a Philips 55PUS7009 4K LED Smart TV (“55 Inch Display with Pixel Precise Ultra HD Titan OS Platform and Dolby Atmos Sound, Works with Alexa and Google Voice Assistant”, according to Amazon). It's a decent modern TV, though its native platform is not Android, unfortunately; instead it’s “TitanOS”, a Linux-based Smart TV operating system.
After reading The Smart TV in Your Living Room Is a Node in the AI Scraping Economy, I thought it’d be a good plan to take a look at what’s going on in terms of network traffic from this device. My wifi AP is a GL-iNet MT-6000 , which runs their OpenWRT-based operating system, so gives easy access to developer-friendly features like full tcpdump support to examine a wireless client’s traffic. (scroll down to “Snooping Traffic For One Client In GL-MT6000” if you’re curious about this part.)
Another reason I wanted to do this was to disable mandatory updates; I don't want to risk something like this horror from LG. Despite disabling this in the TV’s UI, the most recent update (a couple of months ago) was accompanied by nagging dialog boxes every time someone turned on the TV, which is a really crappy piece of user experience, thanks Philips --- so I’d prefer if the TV had no idea that an update was available in the first place.
What The TV Sends
I power cycled the TV, waited for it to boot, then checked for software updates in the Settings menu. During this process, I ran a packet capture for all traffic escaping from the device. Here’s what it hit during the process, tcpdump interpreted with a little help from Claude:
Content / streaming apps (expected):
- Netflix — *.netflix.com, nrdp*.netflix.com, occ.a.nflxso.net, cdn-0.nflximg.com, tpv-*.prod.partner.netflix.net, and threeplr-*.api.amazonvideo.com (Netflix's Open Connect is partly fronted via Amazon)
- YouTube / Google — www.youtube.com, www.google.com, clients3.google.com (the last is Google's captive-portal/connectivity check)
- Apple — mediaservices.cdn-apple.com (AirPlay/trailer assets)
- download.airserver.com — AirServer mirroring; I may have installed this TitanOS app. Pretty much expected.
Platform / infrastructure (expected):
- NTP: 0.ie.pool.ntp.org, time.aws.com — clock sync, all fine
- app.titanos.tv, www.philips.com — TitanOS platform + vendor
- *.core.cloud.vewd.com — the Vewd browser engine TitanOS is built on
- ocsp.*.amazontrust.com — TLS certificate revocation checks
Telemetry / tracking (no thanks):
- platform.cid.samba.tv / preferences.cid.samba.tv - this is Samba TV ACR (Automatic Content Recognition). It fingerprints what's on screen, including HDMI inputs, for ad/analytics tracking purposes.
- dac-api-prod.tpv-analytics.com - TP Vision's analytics backend.
- metrics.core.cloud.vewd.com - browser-engine metrics.
- Netflix telemetry: ichnaea.netflix.com, customerevents.netflix.com - usage/event reporting, distinct from playback.
- ipinfo.io - IP geolocation lookup.
The streaming and platform traffic is normal, but one thing was a really nasty surprise; the set seems to support reporting to Samba TV ACR, with what looks like a remote switch to enable it. I do not want this "ACR" feature active, which essentially repeatedly screenshots your screen and reports it home to Samba TV servers; extremely invasive surveillance adware, if you ask me. There was no notification in the Philips setup docs, specification, or TV UI that this kind of crap was installed, which I find particularly unpleasant. Not cool, Philips.
There's also TP Vision analytics -- TP Vision is the company behind the "Philips" TV brand. I doubt these are as invasive as the "ACR" monitoring, but worth turning off too.
Most of the Platform and Telemetry DNS lookups were performed using my configured DNS server. However, Netflix resolves the following names using 8.8.8.8 directly:
api-global.netflix.com. cdn-0.nflximg.com. customerevents.netflix.com. ichnaea.netflix.com. nrdp-cell4.prod.ftl.netflix.com. nrdp.nccp.netflix.com. nrdp.prod.cloud.netflix.com. nrdp25.appboot.netflix.com. nrdp51-appboot.netflix.com. occ.a.nflxso.net. secure.netflix.com. uiboot.netflix.com.
Digging into “samba.tv”, which is my biggest source of unwanted traffic here: here's the full picture of what samba.tv did in that capture.
The device: the TV at 10.19.72.124, at power-on (all of this happens in a ~2-second burst at 20:40:23–25). DNS (via your Pi-hole, 10.19.72.11):
- preferences.cid.samba.tv -- resolves to CNAME -> flingo.tv -> 216.183.117.106 / .105
- platform.cid.samba.tv -- resolves to 216.183.117.91
Note the CNAME to flingo.tv — Flingo is the original company behind Samba TV's ACR ("automatic content recognition"). The IPs are all in Samba's own 216.183.117.0/24 block. Importantly, the TV had no hardcoded IP — it relied entirely on DNS (unlike Netflix, which went to 8.8.8.8). That's why the Pi-hole block will fully stop it.
The connections — two short-lived HTTPS sessions:
- 216.183.117.106:443 (preferences.cid.samba.tv): 22 packets, ~5.2 KB
- 216.183.117.91:443 (platform.cid.samba.tv): 22 packets, ~5.5 KB
- .105 was resolved but never contacted (redundant A-record).
Both follow an identical shape:
- TCP handshake, then a 518-byte TLS ClientHello (SNI platform./preferences.cid.samba.tv).
- Server returns ~3.3 KB — the *.cid.samba.tv certificate (issued by GoDaddy).
- TV sends ~1 KB of application data (seq 518 -> 1590/1695), server replies with a tiny (~150–300 byte) response.
- Immediate FIN/RST teardown.
Interpretation: This is a telemetry check-in, not a stream: two brief, one-shot encrypted POSTs at boot — the TV uploads ~1 KB to each endpoint (device identity + a "preferences"/config pull) and hangs up. The payload is TLS-encrypted so the contents are opaque, but the pattern — resolve / connect / upload ~1 KB / tiny reply / close, to hosts literally named platform and preferences under Samba's ACR domain — is most likely the ACR phone-home, not content delivery. Nothing large was exfiltrated in this capture; ACR's continuous "what's on screen" reporting would show up as repeated check-ins over time, which is what you'd catch with ongoing logging.
Given this, I think Pi-Hole blocking on *.samba.tv should block these check-ins and avoid future snooping.
In addition, blocking the following domains seems to ensure that software updates are blocked:
- app.titanos.tv, www.philips.com — TitanOS platform + vendor
- *.core.cloud.vewd.com — the Vewd browser engine TitanOS is built on
Full protocol/port breakdown for the TV
Analysing this lets us check for DoH/DoQ/DOH3/DoT name resolution evading the DNS blocks. Here’s what was happening across all TCP/UDP protocols, according to a Claude based analysis:
- TCP port 443 - destination external (known SNIs) --- HTTPS — the hosts we already enumerated
- TCP port 80 - destination external --- cleartext HTTP (ipinfo, Netflix appboot, OCSP)
- TCP port xxxxx ? 10.19.72.xx — LOCAL --- Plex and DLNA media server
- TCP port 56890 ? 10.19.72.115 — LOCAL --- TV set top box; no TLS, no hostnames
- UDP port 53 - destination Pi-hole + 8.8.8.8 --- plaintext DNS
- UDP port 123 - destination external --- NTP
- ICMP, IGMP traffic
Why this rules out each variant:
- DoQ / DoH3 (QUIC, always UDP): the only UDP that leaves the network is port 53 and 123. There is zero other UDP egress — no QUIC on any port, standard or not. Definitively ruled out.
- DoT (TLS on TCP, normally 853): the only nonstandard TCP ports (32469, 56890) both go to local LAN hosts (the Plex server and .115), never to the internet, and neither carries a TLS handshake to a resolver. The only WAN-bound TCP is 443 and 80. Ruled out.
- DoH (HTTPS on 443 — the hard one): DoH is deliberately indistinguishable from normal HTTPS, so a pcap can't prove its absence by port alone. But:
- SNI enumeration: every 443 ClientHello we pulled had a content/CDN/tracker hostname (google, netflix, apple, yahoo, youtube, samba, vewd, airserver, GoDaddy OCSP). None is a resolver (dns.google, cloudflare-dns.com, dns.quad9.net, etc.), and there was no 443 to 8.8.8.8/1.1.1.1/9.9.9.9.
So no encrypted DNS is escaping, on either standard or nonstandard ports. The TV's name resolution is 100% cleartext Do53.
One other thing that’s interesting there is the port 56890 TCP traffic to 10.19.72.115. This is the Virgin Media TV box I use to watch Virgin’s TV service; it’s intriguing that the TV opens a TCP connection immediately to this set top device. Here’s what Claude makes of it:
Port 56890 is DIAL / UPnP device discovery — the "cast to TV" mechanism — and it's entirely local LAN, nothing to do with DNS or phone-home. The TV (10.19.72.124) is the client here. It opens three short connections to 10.19.72.115:56890 and sends a plain-HTTP UPnP request:
GET /apps/dd.xml HTTP/1.1 HOST: 10.19.72.115:56890 USER-AGENT: Linux/6.1.124-..., UPnP/1.0, Portable SDK for UPnP devices/1.14.6
dd.xml is a UPnP device-description document, and the Portable SDK for UPnP devices/1.14.6 user-agent is the standard libupnp DIAL stack. The device at .115 answers with:
HTTP/1.1 200 OK Application-URL: http://10.19.72.115:8092/apps/ <- DIAL app-launch REST endpoint ... <deviceType>urn:schemas-upnp-org:device:tvdevice:1</deviceType> <friendlyName>360 Box</friendlyName> <manufacturer>360 Box</manufacturer> <modelName>EOS-1008R</modelName> <UDN>uuid:0f7902cd-efbf-4a81-aeae-d975bbf89bff</UDN>
This is DIAL (DIscovery And Launch) — the protocol behind "Cast" / second-screen app launching (YouTube, Netflix "play on TV", etc.). The tvdevice:1 type and the Application-URL pointing at :8092/apps/ are the DIAL signature. The TitanOS TV is scanning the LAN for cast targets, found a device advertising itself as "360 Box", model EOS-1008R at 10.19.72.115, and fetched its capability document to learn what apps it can launch and where (:8092). The dd.xml retrieval is the tiny handshake — 204-byte request, ~624-byte XML reply, then clean close. Three near-identical connections at 21:06:56 are just the discovery routine probing a couple of times.
It appears the Virgin set top box can be poked to launch a Netflix client, a Youtube client (which is currently disabled?), and that appears to be it; it has no remote-streaming capability using this protocol.
Snooping Traffic For One Client In GL-MT6000
Here's how I set this up, for future reference. Log into the GL-Inet admin UI, then click into LUCI, the OpenWRT GUI, using the "System" -> "Advanced Settings" link. Go to Network -> Wireless and add a new wireless network under your 5GHz wifi device. Give it a new ESSID (I used my normal SSID name, plus "IOT") and set its WPA key. You can choose “Isolate Clients”, which (I think) will ensure clients on this network can only talk to the external internet? (I’m not sure; I didn’t use it as my local LAN fileserver serves all sorts of content to the TV, so I left it off.)
Hit Save and enable the network.
Change the TV’s networking config to use this new SSID and it should connect to it, then showing up in the “Associated Stations” part of Network -> Wireless with a new device name; in my case, “rax1”. SSH to the AP and run:
# opkg update && opkg install tcpdump
You should now be able to use tcpdump to snoop packets on that interface, seeing only traffic to and from the client in question (10.19.72.124 being the TV in my case):
# tcpdump -ni rax1 -e tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on rax1, link-type EN10MB (Ethernet), capture size 262144 bytes 19:34:18.487777 IP 10.19.72.124.41837 > 10.19.72.11.53: 54382+ A? www.google.com. (32) 19:34:18.487787 IP 10.19.72.124.41837 > 10.19.72.11.53: 23073+ AAAA? www.google.com. (32) 19:34:18.490906 IP 10.19.72.11.53 > 10.19.72.124.41837: 54382 8/0/0 A 142.251.151.119, A 142.251.152.119, A 142.251.154.119, A 142.251.157.119, A 142.251.150.119, A 142.251.153.119, A 142.251.155.119, A 142.251.156.119 (160) 19:34:18.492935 IP 10.19.72.11.53 > 10.19.72.124.41837: 23073 8/0/0 AAAA 2001:4860:4826:7700::, AAAA 2001:4860:4828:7700::, AAAA 2001:4860:482a:7700::, AAAA 2001:4860:4829:7700::, AAAA 2001:4860:482c:7700::, AAAA 2001:4860:4827:7700::, AAAA 2001:4860:482d:7700::, AAAA 2001:4860:482b:7700:: (256)
And for deeper examination, write a pcap file:
# opkg install openssh-sftp-server # tcpdump -ni rax1 -w /tmp/iot.pcap -C 50 -W 5 tcpdump: listening on rax1, link-type EN10MB (Ethernet), capture size 262144 bytes ^C6486 packets captured 6487 packets received by filter 0 packets dropped by kernel
You can now scp that /tmp/iot.pcap file to your local machine for full analysis. (Claude is really good at this part.)
I really recommend the GL-iNet GL-MT6000 as an AP or router BTW. OpenWRT is just a fantastic operating system for these devices, full of developer accessibility, scriptability, automation, and room for cool hacks, and GL-iNet did a good job in building a reliable, solid consumer product on top of it.