Trivial Transfers with TFTP, Part 1: Why Use It?


Sometimes we find ourselves using technologies that — although we may not realize it — stem from way back in the history of the Internet. The other day, I was using Trivial File Transfer Protocol (TFTP) and looked up its Request For Comments (RFC) only to discover that it’s been around a while longer than I suspected: since June 1981 to be exact. That may not be the 1970s but FTP  and TFTP can certainly be considered founding protocols.

In an unusual twist, TFTP doesn’t use the now almost mandatory Transmission Control Protocol (TCP) for moving its data around. TCP offers resilience through error recovery but instead TFTP uses the User Data Protocol (UDP) presumably because of the “trivial” nature of its file transfers.

The feature set included with TFTP is admittedly quite limited but, make no mistake, it can still be very useful on a local area network (LAN). Unlike the well-known FTP service, which is commonly used for moving files back and forth across the Internet (and which includes successors with encryption, such as sFTP and FTPS, among its family members), TFTP doesn’t even allow the listing of directories, so you can see which files are available. If you want to use TFTP, you need to be aware of the filenames, which are sometimes complex and lengthy to provide a small dose of security through obscurity, before connecting to a server.

Other somewhat surprising limitations, relative to its cousin FTP, include a lack of authentication and the ability to delete or rename files. Admittedly, there may have been improvements since its original design but the RFC also states that, in essence, the only errors it can pick up are noticing if the wrong user is specified, if a file that’s requested doesn’t exist, and other access violations.

Now that you’re firmly sold on using this somewhat-deprecated protocol, let’s have a think about what it might be used for.

If you’re creating new machines from images, then TFTP is perfect for bootstrapping a new server with predefined config and a sprinkling of packages. It might also be used during boot time to pull the latest version of a file from a local server so that all clients are guaranteed to be up-to-date with a certain software package.

You may also want to use TFTP — as several vendors do — for firmware updates. Why choose TFTP over FTP or even HTTP, you may ask? Simply because even if you don’t have a TFTP server already up and running, it’s relatively easy to quickly get started. Also the number of parameters required to retrieve a file (and therefore the number of things that can go wrong) is very limited. It tends to work or it doesn’t; there’s little middle ground. This functional simplicity is definitely a bonus.

If you’ve ever maintained switches or routers, then you’ve likely used TFTP either to back up or restore config files or possibly to perform a firmware upgrade. Many of the major vendors still prefer this method, possibly because there’s a feeling of comfort (in relation to security) when moving files around inside a LAN relative to doing so across the Internet.

On a network device, for example, you might encounter a transaction similar to that seen in Listing 1:

Router# copy running-config tftp:
Address or name of remote host []?
Destination filename [router_config_backup_v1]? router_config_backup_v1
3151 bytes copied in 1.21 secs (2,604 bytes/sec)


Listing 1: The type of transaction that you may see when backing up a network device’s config via TFTP.

As you can see in this listing, the exclamation marks provide a progress bar of sorts and each one acts as an indicator that a successful transfer of ten packets.


Let’s look at how to get a TFTP server up and running.

In the olden days, inetd ruled the roost and was responsible for letting many local services out onto the network so that they could communicate with other users and machines. On the majority of systems that I used, thanks to security limitations, inetd ultimately became xinetd, which closed down more unneeded services by default. Thankfully, however we can avoid also installing xinetd, which was the norm until a few years ago but instead solely focus on the tftpd package.

On Debian derivatives, installing tftpd is as simple as running:

# apt-get install tftpd

As you can see in Figure 1, inetd is indeed mentioned as a supplementary package but this is of little consequence in terms of the filesystem footprint remaining minuscule.

Figure 1: Installing the “tftpd” package on Debian systems.

Trilbys and Fedoras

On Red Hat derivatives, there are a few other considerations. You can use an alternative package with similar relative ease but opt in to using the more advanced xinetd by running a command such as:

# yum install tftp-server xinetd

This pulls down the more sophisticated replacement for inetd and tftp-server. Incidentally, the tftpd-hpa is pulled down on Debian systems if you try and install tftp-server, and you would edit the file /etc/default/tftpd-hpa to config your service. Look for the Debian-specific README to allow file uploads, too.

Back to Red Hat. The description for the tftp-server packages is as follows, echoing what we’ve said until now:

“The Trivial File Transfer Protocol (TFTP) is normally used only for booting diskless workstations. The tftp-server package provides the server for TFTP, which allows users to transfer files to and from a remote machine. TFTP provides very little security, and should not be enabled unless it is expressly needed. The TFTP server is run from /etc/xinetd.d/tftp, and is disabled by default.”

If you haven’t used xinetd before it uses individual config files per service. For example, inside the file /etc/xinetd.d/tftp you need to make a couple of small changes to get started. Have a look at Listing 2.

service tftp


socket_type  = dgram

protocol            = udp

wait            = yes

user            = root

server            = /usr/sbin/in.tftpd

server_args    = -s /tftp_server_directory

disable            = yes

per_source    = 11

cps            = 100 2

flags            = IPv4


Listing 2: A sample “xinetd” config for a TFTP service.

As you can see in this listing, we will need to change the “disable” setting to “no” if we want this service to start. Additionally, we might need to alter the “server_args” option away from “-s /tftp_server_directory” if we want to serve files from another directory. If you want to allow file uploads then simply add a “-c” option before the aforementioned “-s” on that line.

In the next article, we’ll look more closely at the main config file and talk about how to enable and disable tftpd services.

Chris Binnie is a Technical Consultant with 20 years of Linux experience and a writer for Linux Magazine and Admin Magazine. His new book Linux Server Security: Hack and Defend teaches you how to launch sophisticated attacks, make your servers invisible and crack complex passwords.

Advance your career in Linux System Administration! Check out the Essentials of System Administration course from The Linux Foundation.