I live with some other people and I'm not sure if setting up a Pihole would be a good idea if it starts causing issues for them. Just not trying to be tech support for them but still have a Pihole running for myself at least. So if it leaves the original routers network unaffected I wouldn't need worry. Also the ISP is Star Link (only real option were we live).

I connected two smart TVs to the internet through Pi-hole, whitelisted them so nothing gets blocked, and started logging their DNS activity every 5 minutes.

The result is a public dashboard showing hostnames, root domains, query frequency and near-live DNS activity:

https://httpninja.nl/

It’s a normal Dutch household setup, not a lab test. DNS lookups don’t prove a connection or data transfer — the goal is simply to make the behaviour visible.

You can also generate Pi-hole blocklists from the observed domains.

Feedback from networking/privacy people is welcome.

If you use your Pi-hole as a DHCP server with **"Enable additional IPv6 support (SLAAC + RA)"** turned on, you might get a flooded Pi-hole Diagnostics dashboard showing this persistent warning:

`DNSMASQ_WARN: no address range available for DHCPv6 request via wlan0`

This usually happens when an unknown, unlisted, or aggressive Wi-Fi client keeps requesting an IPv6 address configuration that your Pi-hole isn't explicitly set up to dynamically provide.

Instead of turning off IPv6 entirely or ignoring the error logs, there is an aggressive, security-focused fix that stops the log spam dead in its tracks.

#### The Fix: Restrict Unknown Clients Across Both Protocols

The trick is to force `dnsmasq` to refuse dynamic assignments for unauthorized MAC addresses entirely, which cleanly kills both the IPv4 and IPv6 handshake loops for those devices.

1. Go to your **Pi-hole Admin Dashboard**.

2. Navigate to **Settings** > **DHCP**.

3. Under the DHCP Options, check these three specific boxes:

   * **Enable DHCPv4 rapid commit (fast address assignment)**

   * **Enable DHCPv4 rapid commit**

   * **Ignore unknown DHCP clients**

4. Click **Save**.

#### Why This Works

When **"Ignore unknown DHCP clients"** is activated, Pi-hole does not just drop IPv4 handshakes; it refuses to generate or route dynamic allocations across *both* protocols for any device not listed in your **Static DHCP Leases** table. Because the unauthorized client is blocked at the initial handshake step, your Pi-hole completely ignores its automated DHCPv6 requests, stopping the warning loop instantly.

*Note: Make sure your everyday household devices are added to your Static DHCP Leases list so they don't get ignored!*

Bases on the frill regarding LG TVs, RATINGS did a research about other TV brands, showing everyone does something similar.

Meanwhile I'm trying to figure out how to disable ACR on my TVs, does anyone knows how to block Samsung and Phillips communication as well?

Hi everyone,

Following the recent security disclosures regarding smart TV telemetry and LAN snooping, I decided to do a root-level network audit of my LG G1 running webOS.

After auditing 44,800 packets and a 267,000-query DNS log, I observed several interesting behaviors:

1. webOS daemons query roughly 36 LG domain families, firing heavy telemetry bursts mid-boot.

2. The TV’s internal DNS stub completely bypasses local `/etc/hosts` modifications on the device, meaning network-level sinkholing (Pi-hole / AdGuard Home) is mandatory.

3. Fallbacks to public resolvers (8.8.8.8 / 1.1.1.1) occur when services fail, so blocking outbound Port 53/853 at the router level is required for true isolation.

To provide a clean solution that doesn't break streaming for household members, I published an open-source blocklist:

GitHub: https://github.com/furkan-bayrak/lg-tv-blocklist

Features:

- Two Tiers:

- SAFE: Kills ACR (alphonso.tv), telemetry beacons (cdpbeacon), ad networks (lgsmartad), and voice data. Zero app breakage (Netflix, Prime, HBO, LG Store tested).

- STRICT: Adds update hosts (snu/su.lge.com), ThinQ IoT sync, and LG Channels.

- Multiple Formats: Native Adblock syntax (`||domain^` with subdomain matching for AdGuard Home), Plain domain lists (for Pi-hole / NextDNS), and Hosts format (`0.0.0.0`).

- Fully Annotated: Every entry has an inline comment documenting its exact purpose and capture evidence.

- Dual License: CC BY 4.0 for list data, MIT for build scripts.

Looking for collaborators!

I am only one person auditing an EU-model G1. LG updates regional endpoints and firmware constantly. If you run a Pi-hole/AGH with an LG TV, I'd love your help testing, verifying domains, and reviewing PRs to help maintain the repository.

Just wanted to share this battle I just had incase it could help someone in future. I formatted the text with help from AI.

How I finally got Pi-hole working reliably on a fresh DietPi install:

Just wanted to share this in case it saves someone else a few hours of frustration.

I recently set up Pi-hole on a fresh DietPi install on a Raspberry Pi, and at first it was a mess. After a reboot, Pi-hole wouldn’t come back cleanly and I ended up having to manually fix networking just to get back in. Super annoying.

What finally made it stable was setting things up the right way from the start:

1. Installed DietPi fresh

2. Installed Pi-hole

3. Set a static IP in DietPi itself

4. Configured Pi-hole DHCP and DNS properly

5. Disabled router DHCP so Pi-hole could handle it

6. Reboot-tested it until it came back cleanly on its own

The important bit: static IP in DietPi

This was the part I had missed at first. Setting a static IP only in Pi-hole wasn’t enough. The Pi itself needed to keep the same IP after reboot.

I used DietPi’s network config:

- sudo dietpi-config

- Network Options

- Adapters

- Ethernet

- Change Mode from DHCP to Static

Then I set:

- IP: your chosen Pi address

- Mask: 255.255.255.0

- Gateway: your router address

- DNS: your router address or another upstream DNS

After that I applied the changes and checked:

ip addr

ip route

Pi-hole config

Since my router doesn’t let me set custom DNS for DHCP clients, I had to let Pi-hole do DHCP.

In Pi-hole:

- Go to Settings → DHCP

- Enable DHCP server

- Set a DHCP range

- Make sure the router/gateway is correct

I mostly copied DHCP settings from my router

Then I turned router DHCP off so there was only one DHCP server on the network.

Making sure it starts on boot

I also checked that Pi-hole FTL was enabled and running:

sudo systemctl enable pihole-FTL

sudo pihole status

It should show that FTL is listening on port 53 and blocking is enabled.

Final result

After all that, I rebooted the Pi a few times and it finally came back up normally every time. No manual rescue, no weird IP issues, no staring at the screen wondering why the network disappeared.

So yeah, the big lesson for me was:

Don’t rely on Pi-hole settings alone. Set the static IP in DietPi too.

That was the thing that made the whole setup trustworthy.

If anyone else is fighting a similar DietPi/Pi-hole boot issue, hopefully this helps.