On 10/11/2011 01:46 PM, Aaron Gray wrote: I assume you mean "TFTP server", here. Can you attach copies of the relevant config files and any errors that show up in the logs (server or client side)? ~tom == Fedora Project

On Tue, 2011-10-11 at 21:22 +0100, Aaron Gray wrote: Is your issue similar to: https://bugzilla.redhat.com/show_bug.cgi?id=739534 ?

On 11 October 2011 18:49, Tom Callaway <tcallawa(a)redhat.com&gt; wrote: Configuration files attached, if you need any others just ask. AFAICT (by using my F15 laptop on which TFTP is working fine) both client and server are failing and causing time outs on my desktop F15 machine running new Gnome 3 desktop. No packets are transferred so it is not like bug 739534<https://bugzilla.redhat.com/show_bug.cgi?id=739534> [root@XXXX ang]# netstat -a -n -p --ip|grep xinetd udp 0 0 0.0.0.0:69 0.0.0.0:* 1118/xinetd I have tried disabling both iptables and sellinux. [root@XXXX ang]# tail /var/log/messages Oct 12 14:17:29 gold xinetd[1118]: Exiting... Oct 12 14:18:19 gold xinetd[2886]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in. Oct 12 14:18:19 gold xinetd[2886]: Started working: 2 available services rsync (the other service) appears to be working correctly. Anything else you need just shout. Many thanks for looking into this, Aaron

Okay. Your configurations are the default configs (with the notable exception of enabling the xinetd.d/tftp service). On my x86_64 laptop running Fedora 16, with iptables reasonably normal, I installed "tftp" and "tftp-server", and changed "disable = yes" to "disable = no" in /etc/xinetd.d/tftp. Then, I ran: service xinetd restart Next, I put a dummy file in /var/lib/tftpboot: echo "Hello, Fedora." > /var/lib/tftpboot/hello.txt Then, I tested a tftp connection across the loopback: [spot@pterodactyl ~]$ tftp -v localhost Connected to pterodactyl (127.0.0.1), port 69 tftp> get hello.txt getting from pterodactyl:hello.txt to hello.txt [netascii] Received 16 bytes in 0.0 seconds [44990 bit/s] tftp> quit [spot@pterodactyl ~]$ cat hello.txt Hello, Fedora. Okay, that works. I'd be a bit worried if it didn't. :) Next, I tried to connect from a F-14 x86_64 machine on the same network (actually connected to the same switch too), and that worked fine: [spot@treefrog ~]$ tftp -v pterodactyl Connected to pterodactyl (XX.XX.XX.XX), port 69 tftp> get hello.txt getting from pterodactyl:hello.txt to hello.txt [netascii] Received 16 bytes in 0.0 seconds [18910 bit/s] tftp> Now, I did notice a failure when I was trying to connect to the server from a VM on that separate machine. From the server logs: Oct 12 14:10:22 pterodactyl in.tftpd[8609]: tftpd: read(ack): Connection refused The client would connect, but it would not download any files. [spot@f15 ~]$ tftp -v pterodactyl Connected to pterodactyl (XX.XX.XX.XX), port 69 tftp> get hello.txt getting from pterodactyl:hello.txt to hello.txt [netascii] Transfer timed out. The trick to getting the VM working was to run this command on the hypervisor level on the system where the VM was running: modprobe nf_nat_tftp And within the VM itself, run: modprobe nf_conntrack_tftp (You could also do modprobe nf_nat_tftp here too, because that will also load nf_conntrack_tftp as a dependency, but I don't think you need nf_nat_tftp on this end. Not harmful though, just unnecessary.) Once that was done, it connected to my laptop without an issue. This makes sense, because KVM is using NAT to handle networking inside VMs. I did have issues tftp'ing between two VMs on the same system, but I don't really think that is a very sensible setup, so I didn't pursue it any farther. Just for another data point, I setup a tftp server on my F14 system and connected from my F16 laptop as a client, and it worked fine. You might be able to get useful debugging by turning off xinetd and manually launching in.tftpd in a console: sudo /usr/sbin/in.tftpd -L -v -v -v -s /var/lib/tftpboot Then, in another console on the server, tail -f /var/log/messages and try to connect from the remote client. You might see errors like: in.tftpd[8638]: tftpd: read(ack): No route to host or in.tftpd[8613]: tftpd: read(ack): Connection refused Those usually imply a networking issue between the client and server. Having more information about how the client and server are networked together would be useful, especially if NAT is in play. Hope that helps, ~tom == Fedora Project

On 10/12/2011 06:37 PM, Aaron Gray wrote: I have no idea. xinetd should be spawning off the equivalent of: /usr/sbin/in.tftpd -s /var/lib/tftpboot You can add the -v (for verbosity) to /etc/xinetd.d/tftp (same line as the -s /var/lib/tftpboot), but don't add the -L (man in.tftpd will explain why that is incorrect). If you can't localhost connect to your tftp server, you have bigger issues, and I don't think they involve tftp. ~tom == Fedora Project