Tftp package doesn't work but found a workaround
-
Hi guys, I applied this workaround following these steps :
- added additional line in /etc/inetd.conf
- rebooted the box, despite I read you can make it work with /etc/rc.d/inetd onestart
And…. it doesn't work... to make it work I have to exec /etc/rc.d/inetd stop and then /etc/rc.d/inetd onestart and then it works.
If I reboot I have to do the same things. Quite strange isn't it ?Kind regards.
-
drjee,
Did you not see my post? update to a current snapshot, reinstall the tftp package and you do not need any workarounds, it just works as-is.
-
Hello,
Yes sorry I saw it. I forgot to mention that I run on 2.0RC May 12th build and re-installed the tftp package. But still not working as-is.
Did I make something wrong ? -
Odd that it doesn't work for you, I can't seem to make it fail. As long as the TFTP package is installed, it's running tftp automatically and the proper entry is in /var/etc/inetd.conf
It survives reboots and firmware upgrades/package reinstalls without problems for me. -
Quite strange… I uninstalled it and reinstalled it, still not working.
What is the difference between /var/etc/inetd.conf and /etc/inetd.conf ?
Cause workaround they find is adding a line to /etc/inetd.conf
After package install, I can see that a line for tftp is added to /var/etc/inetd.conf but it does not work... (I also checked that service was running and it is).
Only way to make it work for me is to add an entry to /etc/inetd.conf -
/etc/inetd.conf is not used by pfSense 2.0. /var/etc/inetd.conf is used by the TFTP proxy (and TFTP package).
When inetd is setup and started from filter.inc, it uses /var/etc/inetd.conf
: ps uxawww | grep inetd root 47253 0.0 0.3 9036 1508 ?? INs Thu10AM 0:00.00 /usr/sbin/inetd -wW -R 0 -a 127.0.0.1 /var/etc/inetd.conf : cat /var/etc/inetd.conf tftp-proxy dgram udp wait root /usr/libexec/tftp-proxy tftp-proxy -v tftp dgram udp wait root /usr/libexec/tftpd tftpd /tftpboot -
Thanks for your help.
Actually here is what I got on my side :
:ps uxawww | grep inetd root 11514 0.0 0.6 3436 1400 ?? Ss 9:28PM 0:00.01 /usr/sbin/inetd -wW -C 60Is there something that maybe wrong in my config for having not at all the same parameters behind /usr/sbin/inetd ?
-
If you started it manually with /etc/rc.d/inetd, it will launch the wrong one.
Kill that process, then go to Status > Filter Reload, and force a filter reload with the button there, then check if the right one is running.
-
Ok, sorry, the right one is now running, but tftp still not working.
Here is what I have in /var/etc/inetd.conf :tftp-proxy dgram udp wait root /usr/libexec/tftp-proxy tftp-proxy -v 19000 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.236 25 19000 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.236 25 19001 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.235 80 19001 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.235 80 19002 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.235 443 19002 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.235 443 19003 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.13 3074 19003 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.13 3074 19004 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.13 88 19005 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.234 3389 tftp dgram udp wait root /usr/libexec/tftpd tftpd /tftpboot -
: sockstat | grep inetd root inetd 47253 4 stream /var/run/check_reload_status root inetd 47253 6 stream /var/run/check_reload_status root inetd 47253 12 dgram (not connected) root inetd 47253 13 udp4 *:* *:* root inetd 47253 17 udp4 127.0.0.1:6969 *:* root inetd 47253 18 udp4 127.0.0.1:69 *:*That last line is tftpd. You probably need to add a port forward on LAN for port udp/69 to direct it at 127.0.0.1:69, since inetd is only listening on localhost.
-
Damn sorry…. still does not work, even after creation of nat+passing rule.
May this be due to the fact that I have manual outbound nat ? (required for xbox live to work correctly)Here are sockstat results, it seems that tftp daemon is listening
root inetd 1883 4 stream /var/run/check_reload_status root inetd 1883 6 stream /var/run/check_reload_status root inetd 1883 12 dgram (not connected) root inetd 1883 13 udp4 *:* *:* root inetd 1883 17 udp4 127.0.0.1:6969 *:* root inetd 1883 18 tcp4 127.0.0.1:19000 *:* root inetd 1883 19 udp4 127.0.0.1:19000 *:* root inetd 1883 20 tcp4 127.0.0.1:19001 *:* root inetd 1883 21 udp4 127.0.0.1:19001 *:* root inetd 1883 22 tcp4 127.0.0.1:19002 *:* root inetd 1883 23 udp4 127.0.0.1:19002 *:* root inetd 1883 24 tcp4 127.0.0.1:19003 *:* root inetd 1883 25 udp4 127.0.0.1:19003 *:* root inetd 1883 26 udp4 127.0.0.1:19004 *:* root inetd 1883 27 tcp4 127.0.0.1:19005 *:* root inetd 1883 28 udp4 127.0.0.1:69 *:* -
manual outbound nat wouldn't affect it.
Show me exactly what your port forward rule on LAN looks like.
-
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!
