Unbound problems after update to latest beta
-
I hope so, too. I have not received any feedback about the patch I posted here (or on the Redmine ticket). I could not reproduce the problems here, so I'd rather not commit it without verifying it works properly on firewalls that exhibited the previous problems.
-
I hope so, too. I have not received any feedback about the patch I posted here (or on the Redmine ticket). I could not reproduce the problems here, so I'd rather not commit it without verifying it works properly on firewalls that exhibited the previous problems.
Hmm, in reply #13 I gave feedback, I believe. Works fine, I have not upgraded my installation since.
-
I hope so, too. I have not received any feedback about the patch I posted here (or on the Redmine ticket). I could not reproduce the problems here, so I'd rather not commit it without verifying it works properly on firewalls that exhibited the previous problems.
Hmm, in reply #13 I gave feedback, I believe. Works fine, I have not upgraded my installation since.
I must have missed the "edit:". I do not get notified on post edits like I do for replies, it's not a very effective way to convey an update like that.
-
Ah, sorry, I'll post a second answer for things like this in the future. But it would be great if the others in this thread could give it a shot, too.
-
I went ahead and committed the updated patch, we'll see how that goes.
-
I can't say whether the issue I'm experiencing is related to this one, but it's been consistent for a while that I have to restart unbound after updating or rebooting pfsense or else nslookup and dig will fail. This is only using the snapshot, not 2.3.4. I am using the "do not wait for RA" feature. Otherwise my system is quite simple and uses defaults almost exclusively.
Here are the details: https://forum.pfsense.org/index.php?topic=132181.0
-
I'm not sure what's going on here, but while swapping modems this afternoon (upgraded to a DOCSIS 3.1 modem), I had my pfSense WAN interface not connected for a bit. After reconnecting it, and just now looking in the DNS Resolver logs, I have extended the log view up to 5000 lines and over 95% of the lines are…
Jul 18 17:30:46 unbound 82208:1 error: can't bind socket: Can't assign requested address for x.x.x.x
or replace the IPv4 address with an IPv6 address. The timestamp is the exact same to the minute, with a variance of 3 seconds over more than 4900 lines. That's some MAJOR log spamming going on while the connection is down.
Maybe it's always done that and I just haven't noticed (I don't tend to look at dns resolver logs often)… but that's pretty severe to be writing over 4900 lines to a log file in just three seconds. Possibly related? If not, please feel free to split this to a new topic.