pihole-ftl v.5.3.4 / PADD v3.4 - telnet_connection_handler_thread

[un99known99]

Before submitting a bug report, are you using a test version of Pi-hole? If so, PADD doesn‘t support beta versions of Pi-hole!

Describe the bug
pihole-ftl.log is filling up with massive amount of warnings (the more the longer padd.sh runs)

To Reproduce
Steps to reproduce the behavior:

1. start padd.sh (version 3.4)
2. tail -f on pihole-ftl.log

Expected behavior
No warnings in pihole-ftl.log when padd.sh is being executed

Screenshots
[2020-12-28 13:48:56.967 19626/T24654] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer
[2020-12-28 13:48:56.987 19626/T24657] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer

[un99known99]

using official versions:
Pi-hole® v5.2.2, Web v5.2.2, FTL v5.3.4, PADD v3.4

[DL6ER]

PADD uses the same method for connecting to FTL as chronometer does:

https://github.com/pi-hole/pi-hole/blob/41bdb741b7e1a70184ecd7dbfc23f3ebcaa5e3bc/advanced/Scripts/chronometer.sh#L15-L40

PADD/padd.sh

Lines 119 to 148 in 1c93c02

	GetFTLData() {
	# Get FTL port number
	ftl_port=$(cat /var/run/pihole-FTL.port)
	# Did we find a port for FTL?
	if [[ -n "$ftl_port" ]]; then
	# Open connection to FTL
	exec 3<>"/dev/tcp/localhost/$ftl_port"
	# Test if connection is open
	if { "true" >&3; } 2> /dev/null; then
	# Send command to FTL
	echo -e ">$1" >&3
	# Read input
	read -r -t 1 LINE <&3
	until [ ! $? ] || [[ "$LINE" == *"EOM"* ]]; do
	echo "$LINE" >&1
	read -r -t 1 LINE <&3
	done
	# Close connection
	exec 3>&-
	exec 3<&-
	fi
	# We didn't...?
	else
	echo "0"
	fi
	}

(both on current branch master)

As you can see, what is reported by FTL is correct: The connection is just closed at the end without sending FTL the >quit command. Hence, FTL expects something more to come through the pipe and is then surprised by a suddenly closed connection.

This can be solved in two ways:

1. Terminate the connection properly (i.e., send >quit to FTL) when the connection is not needed any longer
2. Ignore the client's connection reset (as we did before FTL v5.3.3)

1 seems to be the preferred variant and is proposed in pi-hole/pi-hole#3954

[un99known99]

not fixed yet , pihole -c still showing errors

[DL6ER]

This issue is about padd which was already updated and fixed. pihole -c is fixed as well, however, the fix will only be distributed with the next release of Pi-hole.