Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update embedded dnsmasq to v2.87 #1449

Merged
merged 2 commits into from
Sep 26, 2022
Merged

Update embedded dnsmasq to v2.87 #1449

merged 2 commits into from
Sep 26, 2022

Conversation

DL6ER
Copy link
Member

@DL6ER DL6ER commented Sep 26, 2022

By submitting this pull request, I confirm the following:

  • I have read and understood the contributors guide.
  • I have checked that another pull request for this purpose does not exist.
  • I have considered, and confirmed that this submission will be valuable to others.
  • I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
  • I give this submission freely, and claim no ownership to its content.

How familiar are you with the codebase?:

10


dnsmasq v2.87 has been released today: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q3/016599.html

simonkelley and others added 2 commits September 26, 2022 19:14
Sending the same query repeatedly to a dnsmasq instance which
doesn't get replies from upstream will eventually hit the
hard limit on frec_src structures and start gettin REFUSED
replies. This is OK, except that since the queries are no longer
being forwarded, an upstream server coming back doesn't reset the
situation. If there is any other traffic, frec allocation will
eventually delete the timed-out frec and get things moving again,
but that's not guaranteed.

To fix this we explicitly delete the frec once timed out in this case.

Thanks to Filip Jenicek for noticing and characterising this problem.

Signed-off-by: DL6ER <dl6er@dl6er.de>
Signed-off-by: DL6ER <dl6er@dl6er.de>
@DL6ER DL6ER requested a review from a team September 26, 2022 17:18
@PromoFaux
Copy link
Member

As we already have 2.87 minus 1 commit, do we want to release this as 5.18.2?

@PromoFaux
Copy link
Member

If so, we will need to do it to master (and then back to development) as we have the pihole-FTL.port file stuff that needs sorting before we can release what is currently in development

Or - if this additional commit is not urgent - then it can just go out there with whatever the next release is

@DL6ER
Copy link
Member Author

DL6ER commented Sep 26, 2022

Yeah, it can sit here and wait a bit. It's a nice commit but not urgent in any way.

@pralor-bot
Copy link

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/conditional-forwarding-issues-w-tailscale/61522/14

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants