Otdfbt

I'm running tftp-server through xinetd. When I plug a client device in directly or through a switch, it boots correctly. However, I am not able to completely boot with a client device connected through a router in bridge mode. It gets the DHCP lease OK and starts downloading files, but then times out. It's not clear to me what step should be running when it times out. It actually appears to "time out" in the same second that the client finished downloading start.elf.

When I connect my laptop to the bridged router and run a traceroute on the tftp server address, it has access:

Traceroute has started…

traceroute to 192.168.10.1 (192.168.10.1), 64 hops max, 72 byte packets
 1 192.168.10.1 (192.168.10.1) 10.906 ms 5.274 ms 4.500 ms

Is there a way to better log and know which step is timing out so I know where to debug? I'm already running -v -v on the tftp executable but I can't find more information on extra logging there.

This is the output in /var/log/messages:

Apr 8 23:01:25 shepherd dnsmasq-dhcp[19671]: DHCPDISCOVER(eno1) da:0d:17:d4:30:3b
Apr 8 23:01:25 shepherd dnsmasq-dhcp[19671]: DHCPOFFER(eno1) 192.168.10.133 da:0d:17:d4:30:3b
Apr 8 23:01:25 shepherd in.tftpd[19022]: RRQ from 192.168.10.133 filename bootcode.bin
Apr 8 23:01:26 shepherd in.tftpd[19022]: Client 192.168.10.133 finished bootcode.bin
Apr 8 23:01:26 shepherd in.tftpd[19027]: RRQ from 192.168.10.133 filename bootsig.bin
Apr 8 23:01:26 shepherd in.tftpd[19027]: Client 192.168.10.133 File not found bootsig.bin
Apr 8 23:01:26 shepherd in.tftpd[19027]: sending NAK (1, File not found) to 192.168.10.133
Apr 8 23:01:26 shepherd dnsmasq-dhcp[19671]: DHCPDISCOVER(eno1) da:0d:17:d4:30:3b
Apr 8 23:01:26 shepherd dnsmasq-dhcp[19671]: DHCPOFFER(eno1) 192.168.10.133 da:0d:17:d4:30:3b
Apr 8 23:01:26 shepherd in.tftpd[19029]: RRQ from 192.168.10.133 filename 69d4303b/start.elf
Apr 8 23:01:26 shepherd in.tftpd[19029]: Client 192.168.10.133 File not found 69d4303b/start.elf
Apr 8 23:01:26 shepherd in.tftpd[19029]: sending NAK (1, File not found) to 192.168.10.133
Apr 8 23:01:26 shepherd in.tftpd[19030]: RRQ from 192.168.10.133 filename autoboot.txt
Apr 8 23:01:26 shepherd in.tftpd[19030]: Client 192.168.10.133 File not found autoboot.txt
Apr 8 23:01:26 shepherd in.tftpd[19030]: sending NAK (1, File not found) to 192.168.10.133
Apr 8 23:01:26 shepherd in.tftpd[19031]: RRQ from 192.168.10.133 filename config.txt
Apr 8 23:01:26 shepherd in.tftpd[19031]: Client 192.168.10.133 finished config.txt
Apr 8 23:01:26 shepherd in.tftpd[19032]: RRQ from 192.168.10.133 filename recovery.elf
Apr 8 23:01:26 shepherd in.tftpd[19032]: Client 192.168.10.133 File not found recovery.elf
Apr 8 23:01:26 shepherd in.tftpd[19032]: sending NAK (1, File not found) to 192.168.10.133
Apr 8 23:01:26 shepherd in.tftpd[19033]: RRQ from 192.168.10.133 filename start.elf
Apr 8 23:01:32 shepherd in.tftpd[19040]: RRQ from 192.168.10.133 filename fixup.dat
Apr 8 23:01:32 shepherd in.tftpd[19040]: Client 192.168.10.133 finished fixup.dat
Apr 8 23:01:37 shepherd in.tftpd[19033]: Client 192.168.10.133 finished start.elf
Apr 8 23:01:37 shepherd in.tftpd[19033]: Client 192.168.10.133 timed out

[adam@shepherd ~]$ cat /etc/xinetd.d/tftp
# default: off
# description: The tftp server serves files using the trivial file transfer 
# protocol. The tftp protocol is often used to boot diskless 
# workstations, download configuration files to network-aware printers, 
# and to start the installation process for some operating systems.
service tftp

 socket_type = dgram
 protocol = udp
 wait = yes
 user = root
 server = /usr/sbin/in.tftpd
 server_args = -v -v -s /tftpboot
 disable = no
 per_source = 11
 cps = 100 2
 flags = IPv4

To trace this problem you need a Wireshark traffic capture (i.e. at the TFTP server) in order to really know what's going on at packet level.