Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved Traffic Shaping
    17 Posts 2 Posters 3.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      gigaforall
      last edited by

      Hi, I used the traffic shaping wizard to create Multiple Lan/Wan for 1 lan and 1 wan PRIQ for both lan and wan no voip, penalty box,
      with "Lower priority of Peer-to-Peer traffic" p2pCatchAll and all default values for protocol except http is high.
      The problem is, whenever I activate the traffic shaper, I get a lot of the following in the log entry of unbound:

      Jun 27 12:30:52 unbound 82505:0 notice: remote address is 192.168.3.28 port 58956
      Jun 27 12:30:52 unbound 82505:0 notice: sendto failed: No buffer space available
      with a lot of remote addresses and random ports, can someone please point me what I'm doing wrong, thank you.

      1 Reply Last reply Reply Quote 0
      • G
        gigaforall
        last edited by

        so I removed traffic shaper on LAN but now download traffic is not shaped, only upload is shaped, is there no way to have download speed shaped without hurting dns requests on LAN while using unbound?

        1 Reply Last reply Reply Quote 0
        • GertjanG
          Gertjan
          last edited by Gertjan

          Hi,

          What about this one : inform pfSense that it should allocate some more "buffers" ?

          Also : unbound doesn't use the LAN interface ....
          What about making a priority queque for all "port 53" requests, as you did for http (https I presume, http is nearly gone now)

          No "help me" PM's please. Use the forum, the community will thank you.
          Edit : and where are the logs ??

          1 Reply Last reply Reply Quote 0
          • G
            gigaforall
            last edited by

            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?

            1 Reply Last reply Reply Quote 0
            • GertjanG
              Gertjan
              last edited by

              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 : 9f71fdcd-cf39-467e-927f-ce2d3319513f-image.png

              No "help me" PM's please. Use the forum, the community will thank you.
              Edit : and where are the logs ??

              1 Reply Last reply Reply Quote 0
              • G
                gigaforall
                last edited by

                that's at 1% max on my installation, I don't think that's an issue here

                1 Reply Last reply Reply Quote 0
                • GertjanG
                  Gertjan
                  last edited by

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

                  No "help me" PM's please. Use the forum, the community will thank you.
                  Edit : and where are the logs ??

                  1 Reply Last reply Reply Quote 0
                  • G
                    gigaforall
                    last edited by

                    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 !

                    1 Reply Last reply Reply Quote 0
                    • GertjanG
                      Gertjan
                      last edited by

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

                      No "help me" PM's please. Use the forum, the community will thank you.
                      Edit : and where are the logs ??

                      1 Reply Last reply Reply Quote 0
                      • G
                        gigaforall
                        last edited by

                        thats exactly my question, how can I do that?

                        1 Reply Last reply Reply Quote 0
                        • GertjanG
                          Gertjan
                          last edited by Gertjan

                          Instead of what I do here :
                          1d6c8c0b-5f5b-427a-9bd2-3b87a90038de-image.png

                          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.

                          No "help me" PM's please. Use the forum, the community will thank you.
                          Edit : and where are the logs ??

                          1 Reply Last reply Reply Quote 0
                          • G
                            gigaforall
                            last edited by

                            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

                            GertjanG 1 Reply Last reply Reply Quote 0
                            • GertjanG
                              Gertjan @gigaforall
                              last edited by

                              @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.

                              No "help me" PM's please. Use the forum, the community will thank you.
                              Edit : and where are the logs ??

                              1 Reply Last reply Reply Quote 0
                              • G
                                gigaforall
                                last edited by

                                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.

                                1 Reply Last reply Reply Quote 0
                                • GertjanG
                                  Gertjan
                                  last edited by

                                  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 ?

                                  No "help me" PM's please. Use the forum, the community will thank you.
                                  Edit : and where are the logs ??

                                  1 Reply Last reply Reply Quote 0
                                  • G
                                    gigaforall
                                    last edited by

                                    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

                                    1 Reply Last reply Reply Quote 0
                                    • GertjanG
                                      Gertjan
                                      last edited by Gertjan

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

                                      dd8edc61-e2d9-4177-be57-4adf0fca8afb-image.png

                                      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.

                                      No "help me" PM's please. Use the forum, the community will thank you.
                                      Edit : and where are the logs ??

                                      1 Reply Last reply Reply Quote 0
                                      • bmeeksB bmeeks referenced this topic on
                                      • bmeeksB bmeeks referenced this topic on
                                      • bmeeksB bmeeks referenced this topic on
                                      • bmeeksB bmeeks referenced this topic on
                                      • First post
                                        Last post
                                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.