• It could just be my box but i've seen some topics that tftp isn't working on 2.0. The topics were old so I figured i would start a new one.

    I install the tftp package on build 2.0 BETA5 (i386) built on Wed Feb 2 04:04:51 EST 201.

    Add some files to the tftpboot dir to test PXE booting.. My client timeout trying to connect via tftp.

    I looked at the /etc/inetd.conf and noticed that the tftp service wasn't defined. So I added it under the tftp-proxy service.

    tftp-proxy	dgram	udp	wait	root	/usr/libexec/tftp-proxy	tftp-proxy
    tftp	dgram	udp	wait	root	/usr/libexec/tftpd	tftpd /tftpboot
    

    rebooted the box and tftp is working. I could had commented out the tftp-proxy since i don't use it but figured it wasn't hurting anything.

    Hope this can be fixed via package but i have it working for now…

    Edit: You lose the this setting after a firmware update


  • Thanks for this, I found this hint useful.
    You don't need to reboot, you can also just say a command "/etc/rc.d/inetd onestart"


  • Thank you very much.. my TFTP server is now working..


  • 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!

  • Rebel Alliance Developer Netgate

    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 :

    1. added additional line in /etc/inetd.conf
    2. 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.

  • Rebel Alliance Developer Netgate

    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 ?

  • Rebel Alliance Developer Netgate

    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

  • Rebel Alliance Developer Netgate

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

    Is there something that maybe wrong in my config for having not at all the same parameters behind /usr/sbin/inetd ?

  • Rebel Alliance Developer Netgate

    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
    
    
  • Rebel Alliance Developer Netgate

    : 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          *:*
    
    
  • Rebel Alliance Developer Netgate

    manual outbound nat wouldn't affect it.

    Show me exactly what your port forward rule on LAN looks like.


  • I just attached them.




  • Rebel Alliance Developer Netgate

    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

  • Rebel Alliance Developer Netgate

    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 69
    

    in SSH session, this should "work", isn't it ?

  • Rebel Alliance Developer Netgate

    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.

  • Rebel Alliance Developer Netgate

    $ 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

  • Rebel Alliance Developer Netgate

    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 ...

  • Rebel Alliance Developer Netgate

    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.

  • Rebel Alliance Developer Netgate

    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>
    
    
  • Rebel Alliance Developer Netgate

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

    But 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

  • Rebel Alliance Developer Netgate

    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.


  • 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…

  • Rebel Alliance Developer Netgate

    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.


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