On 2016-09-28, Peer Janssen <p...@pjk.de> wrote: > # tftpd -d /tftpboot > > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out
Check your firewall rules. The packets where the file is actually transferred come from a high numbered source port: Request $high_port_A -> port 69 First file packet $high_port_B -> $high_port_A Ack $high_port_A -> $high_port_B Second file packet $high_port_B -> $high_port_A etc. I suspect you might not be allowing the return packets. Adding "log" to any "block" rules that you have and watch "tcpdump -neipflog0" probably gives you some clues.
