I have installed tftp on openSuSE 10.3 and it does not work. I can connect but any get or put gives “Transfer timed out.” The directory /tftpboot is as:
This server is in a secure environment so I added the -c option to the /etc/xinetd.d/tftp file as :
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -c -s /tftpboot
disable = yes
}
This I did just to allow testing but whether the -c was there or not made no difference.
I did put one file in the directory:
-rw-r–r-- 1 root root 15 2009-02-21 03:22 test
None of this has helped. Here is what happens:
tftp localhost
tftp> status
Connected to localhost.
Mode: netascii Verbose: off Tracing: off Literal: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> get test
Transfer timed out.
tftp> put test2
Transfer timed out.
tftp> quit
I also searched the Internet but did not find an answer to the problem.
Look at that last line in your tftp config file, it says disable = yes. You have to change it to disable = no. Better still, you should have edited this in YaST under Network Services > Network Services (xinetd), then it would have been obvious that it wasn’t enabled. And of course xinetd should also be running.
You should revert all your permission changes, they are not relevant.
I don’t know why the original author of xinetd chose inverted logic, using disable instead of enable.
Talk about being to close to see the forest… That fixed the problem.
I did originally enable tftp using yast. In fact I both installed the package and enabled it using the Network Services > Network Services (xinetd). That was after I fought with vsftpd on a different suse machine in a different town to allow me to access the openSuSE DVD because somebody took it out of the machine on which I was trying to install the tftp. (I am in a different location.) I now know the option of “secure_chroot_dir” is ignored on openSuSE. It wants the anonymous in /srv/ftp.
It seems strange to me that the computer did not respond “connection refused” when tftp was disabled.
I understood that tftp was UDP but I was not aware that the original “connect” command request did not expect a reply from the other computer. The tftp command does make it appear that an exchange occurred when it replies “Connected to …” Well now I know better. I did know that tftp was a very basic operation but I rarely used it and never did any research about how it even makes a confirmation of transfer. It does use UDP to acknowledge the transfer.
I think all that the connect command in the tftp client does is resolve the domain name if any and store the IP address for future packets. Since each packet is self-contained, and no connection establishment is required, you won’t find out that the server isn’t responding until you actually attempt a transfer.
