unbound and traffic shaping cause "sendto failed: No buffer space available"
-
I assumed the buffer is just a log entry by unbound that the connection has dropped, while actually the it's not caused by buffer, but by bandwidth shaping, and setting a priority to DNS port 53 didn't solve the issue, same error kept showing up, and how to allocate more buffer? I used maximum buffer for unbound 512 MB and only disabling traffic shaping did solve the buffer issue, is there a buffer for bandwidth shaping? how can I prevent the requests for dns not being shaped all together?
-
Well, I presume that "sendto" will be a low level kernel function that works in relation to the IP stack.
It might as well be this one :
-
that's at 1% max on my installation, I don't think that's an issue here
-
Maybe here : "sendto failed: No buffer space available"
-
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 !
-
Another thought : DNS requests fall into a queue that is not prioritized ?
-
thats exactly my question, how can I do that?
-
Instead of what I do here :
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.
-
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 -
@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.
-
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.
-
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 ? -
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
-
I added some DNS exceptions rules in front of my shaper rules :
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. -
B bmeeks referenced this topic on
-
B bmeeks referenced this topic on
-
B bmeeks referenced this topic on
-
B bmeeks referenced this topic on
