1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

TFTP Server on Advanced Tomato??

Discussion in 'Tomato Firmware' started by EDlentz, Feb 15, 2017.

  1. EDlentz

    EDlentz Network Newbie Member

    I would like to setup a TFTP server on my ASUS RTN16 with Advanced Tomato installed on it. I would need to have the TFTPboot be a usb drive. I want it to be able to serve upgrade files to IP phones that we are getting ready to send out. Is this possible??

    Thanks
     
  2. pomidor1

    pomidor1 Serious Server Member

    I have never used, but this can be found in the repository entware / opetware
    Install ng entware
    https://github.com/Entware-ng/Entware-ng/wiki/Install-on-the-TomatoUSB
    The same command system is now "entware-install.sh" you do not need to download writes in the guide itself installs as you spend this command in Terminal
    then I think that opkg install tftpd-hpa
    and then run, do not know the command search the web

    This command then the best advice in the firewall tab administration / scripts / firewall, type the command restart
     
  3. jerrm

    jerrm Network Guru Member

    dkirk and koitsu like this.
  4. EDlentz

    EDlentz Network Newbie Member

    Thanks jerrm !

    I tried just your entries but no go. I also set Option66 to the IP of the router. Here is the code I am using.

    dhcp-option=66,"192.168.1.245"
    enable-tftp
    tftp-no-fail
    tftp-root=/mnt/usbdrive/tftpboot

    I have a DHCP server scan program that shows what the DHCP server is sending with its replies and it doesn't show port 69 or the server IP. I read over the page you referenced There is a ton of options I didn't see any that others that I needed.
    The router is set to 192.168.1.245 on the wan
     
  5. jerrm

    jerrm Network Guru Member

    TFTP confirmed working under Shibby 132. I doubt any of the other options will make a difference.

    Have you tested with a tftp client?

    I don't use Shibby 133+ or AT, but doubt @Jacky444 or @shibby20 changed the build options.

    Just to be sure - you understand "usbdrive" was meant to represent whatever folder your drive is mounted under, not literally "usbdrive"?
     
  6. pomidor1

    pomidor1 Serious Server Member

    so I think - if it does not auto mount enabled it can he not mount the disk / usbdrive
    the tomato is not mounted to the mnt only nas opt etc.
     
  7. jerrm

    jerrm Network Guru Member

    I assume basic knowledge such as where/if the drive is mounted. Every thread should not become a Linux basics tutorial.
     
    koitsu likes this.
  8. koitsu

    koitsu Network Guru Member

    Why are you using dhcp option 66? Do you have systems which are PXE booting? If so, there are other flags that will be needed.

    I can confirm the TFTP server works fine on Toastman (tomato-RT-N66U_0511Toastman-RT-AC-VPN.trx). Proof is below.

    Created tftp storage directory with proper permissions:

    Code:
    root@gw:/tmp/home/root# mkdir -m 1777 /tmp/tftpboot
    
    Added to Dnsmasq Custom Configuration:

    Code:
    enable-tftp
    tftp-no-fail
    tftp-root=/tmp/tftpboot
    
    Clicked Save, then verified TFTP server portion of dnsmasq is working:

    Code:
    root@gw:/tmp/home/root# /bin/netstat -n -l | grep 69
    udp        0      0 0.0.0.0:69              0.0.0.0:*
    udp        0      0 :::69                   :::*
    root@gw:/tmp/home/root# /opt/bin/lsof -n -P -i :69
    COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
    dnsmasq 2238 nobody    6u  IPv4  11440      0t0  UDP *:69
    dnsmasq 2238 nobody    7u  IPv6  11441      0t0  UDP *:69
    
    TFTP client access on LAN, attempting to store file using PUT failed:

    Code:
    $ tftp 192.168.1.1
    tftp> debug packet
    The following debugging is enabled: packet
    
    The following debugs are available:
            packet  Packet debugging
            simple  Simple debugging
            options Options debugging
            access  TCPd access debugging
    tftp> put ibs.txt
    Sending WRQ: filename: 'ibs.txt', mode 'netascii'
    Waiting 5 seconds for packet
    Got ERROR packet: unsupported request from 192.168.1.51
    Got ERROR, aborted
    tftp>
    
    dnsmasq TFTP server log is unhelpful, seems to imply either PUT isn't supported or maybe an options negotiation issue. I'd need to look at packet captures to try and determine:

    Code:
    Feb 16 20:53:16 gw daemon.err dnsmasq-tftp[2238]: unsupported request from 192.168.1.51
    
    Tried adding tftp-no-blocksize to the dnsmasq list, to limit blocksize negotiation (only option I can see that's tweakable in the TFTP server). No change in behaviour. Removed tftp-no-blocksize.

    Next, tried GET support. First put /etc/hosts on router into /tmp/tftpboot for fetching:

    Code:
    root@gw:/tmp/home/root# cp /etc/hosts /tmp/tftpboot
    root@gw:/tmp/home/root# chmod 644 /tmp/tftpboot/hosts
    root@gw:/tmp/home/root#
    
    Then client test:

    Code:
    $ tftp 192.168.1.1
    tftp> get hosts
    Received 44 bytes during 0.0 seconds in 0 blocks
    tftp>
    
    GET seems to work, but PUT doesn't for unknown reasons. I could do packet captures and analyse, but I don't have need for this feature. Maybe dnsmasq doesn't support PUT? Ask on the dnsmasq-discuss mailing list, as this is purely a dnsmasq issue and not Tomato (AFAIK). It might also relate to file permissions on the TFTP server side, but I don't know how/why -- 1777 is insanely flexible/open, and the entire path from / upwards looks fine:

    Code:
    root@gw:/tmp/home/root# ls -ld / /tmp /tmp/tftpboot
    drwxr-xr-x   20 root     root           237 Jan  2 06:09 /
    drwxrwxrwx    9 root     root           180 Feb 16 20:48 /tmp
    drwxrwxrwt    2 root     root            60 Feb 16 20:59 /tmp/tftpboot
    
     
  9. jerrm

    jerrm Network Guru Member

    PUT won't work. dnsmasq TFTP is read only.

    The phones aren't using option 66 for booting, but simply as a path to grab auto-provisioning data and possibly firmware updates. This is very common, effectively standard, for IP phones. Newer models usually support option 43 as well. Config file names are some variation of the phone mac address.

    Read only is almost always all that is needed, but some do have an option to put log files to the tftp server.
     
    koitsu likes this.
  10. koitsu

    koitsu Network Guru Member

    In that case, GET-only support works perfectly fine. :) For deeper analysis of why something might not work (re: this post), packet captures with tcpdump + analysis with Wireshark are probably the best choice.

    One thing I did notice in said post, however, is this (underlined/bolded):

    If the above is NOT a typo and the WAN is not part of the local LAN:

    Firewall rules will not permit inbound UDP port 69 traffic to be passed via WAN port. This is by default and is proper/correct (for security reasons). dnsmasq does (as I showed in my post) listen on INADDR_ANY (any/all interfaces), so the only limiting factor is firewall. Custom firewall rules will need to be added (to Scripts -> Firewall) to allow inbound UDP port 69 traffic to hit the router itself (this cannot be done with a port forward). As described in this post in a different thread of mine (read it, don't skim it!):

    Code:
    iptables -t nat -A WANPREROUTING -p udp --dport 69 -j DNAT --to-destination :69
    iptables -A INPUT -p udp --dport 69 -j ACCEPT
    
    Let this be a lesson: it is important to describe your router configuration fully, as well as any VLAN or bridge changes, in addition to providing a physical topology diagram, when troubleshooting things of this sort. All of this matters greatly. Here is a perfect example of what should be provided.

    If the above IS a typo ("on the wan" should have read "on the lan"):

    Packet captures are the best choice to analyse what is going on. This will require Entware-ng (to install the tcpdump package) and getting familiar with something like tcpdump -vvv -p -i br0 -w /tmp/capture.pcap "udp and port 69" followed by doing tests that fail, followed by copying /tmp/capture.pcap off the router onto a machine with Wireshark where it can be opened/read for analysis.
     

Share This Page