I've got the following intermittent socket bind errors in my log files:
error: can't bind socket: Permission denied for <IPv6 address>
Frequency: 1-3 per day
The config contains 10 specific IPv6 addresses and 4 IPv4
'outgoing-interface:'
addresses.
The errors show only IPv6 addresses (no IPv4).
The IPv6 addresses appear to work fine though.
The config also has:
prefer-ip6: yes
I found an old (from 2014) thread in the ML archive [1]
with a similar error but it did not include a solution for me.
This is unbound 1.7.2 on FreeBSD.
Any hints would be appreciated.
As a workaround I could disable the IPv6 'outgoing-interface'
configuration lines.
I've got the following intermittent socket bind errors in my log files:
error: can't bind socket: Permission denied for <IPv6 address>
Does the patch fix the problem for you?
I'm running 1.7.3 with this patch applied and still got an
can't bind socket: Permission denied for ...
error in the logs, but it feels like it is happening less frequently?
If so, the flowinfo or scopeid
information is changed and needs to be reset for the next assignment.
And somehow the information gets permission denied, maybe because of
privacy IPv6 address changes, those values refer to a no longer
accessible address?
The IPv6 addresses are statically assigned and should be available
all the time (also verified via ping6).
How bad is that error actually (since everything appears to work fine)?
Should I disable IPv6 outgoing-interface lines to workaround this errors?
I've got the following intermittent socket bind errors in my log files:
error: can't bind socket: Permission denied for <IPv6 address>
Does the patch fix the problem for you?
I'm running 1.7.3 with this patch applied and still got an
can't bind socket: Permission denied for ...
error in the logs, but it feels like it is happening less frequently?
If so, the flowinfo or scopeid
information is changed and needs to be reset for the next assignment.
And somehow the information gets permission denied, maybe because of
privacy IPv6 address changes, those values refer to a no longer
accessible address?
The IPv6 addresses are statically assigned and should be available
all the time (also verified via ping6).
How bad is that error actually (since everything appears to work fine)?
Should I disable IPv6 outgoing-interface lines to workaround this errors?
I think it is harmless, but the permission denied shouldn't really be
happening? In the code repository is a patch that prints out the port
number as well, perhaps the port number is somehow reserved for a purpose.
No need to disable IPv6, but it is interesting to see what is permission
denied, as unbound uses randomised port numbers once in a while.
Unbound already avoids all IANA registered port numbers as well as <1024
port numbers. Also, those port numbers should not give permission
denied, but a different failure (port already in use if it is in use).
So, perhaps also something with FreeBSD is going on, perhaps the
permissions system.
I think it is harmless, but the permission denied shouldn't really be
happening? In the code repository is a patch that prints out the port
number as well, perhaps the port number is somehow reserved for a purpose.
No need to disable IPv6, but it is interesting to see what is permission
denied, as unbound uses randomised port numbers once in a while.
Unbound already avoids all IANA registered port numbers as well as <1024
port numbers. Also, those port numbers should not give permission
denied, but a different failure (port already in use if it is in use).
So, perhaps also something with FreeBSD is going on, perhaps the
permissions system.
Thank you for the patch, I'm now running unbound with that diagnostics patch applied, lets see
what information we get.
I also have to mention that the error frequency decreases significantly after
applying the last patch (services/outside_network.c):
before: 1-3 error per day
after applying the patch: 1 error in 4 days
I think it is harmless, but the permission denied shouldn't really be
happening? In the code repository is a patch that prints out the port
number as well, perhaps the port number is somehow reserved for a purpose.
No need to disable IPv6, but it is interesting to see what is permission
denied, as unbound uses randomised port numbers once in a while.
Unbound already avoids all IANA registered port numbers as well as <1024
port numbers. Also, those port numbers should not give permission
denied, but a different failure (port already in use if it is in use).
So, perhaps also something with FreeBSD is going on, perhaps the
permissions system.
Thank you for the patch, I'm now running unbound with that diagnostics patch applied, lets see
what information we get.
I also have to mention that the error frequency decreases significantly after
applying the last patch (services/outside_network.c):
before: 1-3 error per day
after applying the patch: 1 error in 4 days
That is interesting to hear.
Will this be included in future unbound releases?
Yes, sure. I'll keep it in. Perhaps something similar is happening and
is what I need to do to fix it, somehow. That would be a failure where
the socket structure is reused with the addr and port reset, and somehow
the reused socket structure is not the same as a fresh malloced structure.
Yes, sure. I'll keep it in. Perhaps something similar is happening and
is what I need to do to fix it, somehow. That would be a failure where
the socket structure is reused with the addr and port reset, and somehow
the reused socket structure is not the same as a fresh malloced structure.
I guess we know why it gets permission denied now:
can't bind socket: Permission denied for <IPv6> port <some-port-bellow-1024>
my config has:
outgoing-port-permit: 32768-65535
outgoing-port-avoid: 0-32767
Yes, sure. I'll keep it in. Perhaps something similar is happening and
is what I need to do to fix it, somehow. That would be a failure where
the socket structure is reused with the addr and port reset, and somehow
the reused socket structure is not the same as a fresh malloced structure.
I guess we know why it gets permission denied now:
can't bind socket: Permission denied for <IPv6> port <some-port-bellow-1024>
I want to ask to make sure. Do you have other config with
outgoing-port-permit or outgoing-port-avoid in the file? They are
processed in order they appear.
An inspection of the code and some debug says that <1024 should really
not be in the list of possibilities, but apparantly it is for you,
perhaps due to config?
interface-automatic: no
outgoing-port-permit: 32768-60999
outgoing-port-avoid: 0-32767
ip-transparent: yes
And after these I bind to ip addresses.
interface: 192.0.2.153
interface: 2001:DB8::5
Could it be auth-zone not using those outgoing-port-permit and
outoging-port-avoid settings - timing from log looks like it could be
caused by rfc7706 config.
Thank you for the information. I don't see any problem and the config
looks spotless. Lots of outgoing interfaces is interesting information,
perhaps I can find something in that part of the code.
if you need me to run with an additional diagnostics patch
I'm happy to help unfortunately things will become harder to debug
once this server is used for 'production' (within 2-3 days).
to get the used ports you would have to apply the patch from this thread.
Could it be auth-zone not using those outgoing-port-permit and
outoging-port-avoid settings - timing from log looks like it could be
caused by rfc7706 config.
to get the used ports you would have to apply the patch from this thread.
Could it be auth-zone not using those outgoing-port-permit and
outoging-port-avoid settings - timing from log looks like it could be
caused by rfc7706 config.
I'm using auth-zone (for RFC7706) indeed.
Yes that is the problem, the auth zone probes did not consult the
config. They had 16 bit random numbers, good for security, but not
config. So, made patch. This patch is also more capable in case of a
lot of traffic and interfaces fully in use, it'll failover to another
unused part of another interface.
Fix in code repository, (bigger patch), but also reproduced below.
Yes that is the problem, the auth zone probes did not consult the
config. They had 16 bit random numbers, good for security, but not
config. So, made patch. This patch is also more capable in case of a
lot of traffic and interfaces fully in use, it'll failover to another
unused part of another interface.
Fix in code repository, (bigger patch), but also reproduced below.
thanks a lot! I'm now running with this patch applied and
I removed the outgoing-port-* lines from the config so it uses all >1024 ports: #outgoing-port-permit: #outgoing-port-avoid: