unbound and traffic shaping cause "sendto failed: No buffer space available"

[Gertjan]

Maybe here : "sendto failed: No buffer space available"

[gigaforall]

since only unbound is reporting this, and it stops when I disable traffic shaping, I had to assume that it's just the unbound (understandably) does not play well when connections are dropped with LAN clients, and I found it strange that DNS traffic on LAN are shaped by default !

[Gertjan]

Another thought : DNS requests fall into a queue that is not prioritized ?

[gigaforall]

thats exactly my question, how can I do that?

[Gertjan]

Instead of what I do here :
login-to-view

Intercepting ICMP (IPv4 and IPv6) so that it goes out before limiter rules kicks in (lower rules) you should focus on UDP and TCP, destination port 53.

[gigaforall]

okay, so till now I'm still unable to find a solution for this problem, DNS resolver log is filled with entries like this whenever I activate bandwidth shaping:
Aug 29 15:07:30 unbound 97618:0 notice: remote address is 192.168.4.59 port 1855
Aug 29 15:07:30 unbound 97618:0 notice: sendto failed: No buffer space available
so I'm wondering if this problem is a known issue or it is only happening to me?
thank you

[Gertjan]

@gigaforall said in unbound and traffic shaping cause "sendto failed: No buffer space available":

192.168.4.59 port 1855

This is a local address, and shouldn't be traffic shaped in any way.
Is this 192.168.4.59 hard wired ? Bad connection or problematic wifi link ?

After all, when unbound want to send something on one of its local networks as a reply to some LAN/OPTx network client that want something to get resolved, and it can reach this 192.168.4.59 anymore, I can imagine that such an error shows up.

[gigaforall]

this only happens when I enable Traffic shaping, took me long time to figure it out, and the only solution was to delete the LAN traffic shaping, and this prevented me to shape my download, while upload where still being shaped by the WAN queue, I agree that LAN should not be shaped, but it's obviously being shaped including DNS resolver replies.

[Gertjan]

That's why I showed you my ICMP shaper exception rules above as an example.
Isn't it possible to put in place some "UDP source port 53" floating exceptions rules BEFORE yout shaping rules, so DNS traffic in't get shaped nowhere ?

[gigaforall]

As shown in the log sample, unbound is suffering other random ports on LAN not the default 53 port, so such a rule did not change a thing when I set it

[Gertjan]

I added some DNS exceptions rules in front of my shaper rules :

login-to-view

The first rule is matched when unbound connects to any DNS server on the net, using IPv4 or IPv6, UDP or TCP, destination port 53.
The second one matches when unbound send s out some DNS traffic on my LAN interface, source port is then '53'. (Destination could be anything above 1024).

The counters show that these rules are matching traffic.

Said all this, I still think your issue isn't shaper related.
Unbound can't connect to "192.168.4.59 - port 1855" : it could be anything, even hardware related.