Your message dated Sun, 27 Sep 2026 15:03:42 +0200 with message-id <[email protected]> and subject line Re: Bug#927872: tftpd-hpa: Fails to serve any files when started with systemd on stretch has caused the Debian Bug report #927872, regarding tftpd-hpa: Fails to serve any files when started with systemd on stretch to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 927872: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927872 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: tftpd-hpa Version: 5.2+20150808-1+b1 Severity: important Dear Maintainer, On a fresh install of tftpd I discovered it was not serving files (timeout from the client end). Changing the address sessing in /etc/default/tftpd-hpa from "TCP_ADDRESS=0.0.0.0:69" to "TCP_ADDRESS=:69" (and systemctrl restart tftpd-hpa) started it working. Netstat reports in.tftpd listening on '0.0.0.0:69' in both cases. sustemd (systemctl status tftpd-hpa) confirms that the command run to start the service has changed from '--address 0.0.0.0:69' to '--address :69'. I tried explicitly setting the ip to one interface ('192.168.0.1:69') in /etc/default/tftpd-hpa and it did start working on that one address - unfortunately it stopped working on loopback (127.0.0.1) and I need to to listen on other networks, so this isn't a solution for me. Why changing '0.0.0.0:69' to just ':69' affects the behaviour of the service is something I do not understand, but out-of-the-box this package appears broken. This is all on an IPv4 set of addresses, as explained, so it does not appear to be the issue that 0.0.0.0:69 isn't going to match IPv6. The service starts and no errors are logged. With tcpdump I can see the REQ coming into the system, when the listen address is configured to '0.0.0.0:69' but no response. With it configured to ':69' it seems to function perfectly. I tried removing the TCP_ADDRESS option entirely (both by commenting and setting it to a blank string) but the service failed to start when I did that (systemctl (re)?start tftpd-hpa fails with an error). My system is fully up to date. Regards, Laurence -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tftpd-hpa depends on: ii adduser 3.115 ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u4 ii libwrap0 7.6.q-26 tftpd-hpa recommends no packages. Versions of packages tftpd-hpa suggests: ii pxelinux 3:6.03+dfsg-14.1+deb9u1 -- debconf information: tftpd-hpa/options: --secure tftpd-hpa/address: 0.0.0.0:69 tftpd-hpa/directory: /srv/tftp tftpd-hpa/username: tftp
--- End Message ---
--- Begin Message ---Source: tftp-hpa Source-Version: 7.1-1 On Wed, Apr 24, 2019 at 01:15:53PM +0100, Laurence Alexander Hurst wrote: > On a fresh install of tftpd I discovered it was not serving files > (timeout from the client end). Changing the address sessing in > /etc/default/tftpd-hpa from "TCP_ADDRESS=0.0.0.0:69" to "TCP_ADDRESS=:69" > (and systemctrl restart tftpd-hpa) started it working. This sounds like a service ordering issue. Anyway since 7.1-1 the service uses systemd socket activation, and this problem should be solved. Best, Chris
--- End Message ---
