I am getting random bursts of "dns: buffer size too small" errors from AdguardHome after I upgraded to OpenWrt 24.10.0 (I am getting this in two different devices, R6S and AX6S).
Things that I have already tried and did not solve the issue:
Upgraded AdguardHome to the latest version (to v0.107.57)
Increased rmem and wmem sizes in /etc/sysctl.conf to 16MiB as folows:
Is there anything non-stock about your Adguard Home setup? I'm curious because I'm on this version for 3 weeks now I think and I don't have anything similar. Which upstreams do you use? Could it be related to QUIC ones as per the GitHub issue (I only use TLS ones)? I somehow doubt the total buffer size is the problem.
I have my own configurations, but nothing crazy. I tested 1.1.1.1 and 8.8.8.8 as upstreams, both with tls:// and https://, and the error happens with both.
I have "AdGuard browsing security web service" enabled, increased DNS cache size to 67108864 and override TTL min/max to 3600/86400, and two client configurations.
Nothing jumps out in the config, so perhaps the issue is elsewhere. Have you tried starting with a fresh Adguard config either way with minimal changes?
Increasing net.core buffers to 128MiB did not help. Errors still appears in burst randomly once or twice a day.
So this is not related to buffer size. I don't want to mess with my main router. When I have time I will setup a spare R4S I have with vanilla OpenWrt and default clean Wireguard setup, and check if this issue still remains.
@Dante I had sometime to install it today early morning.
I did a clean install of OpenWrt 24.10.0 on an R5S, installed AdGuardHome 0.107.57 (default via opk install), and did some basic configuration.
Then I changed my main router to set the R5S AdguardHome as default DNS server via DHCP (dhcp_option 6,192.168.1.92, 3,192.168.1.92) and I would wait all clients in my network to renew DHCP to start using the fresh AdguardHome.
Well, this setup is up an running for about 10 hours now. But after 8 hours I got the first two "buffer too small" errors:
Thu Mar 27 18:08:01 2025 daemon.err AdGuardHome[6070]: 2025/03/27 21:08:01.554061 [error] dnsproxy: unpacking udp packet err="dns: buffer size too small"
Thu Mar 27 18:08:04 2025 daemon.err AdGuardHome[6070]: 2025/03/27 21:08:04.557772 [error] dnsproxy: unpacking udp packet err="dns: buffer size too small"
I will keep this server running for at least one more day, but so far it seems that even starting from a fresh install and config I am getting the same errors.
For now, I am giving up on trying to solve these issues. They happen a few times a day, and I have not noticed any impact on the client side (possibly, clients just retry the DNS resolution when this happens).
If I have time, I may repeat this test using a snapshot build that includes some additional kernel 6.6 patches that could have some positive side effects, but it is more likely that I will wait for 24.10.1 to upgrade my main router and see if these errors go away.
it looks like the DNS response is invalid, so nothing to do with any buffer setting on the router. Perhaps enabling verbose logging could shed some light, as there's a Debug log message right above that.
OK, I enabled AdGuardHome verbose log, and also configured a separate log file.
So far I've captured only two instances of the "dns: buffer size too small" error. Below is the log session with the debug messages right before the error. Nothing seems unusual.
The only thing in common in these two errors are that they seem to originated of a DNS resolution from client 192.168.1.248 (Samsung A55 device).
However I am not sure the log time sequence can be trusted (I suppose AdGuardHome is multithreaded). The only debug message in the code you referred above before the error is 2025/04/01 09:54:52.758247 18344#238 [debug] dnsproxy: handling new udp packet raddr=192.168.1.248:57170 but it does not help (except pointing the originating client).
I will keep monitoring.
Log 1
(...)
2025/04/01 09:54:55.014103 18344#312 [debug] dnsforward: started processing querylog and stats
2025/04/01 09:54:55.014144 18344#312 [debug] dnsforward: client ip for stats and querylog: 192.168.1.248
2025/04/01 09:54:55.014218 18344#312 [debug] dnsforward: finished processing querylog and stats
2025/04/01 09:54:55.014324 18344#312 [debug] dnsproxy: out line_num=1 line=";; opcode: QUERY, status: NOERROR, id: 59422"
2025/04/01 09:54:55.014386 18344#312 [debug] dnsproxy: out line_num=2 line=";; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 0"
2025/04/01 09:54:55.014444 18344#312 [debug] dnsproxy: out line_num=3 line=""
2025/04/01 09:54:55.014503 18344#312 [debug] dnsproxy: out line_num=4 line=";; QUESTION SECTION:"
2025/04/01 09:54:55.014561 18344#312 [debug] dnsproxy: out line_num=5 line=";locationhistory-pa.googleapis.com.\tIN\t A"
2025/04/01 09:54:55.014620 18344#312 [debug] dnsproxy: out line_num=6 line=""
2025/04/01 09:54:55.014678 18344#312 [debug] dnsproxy: out line_num=7 line=";; ANSWER SECTION:"
2025/04/01 09:54:55.014738 18344#312 [debug] dnsproxy: out line_num=8 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.172.170"
2025/04/01 09:54:55.014807 18344#312 [debug] dnsproxy: out line_num=9 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.162.234"
2025/04/01 09:54:55.014868 18344#312 [debug] dnsproxy: out line_num=10 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.172.42"
2025/04/01 09:54:55.014928 18344#312 [debug] dnsproxy: out line_num=11 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.172.138"
2025/04/01 09:54:55.014987 18344#312 [debug] dnsproxy: out line_num=12 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t142.251.128.170"
2025/04/01 09:54:55.015047 18344#312 [debug] dnsproxy: out line_num=13 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t142.251.128.234"
2025/04/01 09:54:55.015105 18344#312 [debug] dnsproxy: out line_num=14 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.30.234"
2025/04/01 09:54:55.015165 18344#312 [debug] dnsproxy: out line_num=15 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.28.170"
2025/04/01 09:54:55.015224 18344#312 [debug] dnsproxy: out line_num=16 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.28.42"
2025/04/01 09:54:55.015283 18344#312 [debug] dnsproxy: out line_num=17 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t142.251.129.10"
2025/04/01 09:54:55.015343 18344#312 [debug] dnsproxy: out line_num=18 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t142.251.128.202"
2025/04/01 09:54:55.015403 18344#312 [debug] dnsproxy: out line_num=19 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.30.138"
2025/04/01 09:54:55.015463 18344#312 [debug] dnsproxy: out line_num=20 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.28.202"
2025/04/01 09:54:55.015522 18344#312 [debug] dnsproxy: out line_num=21 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.28.138"
2025/04/01 09:54:55.015581 18344#312 [debug] dnsproxy: out line_num=22 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.162.10"
2025/04/01 09:54:55.015640 18344#312 [debug] dnsproxy: out line_num=23 line="locationhistory-pa.googleapis.com.\t3600\tIN\tA\t172.217.30.106"
2025/04/01 09:54:55.015698 18344#312 [debug] dnsproxy: out line_num=24 line=""
2025/04/01 09:54:55.765390 18344#313 [debug] dnsproxy: handling new udp packet raddr=192.168.1.248:57170
2025/04/01 09:54:55.765457 18344#313 [error] dnsproxy: unpacking udp packet err="dns: buffer size too small"
(...)
Log 2
(...)
2025/04/01 09:54:52.740681 18344#235 [debug] dnsforward: started processing querylog and stats
2025/04/01 09:54:52.740721 18344#235 [debug] dnsforward: client ip for stats and querylog: 192.168.1.248
2025/04/01 09:54:52.740786 18344#235 [debug] dnsforward: finished processing querylog and stats
2025/04/01 09:54:52.740861 18344#235 [debug] dnsproxy: out line_num=1 line=";; opcode: QUERY, status: NXDOMAIN, id: 6"
2025/04/01 09:54:52.740921 18344#235 [debug] dnsproxy: out line_num=2 line=";; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0"
2025/04/01 09:54:52.740983 18344#235 [debug] dnsproxy: out line_num=3 line=""
2025/04/01 09:54:52.741043 18344#235 [debug] dnsproxy: out line_num=4 line=";; QUESTION SECTION:"
2025/04/01 09:54:52.741102 18344#235 [debug] dnsproxy: out line_num=5 line=";*google.com.\tIN\t A"
2025/04/01 09:54:52.741159 18344#235 [debug] dnsproxy: out line_num=6 line=""
2025/04/01 09:54:52.741218 18344#235 [debug] dnsproxy: out line_num=7 line=";; AUTHORITY SECTION:"
2025/04/01 09:54:52.741278 18344#235 [debug] dnsproxy: out line_num=8 line="com.\t522\tIN\tSOA\ta.gtld-servers.net. nstld.verisign-grs.com. 1743500892 1800 900 604800 900"
2025/04/01 09:54:52.741335 18344#235 [debug] dnsproxy: out line_num=9 line=""
2025/04/01 09:54:52.758247 18344#238 [debug] dnsproxy: handling new udp packet raddr=192.168.1.248:57170
2025/04/01 09:54:52.758326 18344#238 [error] dnsproxy: unpacking udp packet err="dns: buffer size too small"
(...)
BTW, I am not a developer (anymore), but if I am reading it correctly, it seems that the unpack function (method?) used by AdGuardHome seems to come from https://github.com/miekg/dns/ library.
I really do not know golang, but as far as I can understand, the error ErrBuf is the "buffer size too small" message and it comes from the unpack() method from this code:
func (e *EDNS0_SUBNET) unpack(b []byte) error {
if len(b) < 4 {
return ErrBuf
}
(...)
In this case, I do not understand it would mean that the UDP packet size is less than 4? I mean, it is not about increasing buffers, but it is about how to handle an UDP DNS message that contains less than 4 bytes.
I looked into it a bit more. The actual Unpack that dnsproxy calls is here:
Which calls unpack here:
Which in turn calls a bunch of other methods that parse parts of DNS message and if any offset doesn't match, e.g. exceeds the length of the message, they throw the aforementioned ErrBuf:
That goes back to my previous comment about the DNS message being invalid. I guess if you want to dig deeper you could capture the DNS packets to figure out which ones are invalid (if any), or if AdGuard is somehow mangling these messages on their way to be unpacked, but I think that's going a bit too far. Considering it's just a few messages here and there, my gut feeling this is something coming from the upstream DNS resolvers.
