failed to send packet: Resource temporarily unavailable

[DL6ER]

For the last week or so I've been getting tons of "failed to send packet: Resource temporarily unavailable" errors. DNS stops working completely. Sometimes it recovers after ~10 minutes, sometimes I have to restart pihole-FTL. I've even added this restart to cron every two hours.

root@pihole:~# grep -c "failed to send packet: Resource temporarily unavailable" /var/log/pihole/pihole.log
4196

tcpdump shows that pihole receives the request and even forwards it to the upstream DNS server. Bet when upstream replies, pihole doesn't send the answer to the client.

17:18:01.627520 IP 192.168.134.136.64302 > 192.168.134.108.53: 56518+ AAAA? media.x.x.x. (31)
17:18:01.627522 IP 192.168.134.136.55958 > 192.168.134.108.53: 36692+ A? media.x.x.x. (31)
17:18:01.627730 IP 192.168.134.108.47217 > 192.168.134.1.53: 56911+ AAAA? media.x.x.x. (31)
17:18:01.627864 IP 192.168.134.108.44702 > 192.168.134.1.53: 30034+ A? media.x.x.x. (31)
17:18:01.627953 IP 192.168.134.1.53 > 192.168.134.108.44702: 30034* 1/0/0 A 192.168.134.109 (47)
17:18:01.628104 IP 192.168.134.1.53 > 192.168.134.108.47217: 56911* 0/0/0 (31)

Here x.136 is the client, x.108 is pihole and x.1 is the upstream DNS server.

BTW, running in Ubuntu 22.04 LTS LXC container with memory limited to 1GB. All the latest OS and pihole updates are installed.

Originally posted by @kornaz in #5608 (comment)

[DL6ER]

Resource temporarily unavailable is the text behind the error code EAGAIN. This can happen for a few reasons, the most often seen is that the interface went into DOWN state, "lost" it's address or other routing issues happen (when the kernel does not know how to send a query to your client). Basically, everything that prevents packets from being able to reach their destination => Resource temporarily unavailable is shown because the socket is still busy sending the previous message and the send buffer is full.

Another reason is mentioned in man sendmsg:

   EAGAIN (Internet  domain  datagram  sockets)  The socket referred to by
          sockfd had not previously been bound to an address and, upon at‐
          tempting to bind it to an ephemeral port, it was determined that
          all port numbers in the ephemeral port range  are  currently  in
          use.     See   the   discussion   of   /proc/sys/net/ipv4/ip_lo‐
          cal_port_range in ip(7).

The ephemeral port range is limited in size (49152 to 65535 = 16383) and I'm not sure of LXC comes into play here - does the container have its own IP address or does it somehow share its address (and hence ports) with the host?

There have been a few indications on the web that this could also happen when the MTU is unusually low and the UDP packet cannot be sent without blocking. But nothing here is really credible and worth quoting, I'm just mentioning this for the sake of completeness - maybe it rings a bell concerning your particular container configuration.

---

So it seems we need more information. When this happens - does the Pi-hole stop working altogether?

tcpdump shows that pihole receives the request and even forwards it to the upstream DNS server. Bet when upstream replies, pihole doesn't send the answer to the client.

What isn't clear to me: Do you want to show with the tcpdump snippet that receiving from the client works, sending + receiving from upstream as well and only sending back to the client is broken? Is it always the same behavior? Is it always the same client triggering this?

Does you tcpdump show any further arriving queries or is there absolute silence after the last line in your snippet above?

17:18:01.628104 IP 192.168.134.1.53 > 192.168.134.108.47217: 56911* 0/0/0 (31)

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.