What is your preferred Ad Blocking Strategy?

I've searched:
It seems to be easy to do with Windows but I cannot, for the life of me, find how to do it in Linux, much less OpenWrt.

I have a birthday this year; I'd love someone to find instructions for me!! :smile:

It is USB2 so expect more like 100Mbit.

This is great. I pihole in this fashion :

I am dead serious.

But I'm not saying that every single packet will be lost, just that there is more packet loss for a wireless transmission than there is for a wired one.

I am very frequently accessing wirelessly connected systems via ssh (or ssh -X, x2go, RDP) in my WLAN, distance for the purpose of this argument ~1.5-3 metres (same room), with a variety of high-end/ 'good' WLAN cards involved (be200, ax210, ax201, ax200, mt7921, mt7921k, mt7921au, as well as some older stuff, AR5007EG, AR5008, AR9285, RTL8192DU, RTL8192SU, RTL8188SU, rt61, rt73, rt2570, rt2860, rt2870, ar9170, ar9271, ipw2200, bcm4306/3, bcm4318, ti wl1721, rtl8187b, rtl8180l, rtl8185 and another 25+ legacy WLAN cards (down to 802.11b) if I have to, as well as modern stuff like esp8285, esp32-s3, esp32-c3, esp32-c6, …). Often it works just fine, but quite often I see various small issues - it still generally works, but there is some packet loss and delays (as well as a visible delay between hitting a key and seeing it on the other end over the ssh session). …and no, that isn't the fault of my AP either, as I used varying different devices and chipsets (including their corresponding OEM firmwares) for that (in recent times from 802.11n to 802.11be (2.4, 5 and 6 GHz), using SOCs from QCA/Atheros, Mediatek and Broadcom). Don't get me wrong, it works, it's good enough for many purposes, but given the number of external references in a common web pages (easily in the hundreds), you want DNS to reply via the most reliable and instant medium possible, which is not WLAN.

2 Likes

Honestly, I figured you, if anyone, could show packet loss and latency at a distance a wired DNS server might induce.

You do not need/have to post your credentials.
I just challenged a, very educated (on your part), presumption.

:spiral_notepad:Okay, I see it was not an eloquent challenge.

rtl8125 <--> QCA8084 <--> qcn6214 <--> be200, 6 GHz, ~1.2m distance

$ ping -4nc100 be200
PING be200.xxx.xxx.xx (172.22.50.1) 56(84) bytes of data.
64 bytes from 172.22.50.1: icmp_seq=1 ttl=64 time=54.6 ms
64 bytes from 172.22.50.1: icmp_seq=2 ttl=64 time=3.86 ms
64 bytes from 172.22.50.1: icmp_seq=3 ttl=64 time=4.44 ms
64 bytes from 172.22.50.1: icmp_seq=4 ttl=64 time=3.56 ms
64 bytes from 172.22.50.1: icmp_seq=5 ttl=64 time=3.79 ms
64 bytes from 172.22.50.1: icmp_seq=6 ttl=64 time=3.61 ms
64 bytes from 172.22.50.1: icmp_seq=7 ttl=64 time=197 ms
64 bytes from 172.22.50.1: icmp_seq=8 ttl=64 time=112 ms
64 bytes from 172.22.50.1: icmp_seq=9 ttl=64 time=32.4 ms
64 bytes from 172.22.50.1: icmp_seq=10 ttl=64 time=55.7 ms
64 bytes from 172.22.50.1: icmp_seq=11 ttl=64 time=78.9 ms
64 bytes from 172.22.50.1: icmp_seq=12 ttl=64 time=104 ms
64 bytes from 172.22.50.1: icmp_seq=13 ttl=64 time=23.9 ms
64 bytes from 172.22.50.1: icmp_seq=14 ttl=64 time=46.6 ms
64 bytes from 172.22.50.1: icmp_seq=15 ttl=64 time=69.3 ms
64 bytes from 172.22.50.1: icmp_seq=16 ttl=64 time=90.9 ms
64 bytes from 172.22.50.1: icmp_seq=17 ttl=64 time=112 ms
64 bytes from 172.22.50.1: icmp_seq=18 ttl=64 time=33.3 ms
64 bytes from 172.22.50.1: icmp_seq=19 ttl=64 time=58.0 ms
64 bytes from 172.22.50.1: icmp_seq=20 ttl=64 time=79.2 ms
64 bytes from 172.22.50.1: icmp_seq=21 ttl=64 time=102 ms
64 bytes from 172.22.50.1: icmp_seq=22 ttl=64 time=22.1 ms
64 bytes from 172.22.50.1: icmp_seq=23 ttl=64 time=45.5 ms
64 bytes from 172.22.50.1: icmp_seq=24 ttl=64 time=69.4 ms
64 bytes from 172.22.50.1: icmp_seq=25 ttl=64 time=91.0 ms
64 bytes from 172.22.50.1: icmp_seq=26 ttl=64 time=116 ms
64 bytes from 172.22.50.1: icmp_seq=27 ttl=64 time=36.4 ms
64 bytes from 172.22.50.1: icmp_seq=28 ttl=64 time=59.2 ms
64 bytes from 172.22.50.1: icmp_seq=29 ttl=64 time=82.6 ms
64 bytes from 172.22.50.1: icmp_seq=30 ttl=64 time=103 ms
64 bytes from 172.22.50.1: icmp_seq=31 ttl=64 time=24.6 ms
64 bytes from 172.22.50.1: icmp_seq=32 ttl=64 time=47.5 ms
64 bytes from 172.22.50.1: icmp_seq=33 ttl=64 time=69.7 ms
64 bytes from 172.22.50.1: icmp_seq=34 ttl=64 time=92.1 ms
64 bytes from 172.22.50.1: icmp_seq=35 ttl=64 time=13.8 ms
64 bytes from 172.22.50.1: icmp_seq=36 ttl=64 time=35.7 ms
64 bytes from 172.22.50.1: icmp_seq=37 ttl=64 time=161 ms
64 bytes from 172.22.50.1: icmp_seq=38 ttl=64 time=80.8 ms
64 bytes from 172.22.50.1: icmp_seq=39 ttl=64 time=103 ms
64 bytes from 172.22.50.1: icmp_seq=40 ttl=64 time=23.3 ms
64 bytes from 172.22.50.1: icmp_seq=41 ttl=64 time=47.3 ms
64 bytes from 172.22.50.1: icmp_seq=42 ttl=64 time=69.8 ms
64 bytes from 172.22.50.1: icmp_seq=43 ttl=64 time=194 ms
64 bytes from 172.22.50.1: icmp_seq=44 ttl=64 time=115 ms
64 bytes from 172.22.50.1: icmp_seq=45 ttl=64 time=37.4 ms
64 bytes from 172.22.50.1: icmp_seq=46 ttl=64 time=59.9 ms
64 bytes from 172.22.50.1: icmp_seq=47 ttl=64 time=81.9 ms
64 bytes from 172.22.50.1: icmp_seq=48 ttl=64 time=106 ms
64 bytes from 172.22.50.1: icmp_seq=49 ttl=64 time=132 ms
64 bytes from 172.22.50.1: icmp_seq=50 ttl=64 time=48.9 ms
64 bytes from 172.22.50.1: icmp_seq=51 ttl=64 time=70.6 ms
64 bytes from 172.22.50.1: icmp_seq=52 ttl=64 time=94.7 ms
64 bytes from 172.22.50.1: icmp_seq=53 ttl=64 time=13.5 ms
64 bytes from 172.22.50.1: icmp_seq=54 ttl=64 time=37.6 ms
64 bytes from 172.22.50.1: icmp_seq=55 ttl=64 time=59.7 ms
64 bytes from 172.22.50.1: icmp_seq=56 ttl=64 time=81.6 ms
64 bytes from 172.22.50.1: icmp_seq=57 ttl=64 time=104 ms
64 bytes from 172.22.50.1: icmp_seq=58 ttl=64 time=24.1 ms
64 bytes from 172.22.50.1: icmp_seq=59 ttl=64 time=49.6 ms
64 bytes from 172.22.50.1: icmp_seq=60 ttl=64 time=70.4 ms
64 bytes from 172.22.50.1: icmp_seq=61 ttl=64 time=94.3 ms
64 bytes from 172.22.50.1: icmp_seq=62 ttl=64 time=115 ms
64 bytes from 172.22.50.1: icmp_seq=63 ttl=64 time=35.2 ms
64 bytes from 172.22.50.1: icmp_seq=64 ttl=64 time=58.9 ms
64 bytes from 172.22.50.1: icmp_seq=65 ttl=64 time=80.9 ms
64 bytes from 172.22.50.1: icmp_seq=66 ttl=64 time=104 ms
64 bytes from 172.22.50.1: icmp_seq=67 ttl=64 time=23.0 ms
64 bytes from 172.22.50.1: icmp_seq=68 ttl=64 time=45.0 ms
64 bytes from 172.22.50.1: icmp_seq=69 ttl=64 time=68.8 ms
64 bytes from 172.22.50.1: icmp_seq=70 ttl=64 time=91.0 ms
64 bytes from 172.22.50.1: icmp_seq=71 ttl=64 time=96.2 ms
64 bytes from 172.22.50.1: icmp_seq=72 ttl=64 time=35.3 ms
64 bytes from 172.22.50.1: icmp_seq=73 ttl=64 time=56.6 ms
64 bytes from 172.22.50.1: icmp_seq=74 ttl=64 time=80.4 ms
64 bytes from 172.22.50.1: icmp_seq=75 ttl=64 time=103 ms
64 bytes from 172.22.50.1: icmp_seq=76 ttl=64 time=22.1 ms
64 bytes from 172.22.50.1: icmp_seq=77 ttl=64 time=46.7 ms
64 bytes from 172.22.50.1: icmp_seq=78 ttl=64 time=66.8 ms
64 bytes from 172.22.50.1: icmp_seq=79 ttl=64 time=90.5 ms
64 bytes from 172.22.50.1: icmp_seq=80 ttl=64 time=112 ms
64 bytes from 172.22.50.1: icmp_seq=81 ttl=64 time=33.6 ms
64 bytes from 172.22.50.1: icmp_seq=82 ttl=64 time=55.1 ms
64 bytes from 172.22.50.1: icmp_seq=83 ttl=64 time=79.5 ms
64 bytes from 172.22.50.1: icmp_seq=84 ttl=64 time=102 ms
64 bytes from 172.22.50.1: icmp_seq=85 ttl=64 time=22.6 ms
64 bytes from 172.22.50.1: icmp_seq=86 ttl=64 time=44.8 ms
64 bytes from 172.22.50.1: icmp_seq=87 ttl=64 time=66.3 ms
64 bytes from 172.22.50.1: icmp_seq=88 ttl=64 time=89.2 ms
64 bytes from 172.22.50.1: icmp_seq=89 ttl=64 time=114 ms
64 bytes from 172.22.50.1: icmp_seq=90 ttl=64 time=33.3 ms
64 bytes from 172.22.50.1: icmp_seq=91 ttl=64 time=56.1 ms
64 bytes from 172.22.50.1: icmp_seq=92 ttl=64 time=77.9 ms
64 bytes from 172.22.50.1: icmp_seq=93 ttl=64 time=2.46 ms
64 bytes from 172.22.50.1: icmp_seq=94 ttl=64 time=20.7 ms
64 bytes from 172.22.50.1: icmp_seq=95 ttl=64 time=44.3 ms
64 bytes from 172.22.50.1: icmp_seq=96 ttl=64 time=66.0 ms
64 bytes from 172.22.50.1: icmp_seq=97 ttl=64 time=89.8 ms
64 bytes from 172.22.50.1: icmp_seq=98 ttl=64 time=8.33 ms
64 bytes from 172.22.50.1: icmp_seq=99 ttl=64 time=31.0 ms
64 bytes from 172.22.50.1: icmp_seq=100 ttl=64 time=54.2 ms

--- be200.xxx.xxx.xx ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99123ms
rtt min/avg/max/mdev = 2.461/65.613/196.541/38.586 ms

vs.

rtl8125 <--> QCA8084 <--> rtl8125, distance 2m+QCA8084+3m

$ ping -4nc100 xxx
PING xxx (172.21.28.1) 56(84) bytes of data.
64 bytes from 172.21.28.1: icmp_seq=1 ttl=64 time=0.922 ms
64 bytes from 172.21.28.1: icmp_seq=2 ttl=64 time=0.916 ms
64 bytes from 172.21.28.1: icmp_seq=3 ttl=64 time=0.868 ms
64 bytes from 172.21.28.1: icmp_seq=4 ttl=64 time=0.785 ms
64 bytes from 172.21.28.1: icmp_seq=5 ttl=64 time=0.981 ms
64 bytes from 172.21.28.1: icmp_seq=6 ttl=64 time=0.980 ms
64 bytes from 172.21.28.1: icmp_seq=7 ttl=64 time=0.917 ms
64 bytes from 172.21.28.1: icmp_seq=8 ttl=64 time=0.914 ms
64 bytes from 172.21.28.1: icmp_seq=9 ttl=64 time=0.915 ms
64 bytes from 172.21.28.1: icmp_seq=10 ttl=64 time=0.903 ms
64 bytes from 172.21.28.1: icmp_seq=11 ttl=64 time=0.887 ms
64 bytes from 172.21.28.1: icmp_seq=12 ttl=64 time=0.907 ms
64 bytes from 172.21.28.1: icmp_seq=13 ttl=64 time=0.932 ms
64 bytes from 172.21.28.1: icmp_seq=14 ttl=64 time=0.962 ms
64 bytes from 172.21.28.1: icmp_seq=15 ttl=64 time=0.921 ms
64 bytes from 172.21.28.1: icmp_seq=16 ttl=64 time=0.944 ms
64 bytes from 172.21.28.1: icmp_seq=17 ttl=64 time=0.942 ms
64 bytes from 172.21.28.1: icmp_seq=18 ttl=64 time=0.931 ms
64 bytes from 172.21.28.1: icmp_seq=19 ttl=64 time=0.968 ms
64 bytes from 172.21.28.1: icmp_seq=20 ttl=64 time=0.949 ms
64 bytes from 172.21.28.1: icmp_seq=21 ttl=64 time=0.952 ms
64 bytes from 172.21.28.1: icmp_seq=22 ttl=64 time=0.885 ms
64 bytes from 172.21.28.1: icmp_seq=23 ttl=64 time=0.917 ms
64 bytes from 172.21.28.1: icmp_seq=24 ttl=64 time=0.861 ms
64 bytes from 172.21.28.1: icmp_seq=25 ttl=64 time=0.935 ms
64 bytes from 172.21.28.1: icmp_seq=26 ttl=64 time=0.919 ms
64 bytes from 172.21.28.1: icmp_seq=27 ttl=64 time=0.917 ms
64 bytes from 172.21.28.1: icmp_seq=28 ttl=64 time=0.933 ms
64 bytes from 172.21.28.1: icmp_seq=29 ttl=64 time=0.922 ms
64 bytes from 172.21.28.1: icmp_seq=30 ttl=64 time=0.932 ms
64 bytes from 172.21.28.1: icmp_seq=31 ttl=64 time=0.894 ms
64 bytes from 172.21.28.1: icmp_seq=32 ttl=64 time=0.921 ms
64 bytes from 172.21.28.1: icmp_seq=33 ttl=64 time=0.924 ms
64 bytes from 172.21.28.1: icmp_seq=34 ttl=64 time=0.927 ms
64 bytes from 172.21.28.1: icmp_seq=35 ttl=64 time=0.863 ms
64 bytes from 172.21.28.1: icmp_seq=36 ttl=64 time=0.911 ms
64 bytes from 172.21.28.1: icmp_seq=37 ttl=64 time=0.884 ms
64 bytes from 172.21.28.1: icmp_seq=38 ttl=64 time=0.802 ms
64 bytes from 172.21.28.1: icmp_seq=39 ttl=64 time=0.931 ms
64 bytes from 172.21.28.1: icmp_seq=40 ttl=64 time=0.890 ms
64 bytes from 172.21.28.1: icmp_seq=41 ttl=64 time=0.944 ms
64 bytes from 172.21.28.1: icmp_seq=42 ttl=64 time=0.849 ms
64 bytes from 172.21.28.1: icmp_seq=43 ttl=64 time=0.921 ms
64 bytes from 172.21.28.1: icmp_seq=44 ttl=64 time=0.881 ms
64 bytes from 172.21.28.1: icmp_seq=45 ttl=64 time=0.910 ms
64 bytes from 172.21.28.1: icmp_seq=46 ttl=64 time=0.948 ms
64 bytes from 172.21.28.1: icmp_seq=47 ttl=64 time=0.953 ms
64 bytes from 172.21.28.1: icmp_seq=48 ttl=64 time=0.993 ms
64 bytes from 172.21.28.1: icmp_seq=49 ttl=64 time=0.825 ms
64 bytes from 172.21.28.1: icmp_seq=50 ttl=64 time=0.930 ms
64 bytes from 172.21.28.1: icmp_seq=51 ttl=64 time=0.774 ms
64 bytes from 172.21.28.1: icmp_seq=52 ttl=64 time=0.934 ms
64 bytes from 172.21.28.1: icmp_seq=53 ttl=64 time=0.956 ms
64 bytes from 172.21.28.1: icmp_seq=54 ttl=64 time=0.860 ms
64 bytes from 172.21.28.1: icmp_seq=55 ttl=64 time=0.972 ms
64 bytes from 172.21.28.1: icmp_seq=56 ttl=64 time=0.743 ms
64 bytes from 172.21.28.1: icmp_seq=57 ttl=64 time=0.836 ms
64 bytes from 172.21.28.1: icmp_seq=58 ttl=64 time=0.952 ms
64 bytes from 172.21.28.1: icmp_seq=59 ttl=64 time=0.942 ms
64 bytes from 172.21.28.1: icmp_seq=60 ttl=64 time=1.27 ms
64 bytes from 172.21.28.1: icmp_seq=61 ttl=64 time=0.871 ms
64 bytes from 172.21.28.1: icmp_seq=62 ttl=64 time=0.895 ms
64 bytes from 172.21.28.1: icmp_seq=63 ttl=64 time=0.906 ms
64 bytes from 172.21.28.1: icmp_seq=64 ttl=64 time=0.916 ms
64 bytes from 172.21.28.1: icmp_seq=65 ttl=64 time=0.894 ms
64 bytes from 172.21.28.1: icmp_seq=66 ttl=64 time=0.883 ms
64 bytes from 172.21.28.1: icmp_seq=67 ttl=64 time=0.845 ms
64 bytes from 172.21.28.1: icmp_seq=68 ttl=64 time=0.951 ms
64 bytes from 172.21.28.1: icmp_seq=69 ttl=64 time=0.678 ms
64 bytes from 172.21.28.1: icmp_seq=70 ttl=64 time=0.865 ms
64 bytes from 172.21.28.1: icmp_seq=71 ttl=64 time=0.874 ms
64 bytes from 172.21.28.1: icmp_seq=72 ttl=64 time=0.834 ms
64 bytes from 172.21.28.1: icmp_seq=73 ttl=64 time=0.855 ms
64 bytes from 172.21.28.1: icmp_seq=74 ttl=64 time=0.915 ms
64 bytes from 172.21.28.1: icmp_seq=75 ttl=64 time=0.963 ms
64 bytes from 172.21.28.1: icmp_seq=76 ttl=64 time=0.972 ms
64 bytes from 172.21.28.1: icmp_seq=77 ttl=64 time=0.940 ms
64 bytes from 172.21.28.1: icmp_seq=78 ttl=64 time=0.970 ms
64 bytes from 172.21.28.1: icmp_seq=79 ttl=64 time=0.918 ms
64 bytes from 172.21.28.1: icmp_seq=80 ttl=64 time=0.859 ms
64 bytes from 172.21.28.1: icmp_seq=81 ttl=64 time=0.873 ms
64 bytes from 172.21.28.1: icmp_seq=82 ttl=64 time=0.897 ms
64 bytes from 172.21.28.1: icmp_seq=83 ttl=64 time=0.909 ms
64 bytes from 172.21.28.1: icmp_seq=84 ttl=64 time=0.907 ms
64 bytes from 172.21.28.1: icmp_seq=85 ttl=64 time=0.897 ms
64 bytes from 172.21.28.1: icmp_seq=86 ttl=64 time=0.945 ms
64 bytes from 172.21.28.1: icmp_seq=87 ttl=64 time=0.897 ms
64 bytes from 172.21.28.1: icmp_seq=88 ttl=64 time=0.937 ms
64 bytes from 172.21.28.1: icmp_seq=89 ttl=64 time=0.871 ms
64 bytes from 172.21.28.1: icmp_seq=90 ttl=64 time=0.947 ms
64 bytes from 172.21.28.1: icmp_seq=91 ttl=64 time=0.938 ms
64 bytes from 172.21.28.1: icmp_seq=92 ttl=64 time=0.801 ms
64 bytes from 172.21.28.1: icmp_seq=93 ttl=64 time=0.886 ms
64 bytes from 172.21.28.1: icmp_seq=94 ttl=64 time=0.887 ms
64 bytes from 172.21.28.1: icmp_seq=95 ttl=64 time=0.729 ms
64 bytes from 172.21.28.1: icmp_seq=96 ttl=64 time=0.958 ms
64 bytes from 172.21.28.1: icmp_seq=97 ttl=64 time=0.927 ms
64 bytes from 172.21.28.1: icmp_seq=98 ttl=64 time=0.933 ms
64 bytes from 172.21.28.1: icmp_seq=99 ttl=64 time=0.941 ms
64 bytes from 172.21.28.1: icmp_seq=100 ttl=64 time=0.917 ms

--- xxx ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 100165ms
rtt min/avg/max/mdev = 0.678/0.907/1.268/0.065 ms

q.e.d.

1 Like

Okay...

I deserved q.e.d.

Even if I take a look at more consistent results, using mt7921 at a distance of ~3m over 5 GHz as remote peer:

--- mt7921.xxx.xxx.xx ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99133ms
rtt min/avg/max/mdev = 2.494/5.870/75.054/7.008 ms

or qcn6214 over 5+6 GHz and ~6m:

--- xxx.xxx.xxx.xx ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99103ms
rtt min/avg/max/mdev = 2.671/4.675/5.960/0.477 ms

Even that is almost 6 times slower than using a wire.

but if you claim be200 drivers would still not be any good, let's take the more seasoned ax210 over 6 GHz as counter example:

--- ax210.xxx.xxx.xx ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99130ms
rtt min/avg/max/mdev = 12.999/63.382/210.073/32.844 ms

…again, rather big variances and some rather noticable delays.

Keep in mind, WLAN is -by design- suspect to interference, walls - and power saving. Which is why I avoided pinging mobile devices here, but hey, let's take a look at that (phone, 802.11ax, 5 GHz, distance ~1m, I am waking up the phone inbetween, which does help a bit, but not that much):

--- xxx.xxx.xxx.xx ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99048ms
rtt min/avg/max/mdev = 2.516/233.826/416.424/115.538 ms

or an esp32-c6, 2.4 GHz/ 802.11ax and ~1.5m distance:

--- esp32-c6.xxx.xxx.xx ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99117ms
rtt min/avg/max/mdev = 26.337/80.440/329.050/40.193 ms
2 Likes

I know I'm old and playing C-S is not getting any easier (but I can hold, at least, a 1:1 kill ratio and I'm not mentioning gaming other than) I would totally notice 99048ms loading pages.

or, at least: gawd I hope so.
But I use Unbound and, maybe, that is why I get imperceptible (to my geriatric brain) look-ups.

I think this is all on topic and pertinent.

DNS queries are (hopefully, in a modern browser) not not happening in a series, waiting for the previous one to come back, but in parallel during the site rendering (even ignoring partial rendering of the visible chunks of the page).

Again, WLAN 'works', well enough for me not always plugging in a cable whenever possible - but there is a tangible difference, and even one I can notice over a (only text based-) ssh session (and I do use that -very- frequently, as well as various types of SIP, remote desktop and other interactive uses via ethernet and WLAN).

1 Like

Well there must be some priority in the website code because I see ads first when my blocks are off.

Don't you?

I'll look further into USB to Ethernet emulation. Maybe I'll even buy an USB 2 Ethernet dongle.
I do love my Pi-hole.

Websites do prioritize site loading, but rendering is still happening as much in parallel as possible (and not waiting for everything to be received in order, that's why you see content jumping around).

2 Likes

The Pi Zero 2W probably has the appropriate hardware to run Pi-hole, but Gigabit ethernet is only supported on Pi 4 and 5, which I think are overkill for the job.

What I am totally struggling with to understand in the first place is why I need a Pi-hole in my network.

OpenWRT can handle my DNS, encrypt it and is able to block ads and malicious domains. Everything nice and easy without the overhead of another device in my network that needs my attention.

So what exactly is the benefit of running a Pi-hole that my OpenWRT router is not able to handle?

2 Likes

The concept of PiHole is the ease of installation and use. If you can reproduce the funtionality with the dnsmasq config kudos to you. And the Pi Zero 2W may have enough CPU and rams for PiHole but the wireless network insert too much latency to make it anything other that a low power dns backup service.

I use dns blocking + privoxy with default and custom rules. The nice thing is you can instruct dnsmasq to tell the clients there is a proxy no need to configure the proxy on every client.

I tried adblock-fast a couple of weeks ago, but alas it's not suitable for my use case, as it blocked legitim sites, too. I know I can whitelist, but it's too complicated to do that on a router for members of the family with non-IT background.

So I prefer local blocking within the browser:

AdNauseam is a fork of uBO, it not only blocks ads, but also clicks on them - adding injury to the insult for nasty sites. :grin:

I use my openwrt x86 machine solely for routing/firewall duties. VLAN, dhcp options, and local network dns resolutions.

Any external dns requests (with the openwrt firewall rules) get sent to my pi-hole which is my upstream resolver for the router. The pi-hole then blocks what it is told to and resolves legitimate (allowed) traffic via doh.

With the pi-hole, I can specify which clients are filtered and which are not with logging to show what dns requests are being made and by which machine with both IP and device name associations.

I also use my pi-hole environment (lxc) as my dynamic dns updater.

On openwrt I installed the banIP service and use that to block doh traffic that can't be caught with the regular firewall rules.

On the browsers, ublock origin is installed to take care of the rest. Youtube ads still get blocked by ubo but can't be blocked by pi-hole without blocking the entire video.

I use a combination of everything to cover as much as possible. Also, hardware resource could be a consideration for some people. I personally prefer to segregate services/hardware whenever/wherever possible to minimize the "single point of failure" scenario that I have become tired of dealing with. If my pi-hole goes down for whatever reason I can fallback to a second one (lxc) or worse case scenario I can just tell my router to redirect all dns traffic to a specific www upstream while I fix the pi-hole.

There's no wrong or right answer except what is right to you.

2 Likes

I use all 3 options - but I believe the most effective are device addons like adguard.
Pihole is great for its simple and intuitive web ui.
(Simple) adblock is for low resource devices like the ones with mips soc.
One interesting fact is that after receiving multiple complaints from my wife I had to exclude her iphone from all adblocking - happy wife happy life they say - so make sure you're able to handle these kind of requests from your solution.

3 Likes

@adiz0r Could you share your experience which valid websites exactly have been blocked using adblock-fast ?

I can only clearly remember one example: the newsletters from Armstrong Economics. Articles go through some sort of click counter site, which had worked before, but after enabling the blocker, suddenly "disappeared" from DNS.

I like BIND with a Response Policy Zone (RPZ) for whole-house blocking. It is a bit on the geeky side - I haven't seen anything with a nice GUI; it's all command line and checking the log file to see what all has been allowed when an ad gets thru and what all has been blocked when the wife complains she can't get to some web site.

Then a firewall to block google & whatever other open DNS resolvers that "smart" phones, TVs, etc. want to talk to instead of the resolver they're given via DHCP.

For the browser, uMatrix to disable javascript by default and uBlock Origin to block nasty things like youtube ads and finally privoxy so I can go overboard with blocking sites.