#12 No route to destination, bad source UDP port number from tftp server

[Aaron Williams]

I keep getting no route to destination from my tftp clients. I have tracked down the problem to the fact that when replying to the tftp client the source port number is not 69 but some randomly generated port number. This is causing me no end of grief as I have several different TFTP clients that all fail. The response UDP packets from the TFTP server are met with ICMP destination unreachable (communication administratively filtered).
Note that I do not have any firewall support enabled and this is running on Linux. IP tables are clear. Ping and other network traffic works fine between the two machines which are connected on the same subnet into the same switch.

In my case the client is using a source port of 1006. The UDP reply packets are using a source port of 58099 instead of port 69. I believe this is the source of my problem.

[Aaron Williams]

My analysis is wrong with respect to using random source port numbers from the server. I still do not know why the Linux client is returning an ICMP destination unreachable error. This happens with both atftp and the other tftp client available in OpenSUSE 15.3.

[Andi]

Have you solved the problem? Perhaps investigate with tcpdump like (shown on localhost here, edited to make it more readable):

$ sudo tcpdump -i lo -v
tcpdump: listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
localhost.55741 > localhost.tftp: TFTP, length 27, RRQ "d-i/n-a/README.txt" octet
localhost.43854 > localhost.55741: UDP, length 177 <--- DATA
localhost.55741 > localhost.43854: UDP, length 4 <----ACK

The ports are probably not the problem: The client chooses a (client-) port and connects to the well-known tftp port 69 of the server (read request, RRQ). The servers then serves the request from a different port (to the port the request came from).