Can't bind socket: Can't assign requested address for fe80:
-
I have a similar issue with log spam:
The log is filling up with 'error: can't bind socket: Can't assign requested address for fe80::4:2:1070'
fe80::4:2:1070 is the WAN Link Local address.
Unbound config:
- Respond to queries on LAN and Localhost.
- Outgoing network interface is set to WAN
- Forwarding mode is enabled
IPv6 is configured on the WAN with the following settings that differ from the defaults:
- Request a IPv6 prefix/information through the IPv4 connectivity link
- Only request an IPv6 prefix, do not request an IPv6 address
- Prefix delegation size: 60
- (Username & Password filled in)
LAN IPV6 config is set to 'Track Interface - WAN'
-
jimp, no change after implementing your suggestion
-
jimp, no change after implementing your suggestion
Which suggestion specifically? I listed three things to try:
- Deselecting the Link-Local addresses in the list
- Using the "All" option in the list
- Deselecting everything in the list
-
no of the above worked for me
-
What do you have selected for your Outgoing network interfaces? I changed mine from 'WAN' to 'All' and the error disappeared.
On my WAN interface, the primary IPv6 and Link local addresses are the same. My ISP only provides an IPv6 prefix.
I'm not sure why unbound keeps trying to bind to the Link-Local address over and over though
-
upgrading to 2.4.0 and changing outgoing to all seem to fix it!
-
In general you almost never need to change the outgoing interfaces setting, the system will select the appropriate outgoing interface properly based on the destination addresses of the queries. It's only when you have a very special and complicated set up with multiple WANs and complicated routing you have to touch the setting.
-
I don't have a complicated setup, it's one outgoing interface with IPv4 and IPv6 that's it.
-
I meant changing it from the default "All" to something else, you almost never need to do that.
-
I finally was able to replicate it, but it looks like we're doing everything correctly. The specifications of link local addresses all have a scope in the configuration file. It looks like unbound is not too happy about the same link local address being on multiple interfaces, but that's why scopes exist…
Checking sockstat, unbound is actually bound to the addresses it complains about, even with the different scopes.
It appears to be harmless, just log spam. Someone could report it upstream to unbound if they want.
