Tftp package doesn't work but found a workaround
-
I just attached them.
-
Just do UDP, not tcp/udp.
Also make sure you do NOT have the TFTP proxy set to listen on LAN (System > Advanced, Firewall/NAT tab).
Next week some time I can add an interface selection to add the rules automatically, and warn if the proxy is on. They'd both be adding a rule redirecting port 69, so if one is active the other wouldn't work.
-
Ok, I extended to TCP/UDP to see but now I set it back to UDP only.
TFTP proxy is not listening on any interface.
Still not working… I'm getting crazy :) anyway, thanks for your support -
It looks right otherwise… I have no trouble pulling a test file from my VM with a port forward that looks like that.
What do you get if you try this:
: grep 'port 69' /tmp/rules.debug -
rdr pass on vr0 proto udp from any to 192.168.1.1 port 69 -> 127.0.0.1 -
When I do a
telnet 127.0.0.1 69in SSH session, this should "work", isn't it ?
-
Instead of choosing "pass" for the firewall rule type, try just "none" since your LAN rule will pass it.
Telnet won't work for tftp, telnet is tcp, tftp is udp. Netcat might work, but the best test is an actual TFTP client.
-
$ nc -uz 192.168.x.y 69 Connection to 192.168.x.y 69 port [udp/tftp] succeeded! -
Wow, I deserve my "newbie" title then :)
I set it to none but still not working.
As a client, I use a vm on a esx server a try to boot the pxe way -
Upload a test file using the TFTP package GUI, and then try to retrieve it from something locally.
$ tftp 192.168.x.y tftp> get help.png Received 3157 bytes during 0.0 seconds in 7 blocks tftp> quit -
:nc -uz 127.0.0.1 69 Connection to 127.0.0.1 69 port [udp/tftp] succeeded! :nc -uz 192.168.1.1 69 Connection to 192.168.1.1 69 port [udp/tftp] succeeded!Well, it seems it works from the box itself… I don't get it ...
-
Do you have an actual tftp client you can try from another box/vm, instead of just trying a PXE boot? Also make sure the file name matches exactly what you're trying to download, case and all.
-
Also I noticed you had NAT reflection on, you might try to disable NAT reflection for that one rule using the override box on the rule editor.
-
OK I disabled the NAT reflection for this rule.
Here what I got from tftp :Setting up tftp (0.17-16) ... vm-swat:~# tftp 192.168.1.1 tftp> get BootMenu Transfer timed out. tftp> -
and that VM can ping and otherwise talk to 192.168.1.1 without problems?
-
I disabled NAT reflection at sytem level and activated it for the only rule which need it. Cool new functionality.
Yes, I checked connectivity to be sure.
I also disabled snort (only other package installed) to be sure there was not any interference or side effect -
actually if I do
nc -uz 192.168.1.1 (any port number)it returns succeeded :)
-
I tried to disable any nat reflection and have a clean /var/etc/inetd.conf looking like this :
tftp-proxy dgram udp wait root /usr/libexec/tftp-proxy tftp-proxy -v tftp dgram udp wait root /usr/libexec/tftpd tftpd /tftpbootBut still no way (…) ???
-
But if you can't reproduce the problem on your side, there might be something wrong on my box, I will work on it to check if I can go ahead. Thank you for your support. Appreciated.
By the way, here some very minor bugs I found on TFTP package, may we post directly to bug database when we find something like this ?
http://forum.pfsense.org/index.php/topic,36713.0.html -
Actually, due to the nature of my VM setups I almost exclusively try this stuff from the WAN side, and that is working, but when I boot up a VM behind that VM and try it from the LAN, that is timing out on a fetch. Guess I'll have more to look at.
tcpdump shows the packets coming in, they aren't being blocked, truss shows the inetd process responding to the request, but apparently for whatever reason the packets aren't going back out to the LAN like they should.
NAT rules are identical for WAN and LAN so it doesn't make a lot of sense.
