This is a fresh install on a new SD card.
RPi4B/8GB,
OS v12 (bookworm),
Pi-Hole Core v6.0.1, FTL v6.0, WebUI v6.0 with Unbound/Wireguard enabled
2 Likes
This message was generated by the upstream server you are using (apparently Unbound). Pi-hole only logged what happened.
Maybe using a different upstream server will fix the issue.
Seeing the same error in the Pi-Hole Diagnostics, once yesterday and once today on a Pi 3+ running Pi-Hole v6 (updated from v5) and Unbound locally on the Pi 3B+. And saw the same error yesterday on a Pi Zero W also running Unbound locally that likewise was updated from Pi-Hole v5 to v6. From the Pi 3B+'s FTL.log file:
2025-02-20 15:09:20.302 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-20 15:24:45.742 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-20 15:25:15.606 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-20 15:26:32.622 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-20 15:47:19.982 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-20 15:48:29.742 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-20 16:11:47.502 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-20 16:14:44.142 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
Checked the syslog file on the Pi 3B+ and don't see any error offhand around that same time.
Edit to add: Nothing has changed on the Raspberry Pi's other than updating Pi-Hole. Did not see, as far as I can remember, these kinds of errors in Pi-Hole v5 on either Pi device.
I have repeated errors of this type along with some other errrors in between, but the vast majority is this "WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream"
The other errors that pop up in between are these:
2025-02-20 23:15:56.464 INFO Flushing cache and re-reading config
2025-02-20 23:15:56.466 INFO Blocking status is enabled
2025-02-20 23:15:56.567 INFO Compiled 0 allow and 0 deny regex for 18 clients in 0.3 msec
...and several of these:
2025-02-21 00:47:47.638 INFO Received 8/8 valid NTP replies from pool.ntp.org
2025-02-21 00:47:47.638 INFO Time offset: 1.238286e-01 ms (excluded 0 outliers)
I am not sure if thse have any significance.
Updated debug token on: https://tricorder.pi-hole.net/aYpRx5UK/
Good morning,
I am also having the same issues as others here. There have also been a couple of threads popping up for this in Reddit. So far, I do not think anyone has gotten an answer.
1 Like
Having same issue. Fresh install on RPI5 (4GB), bookworm, using unbound.
Core [v6.0.3]
FTL [v6.0.1]
Web interface [v6.0.1]
From a reddit discussion, it seems there might be a fix in Unbound by adding or increasing the value used for "incoming-num-tcp".
Added "incoming-num-tcp: 40" to the end of the Unbound configuration file "/etc/unbound/unbound.conf.d/pi-hole.conf" on my Raspberry Pi running Pi-Hole and Unbound (rebooted the Pi). Will keep an eye on Pi-Hole to see if this fixes the issue.
Edit to add: Initial fix didn't work. Got error almost immediately. Changing value to 50 and will monitor.
Edit 2: Trying 25 as the value to see if it does anything.
You might be referring to my post over there. Though I changed mine to 25 instead of 40.
Been going a little over 4 hrs without any errors. I also made a few more changes before this which did seem to help, but ultimately this is what seems to have solved it.
Now it might start throwing errors again when I make this post, but so far this has been the longest since V6 that I have gone without errors.
1 Like
I did a pihole -up to latest releases [Core v6.0.3 FTL v6.0.1 Web interface v6.0.1] just shy of 5pm local and after reboot the errors disappeared from /var/log/pihole/FTL.log. It is now 9:46pm, so it is up for just about 5hrs without any occurences, so I assume something must been changed in the code.
My Pi-Holes were updated to Core v6.0.3FTL v6.0.1Web interface v6.0.1 more than 8 hours ago and I was still getting the discussed Unbound connection error. After doing the "incoming-num-tcp" fix mentioned up page (and experimenting with the value) I have stopped receiving the error in he past two hours. Fingers crossed the error doesn't return.
The errors resurfaced 5-and-a-half hours post the aforementioned pihole update.
Added the "incoming-num-tcp: 25" to the top of the Unbound configuration file "/etc/unbound/unbound.conf.d/pi-hole.conf" and will be monitoring
With incoming-num-tcp: 25 still got an error on a Pi 3B+ running Pi-Hole + Unbound:
2025-02-21 16:47:24 CONNECTION_ERROR Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
You mean putting 40 stopped the warnings?
In my case, no. 40 did not stop the warning. Still got the error with the value at 25, 40 and 50 (with Unbound restarts in-between each value change) on a Pi 3B+ Pi-Hole Core v6.0.3FTL v6.0.1 Web interface v6.0.1 + Unbound. Trying 100 now (this time rebooted the Pi itself). In my case seems to go a few hours before the error appears when using the lower numbers.
Edit to add: Using 100 as the value didn't stop the warning.
2025-02-21 17:56:21 CONNECTION_ERROR Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
Maybe related? If it's not, I'll start a new topic.
In-place upgrade from v5 to v6.
Unbound is installed as my primary lan DNS and forwarder, but listening on an aliased lo0 address (127.0.1.2) -- along with the 8953 that I haven't figured out how to get rid of:
$ sudo netstat -nlp | grep 'unbound'
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN 2613/unbound
tcp 0 0 127.0.1.2:53 0.0.0.0:* LISTEN 2613/unbound
tcp 0 0 127.0.1.2:53 0.0.0.0:* LISTEN 2613/unbound
tcp6 0 0 ::12:53 :::* LISTEN 2613/unbound
tcp6 0 0 ::12:53 :::* LISTEN 2613/unbound
tcp6 0 0 ::1:8953 :::* LISTEN 2613/unbound
udp 0 0 127.0.1.2:53 0.0.0.0:* 2613/unbound
udp 0 0 127.0.1.2:53 0.0.0.0:* 2613/unbound
udp6 0 0 ::12:53 :::* 2613/unbound
udp6 0 0 ::12:53 :::* 2613/unbound
pihole.toml has the correct setting for DNS upstreams:
upstreams = [
"127.0.1.2"
]
but the rDNS /PTR lookup function continues to "spam" the logs trying to resolve IP-to-Name on 127.0.0.1:53:
2025-02-21 16:26:30.029 CST [1629/T1634] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2025-02-21 16:26:30.029 CST [1629/T1634] INFO: Tried to resolve PTR "9.f.b.8.5.3.8.c.4.8.f.4.4.9.1.0.0.0.7.3.c.4.0.0.9.7.5.0.1.0.0.2.ip6.arpa" on 127.0.0.1#53 (UDP)
There's definitely nothing listening on port 53 for lo0:
$ sudo netstat -nlp | grep '127.0.0.1'
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN 749/unbound
udp 0 0 127.0.0.1:123 0.0.0.0:* 998/ntpd
I haven't find anything in the distribution .toml or in the online docs that either require a separate rDNS resolver or let me set a custom rDNS server, maybe something "nondocumented"? Or that I need to use "legacy dnsmasq" to force?
I get the same error message with DNSCrypt 2.1.7 without Unbound [Pi-Hole: Core v6.0.3, FTL v6.0.1, Web interface v6.0.1]
"Connection error (::1#5300): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)"
Only IPv6-servers with dnssec are entered in dnscrypt-proxy.toml.
@bennor3814, I edited the setting to 40 after your remarks and rebooted. Pihole is running without errors since and have been roughly 12hrs. Fingers crossed.
@panoshountis, Yes fingers crossed. Seems this is hit or miss on working. So far even increasing to 100 didn't work for me on one of my Pi's. I still get the error message. Like this one just a few minutes ago:
2025-02-22 06:38:48 CONNECTION_ERROR Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
From the FTL.log:
2025-02-22 05:38:23.863 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 06:17:59.543 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 06:33:16.663 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 06:35:29.143 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 06:38:48.183 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
I've tossed in the towel and have removed the "incoming-num-tcp" entry for now until there is a better fix available (if one is found). Obviously there is some sort of a change in Pi-Hole v6 that is now showing these errors when Pi-Hole v5 did not. Pi-Hole folks point the finger at Unbound and the "incoming-num-tcp" fix seems to be hit or miss on working (its a miss for me currently).
1 Like
Got one single occurence, 20 odd hrs after setting "incoming-num-tcp: 40" and rebooting. Keeping an eye on it.
setting "incoming-num-tcp: 25" seems to stop warning for me.