PiHole on RPi3B+ went from working to barely responsive

The 3B+ is a few weeks old, and only has PiHole on it. Everything is basically brand new. Here is df -h output:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        28G  3.3G   24G  13% /
devtmpfs        460M     0  460M   0% /dev
tmpfs           464M  7.7M  456M   2% /dev/shm
tmpfs           464M  6.3M  458M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           464M     0  464M   0% /sys/fs/cgroup
/dev/mmcblk0p6   68M   22M   47M  33% /boot
tmpfs            93M     0   93M   0% /run/user/1000
/dev/mmcblk0p5   30M  1.6M   27M   6% /media/pi/SETTINGS
tmpfs            93M     0   93M   0% /run/user/999

I also just checked, and Bluetooth and Wifi are both off (Bluetooth had been on, but I'm not using it, so I turned it off).

Should I be using Wifi or Wired for this application? I assumed Wired was best, correct?

That is on huge chunk of blocked domains ... I believe it does have something to do with the delays (on that particular hardware)...

For testing purposes, try restoring the default blocklists, update gravity and see how that goes...

https://discourse.pi-hole.net/t/how-can-i-restore-pi-holes-default-ad-lists/4683/3?u=ramset

I've disabled all of the other block lists.

Have discovered something interesting with the DHCP server now:
Devices will not get addresses automatically from DHCP, but if I manually configure the device to have the same IP as the reservation, then things tend to be fine. Still can't get anything to resolve through the PiHole in less than 30 seconds though, but gravity is still updating.

You can use a DHCP probe tool to request a lease from the DHCP server and dump the contents for analysis.

(this might work: GitHub - JohannesBuchner/DHCProbe: Send a DHCP request to DHCP server to check its configuration)

No rogue DHCP servers present ?

No rogue DHCP servers, I'll have to see how I can do that probe (this is already stretching my skillset and knowledge).

I figured that the PiHole DHCP solution would 'just work' but its been a lot of trouble. I suppose I can turn it off and go back to having the ORBI handle DHCP and I'll just live without granular device logging (which was really helpful to fine tune getting ads blocked and white lists correct).

It does :slight_smile: it's been serving DHCP leases (out of the box) in my home network for years now :slight_smile:

Most likely there are configuration issues there that prevent you form enjoying Pi-hole to it's fullest potential.

I still can't get the RPi to reliably respond to a ping, so I guess its no surprise that DHCP is failing.

In other news, looks like gravity failed to update because the PiHole can't update the lists. Any idea what would prevent PiHole itself from getting online now?

edit

/etc/resolv.conf

and change from 127.0.0.1 to 1.1.1.1.

Try again after that.

You can rename the existent adlists.list and create a new one with hose default links from the reply above.

Then run a pihole -g

Finally got a Debug Token after forcing a Gravity update:

https://tricorder.pi-hole.net/iifszdf97t!

I could not generate this from the RPi directly, since it could not get online, but I was able to connect from another machine on the network, which I have configured to use a regular DNS server, bypassing the PiHole.

Does that log help at all?

There seems to be a package available for dhcp probing.

sudo apt install dhcp-probe

here's the manual:

https://packages.debian.org/stretch/dhcp-probe

I'll check that out, thanks.

I suppose I need to figure out how to get more ads blocked without adding such a massive list. Still can't ping the Pi to get anything back, but at least it seems to be partially working.

The answer to that is Regex.

Consider it as a wildcard kind of blocking where any links containing your trigger word, like ad- or tracking and the such are blocked ...

There are several regex topics here that can get you going ... even regex generators online ...

Going back to this:

Mar 22 15:34:06 dnsmasq-dhcp[2003]: DHCPREQUEST(eth0) 192.168.1.42 00:11:d9:::**
Mar 22 15:34:06 dnsmasq-dhcp[2003]: DHCPACK(eth0) 192.168.1.42 00:11:d9:::** TIVO-8400301909DAC30

Looks like your TIVO requested a lease and it got one ...

Why? Are you seeing ads? If not, then you don't need more block lists. If so, perhaps a blacklist or regex entry will block that particular ad source.

Well said. I will watch how things work with the default list (when I was using the defaults I was getting a good amount of ads, but maybe I didn't stick with it long enough before adding 'more').

I think the regex topics are also a good idea.

How many domains are in gravity now?

wc -l /etc/pihole/gravity.list

wc -l /etc/pihole/adlists.list

wc -l /etc/pihole/gravity.list
112225 /etc/pihole/gravity.list

wc -l /etc/pihole/adlists.list
16 /etc/pihole/adlists.list

I disabled all but the couple of base lists per the instructions. I'm definitely getting better performance, but at the expense of some ads.

I would use these tools to determine the source of the ads and then block them as required:

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.