Tftp package doesn't work but found a workaround
-
Noticed the same issue and implemented the same solution.
Frustrating 30 minutes, but I guess that's the way it goes when playing with RCs.
I didn't this listed in the current issues, nor a way to report new ticket. Can we get this added an save future users our headaches?
Thanks for this great product!
-
I just committed an updated TFTP package for 2.0, though it requires a change I just committed to 2.0 also. So if you update to a snapshot tomorrow and then reinstall the package, the tftpd daemon should be started as expected via inetd.
-
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 ?
