Unable to establish TLS connection after some time

[dmaltsiniotis]

Versions

• Core version is v6.4 (Latest: v6.4)
• Web version is v6.4.1 (Latest: v6.4.1)
• FTL version is v6.5 (Latest: v6.5)

Platform

• OS and version: Debian Bookworm 12.13
• Platform: Raspberry Pi

Also Same behavior observed on backup instance:

• OS and version: Debian forky/sid
• Platform: Docker

Expected behavior

The web interface is accessible via https, and DNS queries respond.

Actual behavior / bug

After some period of time ranging from a few hours to a day, the web interface becomes unreachable due to a TLS handshake error over https. This is not an untrusted/self-signed cert issue, the FTL web server is sending a connection close packet right after the server/client cipher exchange during the TLS handshake. I can provide packet captures of good vs. bad sessions.

Steps to reproduce

Steps to reproduce the behavior:

1. Go to the web interface URL in any browser
2. See error

Debug Token

• URL: https://tricorder.pi-hole.net/1PAb9bqv/

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

This has occurred on two separate hardware platforms and systems running the same version. Restarting the FTL service resolves the issue for a period of time before it comes back. I've also noticed in some cases DNS request also stop responding (either that or the dashboard just doesn't show logs/history for the time it was "down".

Side note: In the debug logs, the name resolution failure for public DNS is expected, external DNS is blocked on this network.

[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)

[rdwebdesign]

Steps to reproduce the behavior:

• Go to the web interface URL in any browser

I can't replicate using the latest docker image and no one else complained about a similar issue.
I suspect something else is causing this issue. Let's check:

• please include your compose file or docker run command used to start the container;
• Can you please also generate a debug log for your Bookworm installation?
• Are you using a reverse proxy? If you are, please explain your settings.

[metal-mark]

This sounds remarkably like the symptoms I have been seeing with the issue I commented on here: #2786 (comment)

Like you after some time FTL seems to hang and Firefox reports a TLS connection error. Restarting FTL seems to bring it back and it may go days before it happens again.

[dmaltsiniotis]

Hi @rdwebdesign,

See below for the Docker compose file I am using in this instance. I have also generated a debug file from the bookworm instance running on a Raspberry Pi (it has a nearly identical but fairly straightforward configuration): https://tricorder.pi-hole.net/IAHvHUir/

No reverse proxy is in use here, I am directly connecting to the container, or in the case of the Pi, directly to the hardware.

Thank you!

@metal-mark This is interesting, it does feel like there is some odd hanging that started specifically with FTL 6.5. I have not tried downgrading yet to see if I gain some stability as I am trying to catch the error live so I can gather information.

Here is the compose file I am using:

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      # DNS Ports
      - "53:53/tcp"
      - "53:53/udp"
      # Default HTTP Port
      - "8053:80/tcp"
      # Default HTTPs Port. FTL will generate a self-signed certificate
      - "44353:443/tcp"
      # Uncomment the line below if you are using Pi-hole as your DHCP server
      #- "67:67/udp"
      # Uncomment the line below if you are using Pi-hole as your NTP server
      #- "123:123/udp"
    environment:
      # Set the appropriate timezone for your location (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones), e.g:
      TZ: 'America/Chicago'
      # Set a password to access the web interface. Not setting one will result in a random password being assigned
      FTLCONF_webserver_api_password: '<REDACTED>'
      # If using Docker's default `bridge` network setting the dns listening mode should be set to 'all'
      FTLCONF_dns_listeningMode: 'all'
    # Volumes store your data between container upgrades
    volumes:
      # For persisting Pi-hole's databases and common configuration file
      - './etc-pihole:/etc/pihole'
      # Uncomment the below if you have custom dnsmasq config files that you want to persist. Not needed for most starting fresh with Pi-hole v6. If you're upgrading from v5 you and have used this directory before, you should keep it enabled for the first v6 container start to allow for a complete migration. It can be removed afterwards. Needs environment variable FTLCONF_misc_etc_dnsmasq_d: 'true'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    cap_add:
      # See https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
      # Required if you are using Pi-hole as your DHCP server, else not needed
      #- NET_ADMIN
      # Required if you are using Pi-hole as your NTP client to be able to set the host's system time
      #- SYS_TIME
      # Optional, if Pi-hole should get some more processing time
      - SYS_NICE
    restart: unless-stopped

[DL6ER]

metal-mark has confirmed the same symptoms in #2786 - this may truly have the same underlying issue. Both reports point to FTL v6.5 as the starting version.

@dmaltsiniotis Could you try switching to the development branch (I think using nightly tag is the trick for docker) so we can get a backtrace if a crash happens? It also includes a fix for a separate bug that prevented running FTL under a debugger.

If the TLS hang happens again without a visible crash in the FTL log, that's also useful information - please let us know.

[dmaltsiniotis]

metal-mark has confirmed the same symptoms in #2786 - this may truly have the same underlying issue. Both reports point to FTL v6.5 as the starting version.

@dmaltsiniotis Could you try switching to the development branch (I think using nightly tag is the trick for docker) so we can get a backtrace if a crash happens? It also includes a fix for a separate bug that prevented running FTL under a debugger.

If the TLS hang happens again without a visible crash in the FTL log, that's also useful information - please let us know.

No problem, I'm on the nightly tag now and will report back when the issue manifests. From the previous "crashes" at least in my case there was no segfault or restart in the logs, they seemed normal/quiet.