2 ms·
As others have said this being caused by proper functioning Pi Hole functionality (DNS) is impossible. As you’ve said I know many people using it with Comcast.
by kkielhofner 4y ago
As others have said this being caused by proper functioning Pi Hole functionality (DNS) is impossible. As you’ve said I know many people using it with Comcast.
Networks are very funny things and much more complicated than most appreciate. Almost 10 years ago a blog post[0] I wrote with some crazy network debugging was the top post on HN.
I don’t expect you to read the full post but I was able to root cause analysis an issue with cause and effect that no one with network experience would think possible. Long story short in my case a specific byte value at an exact byte location would crash the ethernet controller and cause it to drop off the PCIe bus. You could forward billions of packets and it would never happen. Or one wrong one and end up having to power cycle to get it back…
I’m guessing you have a similar situation here. Maybe the Raspbery PI is glitching somehow and spamming absolute garbage traffic at the modem, which may or may not be forwarded to the DOCSIS side (which is shared broadcast). I could see Comcast booting the modem from the network in this scenario.
Maybe you have your own “packet of death” type scenario where the DNS requests from the Pi Hole and some other specific aspect of the traffic trigger something in the modem (more likely) or head end and crashing (kind of like my situation).
Or any of the other millions of things with a technical underlying cause that could be presenting here.
Unless you want to spend hundreds of hours debugging this like I did you’ll have to do what we all do everyday which is shrug your shoulders, say “Huh, that was weird”, and accept that you found yet another strange bug out there.
What I can say is what we’ve all said and what you’ve found elsewhere. This is not some Comcast advertising related conspiracy targeting you.
Hanlon’s Razor and all.
[0] - http://blog.krisk.org/2013/02/packets-of-death.html?m=1 http://blog.krisk.org/2013/02/packets-of-death.html?m=1