Tftp package doesn't work but found a workaround

jimp

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.

jimp

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.

Guest

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>

jimp

and that VM can ping and otherwise talk to 192.168.1.1 without problems?

Guest

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

Guest

actually if I do

nc -uz 192.168.1.1 (any port number)

it returns succeeded :)

Guest

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 /tftpboot

But still no way (…) ???

Guest

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

jimp

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.

Guest

OK, I tried truss with pid of tftpd and same result, packets are received by the box but timeout on client side. That's interesting…

jimp

OK I figured it out. WAN gets an outbound NAT rule from 127.0.0.1 automatically, and LAN does not. So I switched to Manual Outbound NAT and added a rule on LAN from 127.0.0.1 to any, translate to Interface Address, and it started to reply.

Guest

Wow, yeah this works. Thank you so much ! ;D

jimp

I added this so I don't forget about it next week (unless someone else picks up on it before I get a chance): http://redmine.pfsense.org/issues/1528

Guest

You guys rock !
For info, I also posted this => http://forum.pfsense.org/index.php/topic,36713.0.html
Do not know if this is relevant in this forum but just to report it.

jimp

I replied there. The issue doesn't exist with the current version of the TFTP package that I have installed.

Guest

Is this the latest version trough the package installation interface ? or is there another way to install it ? Package version of TFTP I have is 2.0

jimp

2.0 sounds right, you might have to delete the package and then reinstall it, instead of just trying to upgrade it.

Cino

jimp,

I noticed that the backup/restore doesn't function anymore. Receiving a 404 error. If needed, I'll add start a new thread and report the bug on redmine.

jimp

All of the issues should be fixed now. I also added a control to the interface to select where you want it to take connections (WAN, LAN, etc) that adds the proper NAT rules (port forward, outbound nat for localhost) which should let it "Just Work" for most people.

The only thing I didn't add was a check in the code that would complain if there was a conflict with the TFTP Proxy settings. I'll add that in eventually.

soconfused

Glad to see to see some work on this package.

Another issue with this package is that clicking on the file does not actually present the file for download. I've tried this in both Chrome and Firefox. Can anyone else verify this?