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

Source: tftp-hpa
Source-Version: 7.1-1

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