tftpd responses do not seem to reach host network

[rgov]

Expected Behavior

I should be able to request files from the TFTP service.

Current Behavior

A client trying to request a file just times out with no acknowledgment from the server.

Steps to Reproduce

Run the container, publishing port 69/udp, the TFTP server.

Try to connect to the TFTP server from the host:

$ tftp 127.0.0.1 
tftp> get asdf
Transfer timed out.

Now kill the container and just create a listening netcat instance with --entrypoint /bin/sh linuxserver/netbootxyz -c 'nc -l -p 69 -u | xxd'

Run the tftp request again and note the output from the Docker container:

00000000: 0001 6173 6466 006e 6574 6173 6369 6900  ..asdf.netascii.

This proves that the UDP packet is making it into the container just fine, but the TFTP server is not acknowledging it for some reason.

Environment

OS: macOS 11
CPU architecture: x86_64
How docker service was installed: Docker for Mac

Command used to create docker container (run/create/compose/screenshot)

(Here I override the run script to just add more verbosity flags to tftpd. I also know I'm not publishing all the recommended ports, this is just for testing TFTP.)

docker run --rm -it -p 69:69/udp -v $(pwd)/config:/config -v $(pwd)/assets:/assets -v $(pwd)/run:/etc/services.d/tftp/run -e PUID=1000 -e PGID=1000 linuxserver/netbootxyz

Docker logs

I spent several hours trying to produce logs, down to even hooking calls to syslog() inside the TFTP server, but was not able to get anything to help diagnose this issue.

[aptalca]

Why are you overwriting the service file in your docker run?

Use the sample docker run and watch it work. This image has over 10 million pulls and it works just fine.

[rgov]

@aptalca To add verbosity flags, because it runs without it by default. Otherwise the command is the same.

I was able to get logs finally, and it looks like tftpd is receiving the request, but the host does not see the response:

daemon.notice: Oct  3 22:31:40 in.tftpd[545]: RRQ from 172.17.0.1 filename asdf
daemon.info: Oct  3 22:31:40 in.tftpd[545]: sending NAK (1, File not found) to 172.17.0.1

[rgov]

This may be some peculiarity with how Docker for Mac works. The container is part of the bridge network, where it gets assigned an IP address in 172.17.0.0/16. This is not actually directly connected to any interface on the macOS host, i.e., connecting to the gateway 172.17.0.1 does not connect to the host:

# host:
$ nc -l 0.0.0.0 4444

# container:
$ docker run --rm -it alpine/socat - TCP:172.17.0.1:4444
2020/10/03 22:51:46 socat[1] E connect(5, AF=2 172.17.0.1:4444, 16): Connection refused

Instead, services running on the host are reachable at host.docker.internal which for me is 192.168.65.2. So we have a problem where you can't send the response to the place it seems to originate.

Edit: I reproduced this on Linux as well. The only difference is there you can tftp 172.18.0.1 from the host and it works.

[rgov]

This might be a relevant Docker bug: moby/moby#15127 (comment)

[tobbenb]

I do not get any timeout here.

saarg@pop-os:~$ tftp 192.168.1.10
tftp> get test
Error code 1: File not found
tftp>

[thelamer]

You cannot do TFTP cli from the same host. (even through virtual networks)
I do not know the exact reason why, but you have to test from a different host on the network. (physical hardware)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vangorra]

I posted a workaround for this issue in #11

[thelamer]

TFTP file transfers most definitely work without host level networking I have multiple setups. You can next-server from the same host. I understand this makes connection issues hard/impossible to troubleshoot, but unless anyone has a solid alternative that is reliable for testing people experiencing issues need to take a look at their overall setup.

[PeterHagen]

I can't get the tftpd connection working on a MacOS machine and docker-compose setup (latest docker version). Even with the #11 fix, I still have the same issue. I also tried to use host networking, but keep getting the "Transfer timed out." messages. I guess its the udp docker networking issue that I'm running into.

For now I'm solving it with the build-in tftp server of MacOS and simlinking to the menus folder. That works, but of course not the way I would like it to be.