Netboot does not work due to UDP-mapping about docker-netbootxyz HOT 15 CLOSED

After looking around a bit, I learned that TFTP establishes connections over port 69 UDP but transfers occur over an ephemeral port. I tried setting the UDP port range map in the docker config (which is used by in.tftpd) but transfers would still timeout. I'm not sure why this happens. At any rate, I worked around the issue by using the following docker compose file. This works around the issue by allowing tftp to run in host network mode (so all ports are exposed) and netboot is still using bridged.

version: "3"

# More info at https://blog.linuxserver.io/2019/12/16/netboot-xyz-docker-network-boot-server-pxe/ and https://docs.linuxserver.io/images/docker-netbootxyz
services:
  netbootxyz:
    image: linuxserver/netbootxyz:latest
    ports:
      - "3000:3000" # HTTP admin interface
      - "8080:80" # HTTP serve
    environment:
      PUID: 1026
      PGID: 100
      PORT_RANGE: 30000:30010
    volumes:
      - './container_data/netbootxyz/config:/config'
      - './container_data/netbootxyz/assets:/assets'
    restart: unless-stopped
  tftpd:
    image: stoxygen/tftpd-hpa:v1.0.0
    network_mode: 'host' # TFTP file transfers don't work without host network mode.
    volumes:
      - './container_data/netbootxyz/config/menus:/data'
    restart: unless-stopped

from docker-netbootxyz.

@phockett here's how I worked around this issue on my Synology. The easiest fix is to simply configure the builtin Synology TFTP server to serve its files from the shared folder where the netboot.xyz docker menu files are located.

In my case I configured the docker image to store config and assets in /docker/netbootxyz/config and /docker/netbootxyz/assets, respectively. I didn't expose UDP port 69 on the docker container (since I want the Synology to handle that), and finally pointed the builtin Synology TFTP server to serve its content from /docker/netbootxyz/config/menus. That's all that was needed to get everything working.

Now the Synology takes care of all the TFTP stuff and the netboot.xyz webapp is used to manage the app (via exposed port 3000) and serve local assets (via exposed port 8080). No need to use host networking. Bridge networking works just fine with this setup.

from docker-netbootxyz.

Thanks @crahan - definitely also a viable solution/work-around/configuration, although doesn't address the underlying issue with the docker-compose configuration of course... and the fact/hope that Docker should make this super-simple, and platform independent, on the user end. (Probably some wishful thinking on my part there ;) )

from docker-netbootxyz.

I think you are jumping to conclusions as to why you are having a problem.
This container has 3 million pulls and outside of my local deployment I know of hundreds of other functional deployments.
Your troubleshooting and conclusion would indicate that this container is non functional which is not true.

In any case I do not believe this is a bug report or feature request, please hop on netboot.xyz or linuxsever discord/discourse for help setting up this container in your specific network.

from docker-netbootxyz.

@neerdoc Thank you so much for providing this solution! I get to go to sleep now.

It seems like this issue might be dependent on the router/router settings. When I was using UniFi UDM Pro, I just followed the instructions. However, with my slightly less forgiving pfSense set up, the only thing that got it working was adding this setting (and updating the docker-compose version number to 3.7).

from docker-netbootxyz.

@thelamer I think this might have something to do with PnP settings on the router... not sure though. If there really are millions of users, I'm sure plenty of them (especially ones with strict firewall settings) are going to have this issue... I think you should add it to the documentation

from docker-netbootxyz.

Struggle a while thinking it's my network !

But the official example on the documentation is wrong. It can't work with docker bridge just by mapping the port 69. You also have to open others ports (-p 65500-65515:65500-65515/udp) or set-up the network_mode: 'host'

See: https://serverfault.com/questions/1020874/cant-connect-to-tftp-docker-container

thanks @vangorra for the workaround

from docker-netbootxyz.

@lpyparmentier are you sure those are the only required ports? I thought it used any ephemeral port

from docker-netbootxyz.

Not at all :)

from docker-netbootxyz.

IIRC, Netboot.xyz uses a wide range of ports.. like PnP status.

from docker-netbootxyz.

@thelamer --- I think you should reopen this issue. A fix could be to force Netboot.xyz to use a smaller set of ports instead of forcing Docker users to pass every single ephemeral port to the Netboot.xyz container. network_mode: host works because it acts like a DMZ which can cause issues for users who host anything else on the puter.

When I was debugging this, I saw Netboot.xyz using a very wide range of ports in pfSense.

from docker-netbootxyz.

In fact, I think i've talk a little bit too fast... sorry

I've installed tftpd-hpa to replace the tftpd service provided by the container. And it works locally, but not on other machines. So I came back with the docker-compose provided by the documentation and I'm stuck with the same issue that having having the service without docker.

For now all i'm seeing is that i've bad udp chksum on the ephemeral port (data exchange):

# get ephemeral port (32769)
root@rockpi4-services:/mnt/nvme/netboot# tcpdump udp port 69 -vv -X
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:38:48.805346 IP (tos 0x0, ttl 64, id 42471, offset 0, flags [DF], proto UDP (17), length 62)
    192.168.4.126.32769 > 192.168.4.146.tftp: [udp sum ok]  34 RRQ "menus/netboot.xyz.kpxe" netascii
        0x0000:  4500 003e a5e7 4000 4011 0a67 c0a8 047e  E..>..@[email protected]...~

# listen the port (32769)
root@rockpi4-services:/mnt/nvme/netboot# tcpdump udp port 32769 -vv -X
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:38:56.812520 IP (tos 0x0, ttl 64, id 32299, offset 0, flags [none], proto UDP (17), length 544)
    192.168.4.146.39184 > 192.168.4.126.32769: [bad udp cksum 0x8c7e -> 0x084f!] UDP, length 516
        0x0000:  4500 0220 7e2b 0000 4011 7041 c0a8 0492  [email protected]....
        0x0010:  c0a8 047e 9910 8001 020c 8c7e 0003 0001  ...~.......~....
        0x0020:  ea05 00c0 0766 9c66 600f a80f a006 1e66  .....f.f`......f
        0x0030:  684c 5245 542e 8c16 2105 2e66 8926 1d05  hLRET...!..f.&..

Command used on the client:

tftp> root@rock64-home:/tmp# echo "get menus/netboot.xyz.kpxe" | tftp 192.168.4.146
tftp> Transfer timed out.

And no data on the router, so everything happen on the switch (layer 2). No idea how to deal with that.

EDIT: funny thing, if i put a non existing filename, I clearly see the answer 'File.not.found' in tcpdump and bad udp cksum also:
request:

tftp> root@rock64-home:/tmp# echo "get mnetboot.xyz.kpxe" | tftp 192.168.4.146
tftp> Transfer timed out.

tcpdump on the tftp host:

root@rockpi4-services:/mnt/nvme/netboot# tcpdump udp port 39036 -vv -X
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:55:20.505413 IP (tos 0x0, ttl 64, id 34641, offset 0, flags [DF], proto UDP (17), length 57)
    192.168.4.126.39036 > 192.168.4.146.tftp: [udp sum ok]  29 RRQ "mnetboot.xyz.kpxe" netascii
        0x0000:  4500 0039 8751 4000 4011 2902 c0a8 047e  E..9.Q@.@.)....~
        0x0010:  c0a8 0492 987c 0045 0025 cc4f 0001 6d6e  .....|.E.%.O..mn
        0x0020:  6574 626f 6f74 2e78 797a 2e6b 7078 6500  etboot.xyz.kpxe.
        0x0030:  6e65 7461 7363 6969 00                   netascii.
19:55:20.511835 IP (tos 0x0, ttl 64, id 27138, offset 0, flags [none], proto UDP (17), length 47)
    192.168.4.146.36205 > 192.168.4.126.39036: [bad udp cksum 0x8a8d -> 0x0e76!] UDP, length 19
        0x0000:  4500 002f 6a02 0000 4011 865b c0a8 0492  E../j...@..[....
        0x0010:  c0a8 047e 8d6d 987c 001b 8a8d 0005 0001  ...~.m.|........
        0x0020:  4669 6c65 206e 6f74 2066 6f75 6e64 00    File.not.found.

So I don't understand why I get transfer time out... does the kernel drop the packet due to bad cksum ? some suggestions ?

EDIT2:

Works perfectly with ipv6 (udp6) and network_mode: host, but i'm still stuck with ipv4 (time out). Certainly related with the missing module nf_conntrack_tftp on my OpenWRT router (edgerouterx).

from docker-netbootxyz.

Thanks @vangorra , this fix worked for me too.

@lpyparmentier, @ProfessorManhattan I'm still quite new to Docker, but agreed that it seems that the original docker-compose configuration would never work otherwise, unless Docker defaults to host networking in some/many/most cases(?). For reference, I'm running the container on a Synology NAS (DSM 6.2.4-25556, with Docker 20.10.3-0554) and had exactly the same tftp timeout at netboot.xyz.kpxe loading as the OP. My router is an Asus RT-AC68U with Merlin firmware, and configured for TFTP/PXE as per the docker-netbootxyz DD-WRT guide.

I tried setting the UDP port range map in the docker config (which is used by in.tftpd) but transfers would still timeout.

I didn't dig into the port mappings in detail to see which ephemeral ports were used in the end in my case, but did quickly test just mapping the additional ports specified by PORT_RANGE in the compose file - this didn't fix the problem, although presumably (?) there should be a way to enforce this within the container tftp instance.

@thelamer Kudos for maintaining all this... is there something else I could provide to help debug this since, as you point out, it seems to work without issue for many other people...?

from docker-netbootxyz.

I was pulling my hair out over this issue. Running docker in an Ubuntu VM on a Windows 11 host through either Hyper-V or VMWare player using external networking (VM is able to share host network adapter and get it's own IP address).

I was using the built in TFTP client in Windows (11), and it would time out every time. After using WireShark to do a packet capture, it appeared that the initial file request succeeded and the TFTPD server kept sending back Block 1 of the file over and over. The reply from the client was missing, which would have signaled the server to send Block 2, Block 3, etc.

However, it looks like this might be some sort of incompatibility between tftpd-ha and the windows built in TFTP client as I tried to accomplish a PXE boot at this point at it worked as expected without any changes to the docker compose file.

Edit: I initially thought it was the network mode being set to host, but that had nothing to do with the fix. It was what looked like a Windows built in TFTP client issue.

from docker-netbootxyz.

I'm here with the same thing, but the problem only appears in EFI pxe. I'm thinking on moving the TFTP server to another server, even when that is crippling the entire idea of unification. I've moved the http server to allow an automatic proxy of any unavailable file so that is something else...

from docker-netbootxyz.