[GH-ISSUE #14] TFTP sending wrong IP address #126

Open
opened 2026-03-01 18:33:23 +03:00 by kerem · 7 comments
Owner

Originally created by @derdeagle on GitHub (Mar 21, 2022).
Original GitHub issue: https://github.com/netbootxyz/docker-netbootxyz/issues/14

I currently face the issue where the TFTP server seems to answer with the wrong IP address (from Docker). I am using the default docker-compose.yml file.

10.10.0.103 is my client, 10.10.3.6 is the next-server and 192.168.192.2 is the IP address of the Docker container running netboot.xyz.
The following is the tcpdump output on the host machine (where Docker is **running).

11:53:56.340862 IP 10.10.0.103.1024 > 10.10.3.6.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:56.340922 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:56.340926 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:56.723268 IP 10.10.0.103.1024 > 10.10.3.6.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:56.723308 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:56.723315 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:57.492147 IP 10.10.0.103.1024 > 10.10.3.6.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:57.492206 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:57.492214 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:59.029670 IP 10.10.0.103.1024 > 10.10.3.6.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:59.029734 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:53:59.029743 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:54:02.106092 IP 10.10.0.103.1024 > 10.10.3.6.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:54:02.106157 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
11:54:02.106164 IP 10.10.0.103.1024 > 192.168.192.2.69:  46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0

The following is the tcpdump output on docker container itself (please don't mind the time offset).

10:53:56.340927 eth0  In  IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
10:53:56.723316 eth0  In  IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
10:53:57.492217 eth0  In  IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
10:53:59.029745 eth0  In  IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0
10:54:02.106165 eth0  In  IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0

I tried running the Docker container with network_mode: host which leads to the fact that no Docker internal IP address is shown in the TCPdump output but it fails to start fully because of nginx (I have somehting running on port 80 on the hardware server so nginx cannot bind on it).

What do I need to configure in order to get this up and running?

Originally created by @derdeagle on GitHub (Mar 21, 2022). Original GitHub issue: https://github.com/netbootxyz/docker-netbootxyz/issues/14 I currently face the issue where the TFTP server seems to answer with the wrong IP address (from Docker). I am using the default docker-compose.yml file. `10.10.0.103` is my client, `10.10.3.6` is the `next-server` and `192.168.192.2` is the IP address of the Docker container running netboot.xyz. The following is the tcpdump output on the host machine (where Docker is **running). ``` 11:53:56.340862 IP 10.10.0.103.1024 > 10.10.3.6.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:56.340922 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:56.340926 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:56.723268 IP 10.10.0.103.1024 > 10.10.3.6.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:56.723308 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:56.723315 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:57.492147 IP 10.10.0.103.1024 > 10.10.3.6.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:57.492206 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:57.492214 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:59.029670 IP 10.10.0.103.1024 > 10.10.3.6.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:59.029734 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:53:59.029743 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:54:02.106092 IP 10.10.0.103.1024 > 10.10.3.6.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:54:02.106157 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 11:54:02.106164 IP 10.10.0.103.1024 > 192.168.192.2.69: 46 RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 ``` The following is the tcpdump output on docker container itself (please don't mind the time offset). ``` 10:53:56.340927 eth0 In IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 10:53:56.723316 eth0 In IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 10:53:57.492217 eth0 In IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 10:53:59.029745 eth0 In IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 10:54:02.106165 eth0 In IP 10.10.0.103.1024 > 192.168.192.2.69: TFTP, length 46, RRQ "netboot.xyz.kpxe" octet blksize 1432 tsize 0 ``` I tried running the Docker container with `network_mode: host` which leads to the fact that no Docker internal IP address is shown in the TCPdump output but it fails to start fully because of nginx (I have somehting running on port 80 on the hardware server so nginx cannot bind on it). What do I need to configure in order to get this up and running?
Author
Owner

@ikkemaniac commented on GitHub (May 22, 2022):

I see this too, pretty logical as well as the docker container is only ware of its internal nic's if you're not in network_mode: host

That having said; no further/other configuration is need to get this up and running. As long as you fwd port 69/udp you can serve your LAN.

<!-- gh-comment-id:1133916311 --> @ikkemaniac commented on GitHub (May 22, 2022): I see this too, pretty logical as well as the docker container is only ware of its internal nic's if you're not in `network_mode: host` That having said; no further/other configuration is need to get this up and running. As long as you fwd port 69/udp you can serve your LAN.
Author
Owner

@dezeroku commented on GitHub (Mar 24, 2024):

I've had similar experience when trying to run netbooxyz containerized without host networking.
The issue here seems to be that TFTP protocol, while accepting requests on port 69, can (should?) use (by the RFC) other ports to actually send the data.
This results in ReadReQuests to pass through to the container just ok, but NAT gets confused when container tries to open connections from other ports to the same host.

A fix for that is running TFTP server in a mode where only port 69 is used for both commands and data.
While this isn't strictly RFC compliant it should work with most clients.
PR adding such capability: https://github.com/netbootxyz/docker-netbootxyz/pull/55
With this in place you'd have to set env variable TFTPD_OPTS='--tftp-single-port' and it should work.

<!-- gh-comment-id:2016668182 --> @dezeroku commented on GitHub (Mar 24, 2024): I've had similar experience when trying to run netbooxyz containerized without host networking. The issue here seems to be that TFTP protocol, while accepting requests on port 69, can (should?) use (by the RFC) other ports to actually send the data. This results in ReadReQuests to pass through to the container just ok, but NAT gets confused when container tries to open connections from other ports to the same host. A fix for that is running TFTP server in a mode where only port 69 is used for both commands and data. While this isn't strictly RFC compliant it should work with most clients. PR adding such capability: https://github.com/netbootxyz/docker-netbootxyz/pull/55 With this in place you'd have to set env variable `TFTPD_OPTS='--tftp-single-port'` and it should work.
Author
Owner

@m7les commented on GitHub (Sep 24, 2024):

For what it's worth I've had a similar problem that turned out to be due to running docker in an environment with multiple MACs and IPs - solved by running on a host with a single IP

<!-- gh-comment-id:2372270641 --> @m7les commented on GitHub (Sep 24, 2024): For what it's worth I've had a similar problem that turned out to be due to running docker in an environment with multiple MACs and IPs - solved by running on a host with a single IP
Author
Owner

@jamesbrink commented on GitHub (Nov 6, 2024):

TFTPD_OPTS='--tftp-single-port'

this merge and option fixed the issue for me on macos, thank you!

<!-- gh-comment-id:2460981959 --> @jamesbrink commented on GitHub (Nov 6, 2024): > TFTPD_OPTS='--tftp-single-port' this merge and option fixed the issue for me on macos, thank you!
Author
Owner

@DocSneider commented on GitHub (Nov 28, 2024):

TFTPD_OPTS='--tftp-single-port'

this merge and option fixed the issue for me on macos, thank you!

I had to apply the same "fix", otherwise I got a timeout error:

tftp 10.10.0.60 69
tftp> get netboot.xyz.efi
Transfer timed out.

tftp> 

Wouldn't it be better to set the TFTPD_OPTS='--tftp-single-port' by default?

Or may it be possible to add some information regarding this problem to the wiki?

<!-- gh-comment-id:2506609942 --> @DocSneider commented on GitHub (Nov 28, 2024): > > TFTPD_OPTS='--tftp-single-port' > > this merge and option fixed the issue for me on macos, thank you! I had to apply the same "fix", otherwise I got a timeout error: ```bash tftp 10.10.0.60 69 tftp> get netboot.xyz.efi Transfer timed out. tftp> ``` Wouldn't it be better to set the `TFTPD_OPTS='--tftp-single-port'` by default? Or may it be possible to add some information regarding this problem to the wiki?
Author
Owner

@diktamxx commented on GitHub (Jan 14, 2026):

Currently, we are facing the same problem.

docker run --rm \
  --name=netbootxyz \
  -p 3000:3000 \
  -p 69:69/udp \
  -p 8080:80 \
  ghcr.io/netbootxyz/netbootxyz
Image
<!-- gh-comment-id:3747476522 --> @diktamxx commented on GitHub (Jan 14, 2026): Currently, we are facing the same problem. ``` docker run --rm \ --name=netbootxyz \ -p 3000:3000 \ -p 69:69/udp \ -p 8080:80 \ ghcr.io/netbootxyz/netbootxyz ``` <img width="2532" height="1524" alt="Image" src="https://github.com/user-attachments/assets/efef82aa-f3e6-4a90-a230-93afb24e76a8" />
Author
Owner

@dezeroku commented on GitHub (Jan 14, 2026):

@diktamxx you can try to work around it by adding -e TFTPD_OPTS='--tftp-single-port' to your docker run call, this should help if it's indeed the same issue (and it looks like it is).

@DocSneider well, answering this took longer than expected, sorry 😅

Wouldn't it be better to set the TFTPD_OPTS='--tftp-single-port' by default?

It would be a bit controversial, as the single port approach is not exactly RFC compliant. I haven't had any issues with it personally, but there probably are some devices in the wild that would respond poorly to this option. I've no idea about the scale though

Or may it be possible to add some information regarding this problem to the wiki?

That sounds useful imho, I suppose that you had README.md in mind or is there something more comprehensive for this project?
Also, feel free to whip up a PR for it if you'd like

<!-- gh-comment-id:3747547777 --> @dezeroku commented on GitHub (Jan 14, 2026): @diktamxx you can try to work around it by adding `-e TFTPD_OPTS='--tftp-single-port'` to your docker run call, this should help if it's indeed the same issue (and it looks like it is). @DocSneider well, answering this took longer than expected, sorry 😅 > Wouldn't it be better to set the TFTPD_OPTS='--tftp-single-port' by default? It would be a bit controversial, as the single port approach is not exactly RFC compliant. I haven't had any issues with it personally, but there probably are some devices in the wild that would respond poorly to this option. I've no idea about the scale though > Or may it be possible to add some information regarding this problem to the wiki? That sounds useful imho, I suppose that you had README.md in mind or is there something more comprehensive for this project? Also, feel free to whip up a PR for it if you'd like
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/docker-netbootxyz#126
No description provided.