Hi DL6ER, I'm seeing the same issue described as here:
The issue I am facing: My PiHole setup works without any issues. But I noticed when looking at pihole-FTL.log file that it is full of the following error message.
...
[2022-02-15 00:29:19.191 25294M] ERR: Port mismatch for 127.0.0.1: we derived 5053, dnsmasq told us 43
[2022-02-15 00:30:27.244 25294M] ERR: Port mismatch for 127.0.0.1: we derived 5053, dnsmasq told us 43
[2022-02-15 00:33:04.697 25294M] ERR: Port mismatch for 127.0.0.1: we derived 5053, dnsmasq told us 43
...
I want to resolve …
Running on Raspberry Pi 3 B+
Pi-hole v5.12
I'm also using cloudflared.
$ pihole checkout ftl fix/dnssec-retry
[✗] Requested branch "fix/dnssec-retry" is not available
I don't think these fixes (https://github.com/pi-hole/FTL/compare/master...fix/dnssec-retry ) ever got merged into master.
More than happy to provide debug token if still needed.
DL6ER sent this upstream to dnsmasq where it got accepted into the codebase.
pi-hole:master ← pi-hole:fix/dnssec-retry
opened 07:50PM - 02 Apr 22 UTC
The current version of dnsmasq logs the upstream port like
```
Feb 21 22:02:… 18 dnsmasq[8991]: dnssec-query[DS] microsoft.net to 127.0.0.1#5053
```
when sending queries upstream. However, it is missing for dnssec-retry like
```
Feb 21 22:02:18 dnsmasq[8991]: dnssec-retry[DS] microsoft.net to 127.0.0.1
```
This is added by this patch implementing it in the same way as used elsewhere in the code.
dnsmasq tagged a new release candidate just a few days ago which includes the patch. This update has been merged into the development version of FTL and will be part of the next Pi-hole release.
pi-hole:development ← pi-hole:update/dnsmasq
opened 09:27AM - 11 Sep 22 UTC
**By submitting this pull request, I confirm the following:**
- [X] I have re… ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md).
- [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist.
- [X] I have considered, and confirmed that this submission will be valuable to others.
- [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
- [X] I give this submission freely, and claim no ownership to its content.
**How familiar are you with the codebase?:**
## 10
---
CHANGELOG entries since our last `dnsmasq` update:
```
Enhance --domain to accept, for instance,
--domain=net2.thekelleys.org.uk,eth2 so that hosts get a domain
which relects the interface they are attached to in a way which
doesn't require hard-coding addresses. Thanks to Sten Spans for
the idea.
Fix write-after-free error in DHCPv6 server code.
CVE-2022-0934 refers.
Add the ability to specify destination port in
DHCP-relay mode. This change also removes a previous bug
where --dhcp-alternate-port would affect the port used
to relay _to_ as well as the port being listened on.
The new feature allows configuration to provide bug-for-bug
compatibility, if required. Thanks to Damian Kaczkowski
for the feature suggestion.
Bound the value of UDP packet size in the EDNS0 header of
forwarded queries to the configured or default value of
edns-packet-max. There's no point letting a client set a larger
value if we're unable to return the answer. Thanks to Bertie
Taylor for pointing out the problem and supplying the patch.
Fix problem with the configuration
--server=/some.domain/# --address=/#/<ip> --server=<server_ip>
This would return <ip> for queries in some.domain, rather than
forwarding the query via the default server.
Tweak DHCPv6 relay code so that packets relayed towards a server
have source address on the server-facing network, not the
client facing network. Thanks to Luis Thomas for spotting this
and initial patch.
```
Plus some bug fixes.
3 Likes
Great, thanks for the update and for everything that y'all do!
system
October 5, 2022, 10:48am
4
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.