The only real point of that setting is how to handle DNS queries when your clock isn't properly set yet, meaning crypto validation cannot be done. It's unrelated to what is being investigated.might also play around with the strict vs opportunistic.
The only real point of that setting is how to handle DNS queries when your clock isn't properly set yet, meaning crypto validation cannot be done. It's unrelated to what is being investigated.might also play around with the strict vs opportunistic.
I tried thisThe only real point of that setting is how to handle DNS queries when your clock isn't properly set yet, meaning crypto validation cannot be done. It's unrelated to what is being investigated.
Changes made to the WAN page will cause the WAN connection to be restarted, which in turns will restart a whole bunch of services.I have to look at the logs in detail because trying this again caused a whole lot of services to restart
That’s what I observe, I don’t usually pay to much attention to it. But this time just about everything restarted and I hadn’t seen that before.Changes made to the WAN page will cause the WAN connection to be restarted, which in turns will restart a whole bunch of services.
If you use addons, such as one that modifies the dnsmasq config or uses a very large list of host entries, it may cause crashes. This isn't something new however, it's been randomly happening to some users for quite some time now. The watchdog will take care of restarting dnsmasq after a minute or two.
Interesting findings by the PiHole team.The SERVFAIL error is actually DNSSEC doing its job.
DNSSEC prevents a reply from being replaced by a different answer, by using reply signing. When using Cloudflare 1.1.1.2, Cloudflare returns a different answer than what is the real answer, returning 0.0.0.0 instead of the correct IP. Dnsmasq receives this response, it fails DNSSEC validation, and turns the response into a SERVFAIL error.
Then, dnsmasq incorrectly logs it as a resource limit exceed, which is the log entry people are seeing.
I explored the dnsmasq code and couldn't come up with a simple fix, so I will just remove the log entry, or move it to a DEBUG priority to hide it from normal users.
discourse.pi-hole.net
Interesting. Seems for those running unbound as their upstream DNS this happens. I have OpenDNS as my upstream and don't see this in my logs after the Pi-hole update that included the dnsmasq fix. Will keep my eyes on that...Interesting findings by the PiHole team.
![]()
[pihole] [unbound] [DNSMASQ] validation failed: resource limit exeeded
Okay, so the warning is indeed a bug and shouldn't be printed at all. I will contact the dnsmasq maintainer to check what the best solution should look like and keep you updated! Pi-hole will then likely push out an FTL v5.25.1 soon after. Thank you all for helping characterizing and confirming...discourse.pi-hole.net
Interesting. I wouldn’t bother enabling FTL/dnsmasq DNSSEC if I was forwarding to Unbound on the same server. Let Unbound do its thing. Maybe I need to setup a Pi-Hole again to see how it’s going.Interesting. Seems for those running unbound as their upstream DNS this happens. I have OpenDNS as my upstream and don't see this in my logs after the Pi-hole update that included the dnsmasq fix. Will keep my eyes on that...
This is the same thing that I found. If a request results in a SERVFAIL (for instance if DNSSEC validation fails), then it generates that incorrect log entry.Interesting findings by the PiHole team.
Feb 19 15:26:18 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link DOWN.
Feb 19 15:26:19 kernel: ^[[0;30;103mWarning: Serdes at 7 link does not go up following external copper PHY at 19.^[[0m
Feb 19 15:26:20 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link Up at 10000 mbps full duplex
Feb 19 15:26:22 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link DOWN.
Feb 19 15:26:25 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link Up at 10000 mbps full duplex
Feb 19 15:26:28 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link DOWN.
Feb 19 15:26:34 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link Up at 10000 mbps full duplex
Feb 19 15:26:37 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link DOWN.
Feb 19 15:26:39 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link Up at 5000 mbps full duplex
Feb 19 15:27:46 rc_service: cfg_server 3142:notify_rc update_sta_binding
Unrelated to the dnsmasq change. This seem to indicate your Ethernet port is struggling with staying up at 10 Gbps, and eventually it had to settle on 5 Gbps. To me that sounds like a bad connection, I would try reconnecting both ends of that Ethernet cable, or if it still flaps, replace the cable.I am seeing an awkward error on the 1st alpha that does not occur on the previous standard merlin release. I don't see any relevant changes in the log that might be causing this.
My TP-Link managed switch keeps disconnecting randomly on its copper SFP. I won't get into it too much until I test some more but wanted to see if there were any others experiencing this.
Log
Code:Feb 19 15:26:18 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link DOWN. Feb 19 15:26:19 kernel: ^[[0;30;103mWarning: Serdes at 7 link does not go up following external copper PHY at 19.^[[0m Feb 19 15:26:20 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link Up at 10000 mbps full duplex Feb 19 15:26:22 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link DOWN. Feb 19 15:26:25 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link Up at 10000 mbps full duplex Feb 19 15:26:28 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link DOWN. Feb 19 15:26:34 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link Up at 10000 mbps full duplex Feb 19 15:26:37 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link DOWN. Feb 19 15:26:39 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link Up at 5000 mbps full duplex Feb 19 15:27:46 rc_service: cfg_server 3142:notify_rc update_sta_binding
Reverting to the previous build seems to resolve this, but I will test the newest alpha today as well.
I have noticed no other issues besides this.
Any ideas?
Thanks for the swift reply and all of your hard work!Unrelated to the dnsmasq change. This seem to indicate your Ethernet port is struggling with staying up at 10 Gbps, and eventually it had to settle on 5 Gbps. To me that sounds like a bad connection, I would try reconnecting both ends of that Ethernet cable, or if it still flaps, replace the cable.
Can be either of them. Both ports will negotiate an appropriate link rate based on the connection quality, so it could be a problem with either ports, or the cable itself.Do you mean the ASUS port is struggling, or the TP-Link?
Seems snappier to me too. My setup is pretty basic but still noticed.Updated to lastest.
Limit exceeded error is gone. For good.
Maybe It's placebo, apps/sites here now loads faster in Samsung Smartphone/Tablet.
Just first impression.
Will keep an eye.
First impression does look good.
View attachment 56622

Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!