<div class="gmail_quote">On 12 October 2011 19:30, Tom Callaway <span dir="ltr"><<a href="mailto:tcallawa@redhat.com">tcallawa@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Okay. Your configurations are the default configs (with the notable<br>
exception of enabling the xinetd.d/tftp service).<br>
<br>
On my x86_64 laptop running Fedora 16, with iptables reasonably normal,<br>
I installed "tftp" and "tftp-server", and changed "disable = yes" to<br>
"disable = no" in /etc/xinetd.d/tftp. Then, I ran:<br>
<br>
service xinetd restart<br>
<br>
Next, I put a dummy file in /var/lib/tftpboot:<br>
<br>
echo "Hello, Fedora." > /var/lib/tftpboot/hello.txt<br>
<br>
Then, I tested a tftp connection across the loopback:<br>
<br>
[spot@pterodactyl ~]$ tftp -v localhost<br>
Connected to pterodactyl (127.0.0.1), port 69<br>
tftp> get hello.txt<br>
getting from pterodactyl:hello.txt to hello.txt [netascii]<br>
Received 16 bytes in 0.0 seconds [44990 bit/s]<br>
tftp> quit<br>
[spot@pterodactyl ~]$ cat hello.txt<br>
Hello, Fedora.<br>
<br>
Okay, that works. I'd be a bit worried if it didn't. :)<br></blockquote><div><br></div><div>Yeah this is the point where it is not working for me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Next, I tried to connect from a F-14 x86_64 machine on the same network<br>
(actually connected to the same switch too), and that worked fine:<br>
<br>
[spot@treefrog ~]$ tftp -v pterodactyl<br>
Connected to pterodactyl (XX.XX.XX.XX), port 69<br>
tftp> get hello.txt<br>
getting from pterodactyl:hello.txt to hello.txt [netascii]<br>
Received 16 bytes in 0.0 seconds [18910 bit/s]<br>
tftp><br></blockquote><div><br></div><div>My F15 laptop works fine local and remote. But I need my F15 server to do PXE as a router to the internet.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Now, I did notice a failure when I was trying to connect to the server<br>
from a VM on that separate machine. From the server logs:<br>
<br>
Oct 12 14:10:22 pterodactyl in.tftpd[8609]: tftpd: read(ack): Connection<br>
refused<br>
<br>
The client would connect, but it would not download any files.<br>
<br>
[spot@f15 ~]$ tftp -v pterodactyl<br>
Connected to pterodactyl (XX.XX.XX.XX), port 69<br>
tftp> get hello.txt<br>
getting from pterodactyl:hello.txt to hello.txt [netascii]<br>
Transfer timed out.<br>
<br>
The trick to getting the VM working was to run this command on the<br>
hypervisor level on the system where the VM was running:<br>
<br>
modprobe nf_nat_tftp<br>
<br>
And within the VM itself, run:<br>
<br>
modprobe nf_conntrack_tftp<br></blockquote><div><br></div><div>yes I have nf_conntrack_tftp loaded in the iptables-config file</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
(You could also do modprobe nf_nat_tftp here too, because that will also<br>
load nf_conntrack_tftp as a dependency, but I don't think you need<br>
nf_nat_tftp on this end. Not harmful though, just unnecessary.)<br>
<br>
Once that was done, it connected to my laptop without an issue. This<br>
makes sense, because KVM is using NAT to handle networking inside VMs.<br>
<br>
I did have issues tftp'ing between two VMs on the same system, but I<br>
don't really think that is a very sensible setup, so I didn't pursue it<br>
any farther.<br>
<br>
Just for another data point, I setup a tftp server on my F14 system and<br>
connected from my F16 laptop as a client, and it worked fine.<br>
<br>
You might be able to get useful debugging by turning off xinetd and<br>
manually launching in.tftpd in a console:<br>
<br>
sudo /usr/sbin/in.tftpd -L -v -v -v -s /var/lib/tftpboot<br></blockquote><div><br></div><div>Wow, TFTP works like this !</div><div><br></div><div>Thanks for that, now why does it not work under xinetd ?</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Then, in another console on the server, tail -f /var/log/messages and<br>
try to connect from the remote client. You might see errors like:<br>
<br>
in.tftpd[8638]: tftpd: read(ack): No route to host<br>
<br>
or<br>
<br>
in.tftpd[8613]: tftpd: read(ack): Connection refused<br>
<br>
Those usually imply a networking issue between the client and server.<br>
Having more information about how the client and server are networked<br>
together would be useful, especially if NAT is in play.<br>
<br></blockquote><div><br></div><div>No I was not getting anything in /var/log/messages from tftpd at all only that it was in the count of processes started by xinetd so it was running and connections worked.</div><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hope that helps,<br></blockquote><div><br></div><div>Thanks at least that is a hack I can use for now to get on ! </div><div><br></div><div>I would like to get to the bottom of it though !</div><div><br></div><div>Aaron</div>
<div><br></div><div><br></div></div>