I am having an issue and am reaching out because I have hit a dead end. So around 1-3am each night, it appears as though a bunch of my devices reach out to Pi-Hole to get their IP addresses, from what I can tell the volume causes what appears to be a known issue on RPis where eth0 just keeps going up down with log messages similar to:
bcmgenet fd580000.ethernet eth0: bcmgenet_xmit: tx ring 3 full when queue 4 awake pi-hole
I've tried the fix outlined in the issue, but it doesn't appear to fix the problem, and for 8 nights now it has always coincided with my all the devices in my home reaching out to get their DHCP addresses. What is even weirder is that the moment I try to log into the web-interface from a wired connection, it seems to kick the system out of its timeout loop and everything works fine.
Any thoughts or advice would be incredibly helpful, this DHCP request storm is the only situation I have seen where this happens, so perhaps a way to avoid it would be helpful. Unfortunately this grinds my wifi to a halt overnight.
Expected Behaviour:
DHCP/DNS continues to function as normal
Actual Behaviour:
The pi enters some kind of loop where DHCP/DNS breaks entirely until I access the web interface
If your RPi's OS is dropping and reinitialising its eth0 interface, effectively joining the network afresh, that's what would prompt clients to request a fresh DHCP lease form the just newly arrived DHCP server.
You'd have to address that on the OS level.
On first glance, I couldn't find a fix in that issue you've linked, but it seeems there have been a couple of potential workarounds posted over the length of that issue.
Rolling back to an OS or kernel release that wouldn't expose that behaviour would seem like the most promising option to me.
Ok, I didn't realize this was the behavior. There was a lot of overlap between the two events, and this was the best explanation I could come up with given the data.
Nothing else on my network was reliably happening around those times.
I am aware it is an OS level error, but as far as I can tell it has been an issue in the RPi Kernel for a long time (all of Bullseye). Most of the forum discussions I have seen on this have centered around avoiding the triggering scenario (hence this thread).
I suppose rolling back to Buster isn't the end of the world, this DHCP server is behind my firewall.
Have you considered changing to the wireless interface on the Pi to see if the problem extends to the wlan0 interface? You can run a Pi on wlan0 with almost zero impact on the DNS performance of Pi-hole.
I am using the RPi4 4GB model, and I have not tried the wireless interface.
That isn't a bad idea since the wireless would use a different driver; however, I am going to try the downgrading path first and see if this situation re-occurs tonite. If downgrading doesn't work, I'll try the wlan approach and let you know.