Setting up a TFTP server for TFTP Recovery/Install

WARNING : TFTP server & client tool (based on TFTP protocol) utilize much lesser (or almost no) security, to make sure low level data transfer can occur easily between network devices (in the hand of user who have network devices & computer in front of him/her). So access to TFTP-client (tftp) and TFTP-Server (tftpd) tool/app must be made secure, from (primarily) hackers in internet (and TFTP-Server & Client both must also be kept securely isolated from harmful/ignorant internal users or from hijacked computers, inside your own LAN network). If necessary, create a separate subnet under a 2nd level router, then work / develop / troubleshoot under that separate subnet with network devices which will handle TFTP client/server protocols. If your computer is also used as a desktop computer for general purpose or for other purpose than build/compile, then make sure TFTP-client & TFTP-server, both are placed behind a firewall (frwl) system or rules1, 2, firewall rules should be: (frwl rule # 1) allow TFTP traffic when connections originated from local LAN ip.address range and also ended into local LAN ip.address range, (frwl rule # 2) TFTP traffic is Not-Allowed when it is from/to or lo, (frwl rule # 3) TFTP traffic is Not-Allowed when originated from Internet-ip-address (aka: NON private-LAN ip-address ranges), And you must also make sure to do this: after your develop / troubleshooting etc work is done or when you pause to goto other work, then make sure the TFTP-server and TFTP-client both are completely disabled in your OS/distro : turn off TFTP-Server service / process, disable TFTP-server startup script file, and move the TFTP-client (tftp) & the TFTP-server (tftpd) executable / binary (bin) files out of all folders mentioned in your PATH variable, into a different folder (which is NOT in the PATH variable), and also move bin files out of the folder which is mentioned in startup-script (if such is used). If you keep TFTP-Server running or if you keep the TFTP-client tool available to run anytime, then abusive hackers can abuse/exploit it, to load harmful firmware and/or to change sensitive security settings inside your existing router firmware1, 2, 3, 4, 5, 6, etc.

On most devices, the vendor provided boot loader is a partition separated from the actual firmware. In case of a failed flash process or in case of a misconfiguration, the device's boot loader usually is still untouched and fully working. It the boot loader has a built-in “TFTP recovery mode”, it enables to regain control of a device with a broken firmware partition, by allowing a recovery flash process (which will also reset your configuration to the device defaults).

For many routers the recovery works by starting a TFTP server on your computer. Then device with the broken firmware has to be started up in TFTP recovery mode. Some devices then will pull the network-provided firmware file over TFTP network protocol to the OpenWrt and hopefully recover with a successful emergency flash process.

Some devices do not have automatic pull function and they need manual TFTP copy commands in recovery mode to get firmware from TFTP and firmware install.

NOTE: Some other routers, e.g. many Netgear routers, have TFTP server on themselves, and the PC needs to act as TFTP client. The “TFTP recovery mode” can also mean that, so look carefully at info about your router to find out which method your router possibly supports.

The below article mainly advises on the “TFTP client at router” recovery.

TFTP recovery over Ethernet is not supported by every router model. TFTP recovery is based on a device- and vendor-specific boot loader that may or may not be present on your device. Check the OpenWrt device page for your precise model to find out, if your device has a boot loader supporting TFTP recovery. If your device supports it, then this recovery function will still be present in your device boot loader, after OpenWrt firmware has been flashed onto the device.

● Your device boot loader could alternatively have implemented TFTP recovery over serial cable, which is not covered on this page.
● Your device could also have other means of recovery.

The following procedure only describes how to set up a TFTP server over Ethernet for the TFTP recovery/install preparation process, it does not describe the device-specific flash recovery/install process. For the actual flash process you have to consult the vendor provided documentation, the Internet, the OpenWrt Forum or the OpenWrt device pages.

  1. Download the desired OpenWrt (or stock) firmware image to the designated TFTP directory on your computer (and rename it if needed).
  2. Set the IP address of your computer's Ethernet interface as described in the Device Page for your model.
  3. Start the TFTP server on your computer.
  4. Connect your computer and your device with Ethewnet cable.
  5. Power up the router and press a device-specific button to start firmware recovery over TFTP,
  6. or access boot loader recovery options and install recovery firmware over TFTP.

macOS provides a native tftpd server that runs the command line. However, it is not verified to work on recent versions (10.15.x). So alternative option-1 is: use dnsmasq instead. Alternative option-2 is: use MacPorts (or other) package-manager & obtain tftpd server & dnsmasq, more info is here: buildroot.exigence.macosx. There are also GUI (frontend/wrapper) applications (for CLI based tftp, tftpd tools) that are available for users who prefer such, (in example: There are also GUI based tftp & tftpd app, (in example:

dnsmasq (on macOS):

Dnsmasq can be installed easily via Homebrew or MacPorts and has the advantage of being able to offer a DHCP server if necessary.

● Launch it in this way (if you use Homebrew pkg-mngr):

 $ sudo /usr/local/opt/dnsmasq/sbin/dnsmasq -i enX -p 0 -z --enable-tftp --tftp-root /tmp 

● Launch it in this way (if you use MacPorts pkg-mngr):

 $ sudo /opt/local/sbin/dnsmasq -i enX -p 0 -z --enable-tftp --tftp-root /tmp 

Replace enX with the interface identifier of your ethernet adapter (use ifconfig to find it out) and /tmp to the directory containing the image you want to serve. Don't forget to kill the process (e.g. using the Activity Monitor) before you want to start a new instance of dnsmasq.

macOS Command-Line Native tftpd:

For recent versions of macOS, the system-supplied tftpd is managed with launchctl. Users should be comfortable with command-line usage and sudo to take this approach. As confirmed on macOS Sierra 10.12.6 and macOS Mojave 10.14.2, the general steps involved are

● Configure your network interface for the proper server address for your device. Using System Preferences > Network is perhaps the easiest.
● Connect your device to the network interface
● Start tftpd

$ sudo cp path/to/file/to/serve.bin /private/tftpboot/the_name_the_device_is_looking_for.bin
$ sudo launchctl load -F /System/Library/LaunchDaemons/tftp.plist 

● Confirm tfptd is running by looking for the UDP listener on port 69

$ netstat -an | fgrep \*.69    
udp4       0      0  *.69                   *.*                               

● Activate your device's recovery/TFTP mode

  • When done with tftpd, shut it down with
     $ sudo launchctl unload -F /System/Library/LaunchDaemons/tftp.plist (on macOS):

As an example of a GUI wrapper (aka: frontend) based TFTP server, the from provides a pleasant GUI frontend / wrapper around macOS native command that makes the process less error prone. Info from older site on usage of this app is here.

  • This procedure was tested with v 3.4.1 on OSX 10.10.5 in December 2016.
  • The v3.4.1 TftpServer.dmg file has SHA256: eb71d62da9c0dd6cdf54d604e87083e1a4e7084f8da4bc4e8c196da19e012583 & size: 656,775 bytes, and the “” has 731,378 bytes. DMG file contains APP file. We found mention of updated version v3.5.1 on author's older website via Internet Archive Wayback Machine, obtained on April 27, 20201.
  • Author's contact info: (remove the .nospam portion & remove the 5, to get author's actual email address) or (remove the .spamnotallowed portion & remove the 1, to get author's actual email address).
  1. Download dmg file from the URL1 mentioned above, and install the inside that dmg file. Do not download this app or dmg file from any untrustworthy websites. Do not download unknown version or “new” versions, that is not-shared or not-mentioned by actual author.
  2. Move the application to a convenient directory.
  3. In the same directory, create another folder named 'tftpfiles'. This is the 'designated TFTP directory'. and tftpfiles will be in the same directory.
  4. Set the OSX IP address as specified in the Device Page's TFTP Recovery section.
  5. Launch The window is shown here. You should confirm that you see the desired file named in the window.
  6. Click “Start TFTP” (upper left). You should see the “Server Status:” change to “Running”.
  7. Start your router and press the button. The file will transfer.
  8. Note: may give warnings about file permissions. Use the “Fix” buttons at the bottom of the window to set the permissions properly.
  9. Click “Stop TFTP” or quit the application to stop the TFTP server.
  10. Precautions : keep this app firewalled (and allow only LAN based TFTP), or disable this app when you are done working with TFTP, or disable this app when you pause to goto other work. Do not keep this app continuously running. (on macOS):

This app has GUI interface and also contains builtin TFTP server & client functionalities, it can be obtained from website. Dnld, Src, Tech description here, Help file here.

  • It is developed by Michael Krelin ( , remove the .nospam portion & remove the 5, to get author's actual contact info ).
  • The pumpkin-0.0.1-osx.dmg file has SHA256: 0f857db4ae91907946cfc050f72a17714524d3380fb1e8bc8cb25acfd5f83a67 & size: 796,711 bytes, and the size: 876,994 bytes.
  • Precautions : keep this app firewalled (and allow only LAN based TFTP), or disable this app when you are done working with TFTP, or disable this app when you pause to goto other work. Do not keep this app continuously running.

Tools/Pkgs via Pkg-Mngr (on macOS):

macOS compatible (3rd-party) pkg-mngr (package-manager) info is displayed in buildroot.exigence.macosx page, inside Install Package Manager section.

if you have MacPorts pkg-mngr, then run:

 $ sudo port install inetutils dnsmasq 
  • the inetutils pkg includes telnet, ftp, rsh, rlogin, tftp client tools, and also includes corresponding daemons/servers, as bundle1.

While there is a command line TFTP server/client feature in windows, it's easier to use a third party one that has a proper graphical interface.

Tftpd64 (on Windows):

A simple and free TFTP application is Tftpd64, available here.

Download the portable version, and unzip it in a folder. You should see the manual, a license in a PDF file, a configuration file, and the application executable itself.

Place the file you want to send (the firmware file usually) in the same folder where you find the Tftpd64 program file. The folder exposed through TFTP can be changed by clicking on Browse button, but in most situations you don't need to do that.

Configure your ethernet port according to your device's own recovery method as detailed in Rescue from failed firmware upgrade, note that in most cases you can't use that port to connect to the internet until you reconfigure it back like it was before.

Double-click on the Tftpd64 program file and you should get a Windows Firewall popup asking you to grant access. Check both options, to allow Tftpd64 to communicate over both home/work and public networks. This is very important, if the Windows Firewall blocks your TFTP server you won't be able to access it from the device you want to recover.

Click on the drop-down menu called Server Interfaces and select your PC's Ethernet port.

Now the TFTP server is online and ready, and the file(s) in it can be accessed as normal.

Tiny PXE (on Windows):

Tiny PXE seems to do the same as Tftpd64 plus BOOTP support (particularly useful for MikroTik devices).

Dnsmasq (on Linux):

Dnsmasq is pre-installed in most distributions. Put an image file into your directory - actual name will vary. Then run TFTP server:

bash#  dnsmasq --port=0 --enable-tftp --tftp-root=/path/to/firmware/directory --tftp-no-blocksize --user=root --group=root 

Check if your TFTP server is listening:

bash#  netstat -lunp | grep 69 

atftpd (on Linux):

You can also use atftpd:

Install atftpd from repository on Debian/Ubuntu/Mint:

bash#  apt install atftpd 

Install atftpd from repository on RedHat/Fedora/Centos:

bash#  yum install atftpd 

Create directory where you want to put the image file:

bash#  mkdir /srv/tftp 

Put an image file into your directory - actual name will vary:

bash#  cp ~/tp_recovery.bin /srv/tftp 

Change the ownership of the folder and the file in it:

bash#  chown nobody:nogroup -R /srv/tftp 

Run TFTP server (run as daemon, do not fork, log events to stdout):

bash#  atftpd --daemon --no-fork --logfile - /srv/tftp 

Check if your TFTP server is listening:

bash#  netstat -lunp|grep 69 
  • If not set, you should try running TFTP server as superuser.

Check that you can in fact pull the file from your TFTP server.
Preferably from another computer call your TFTP server IP: (or if not possible, in same server call IP

bash#  tftp
tftp> get tp_recovery.bin
Received 8152633 bytes in 0.8 seconds
tftp> quit 

If you have received the file, congratulations, it's ready.

TFTP file transfer doesn't work from local computer

  • Check if your TFTP server is running and listening
  • Check if TFTP folder is set up correctly (location, access rights)
  • Check if firmware file is set up correctly (location, access rights)

TFTP file transfer works from local computer, but not from another computer:

  • Check if network cable is connected properly
  • Check if server IP is set correctly
  • Make sure server firewall allows inbound TFTP on UDP port 69

TFTP file transfer works from another computer, but not from router:

  • Check if server IP is set correctly (same as router is searching for)
  • Try using alternate cable, a crossover cable or alternate switch/speed
  • Try connecting to an alternate port on the router / routers switch
  • Pay attention to any output or verbosity from the router console or led activity if available
  • Verify the arp cache on either host… server side is easier…
  • Use arp -s to add a static mapping or arp -d to delete stale entries…
  • Use a third host to simply ping the router, both with static addresses if possible
  • Try an alternate server software, client software or TFTP transfer mode
  • If you get some activity, timing can often yield results, power cycle the router and start the transfer earlier or later…

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2022/04/04 08:57
  • by aterik