tftp

What it does

tftp is a minimal file transfer client implementing the Trivial File Transfer Protocol — a stripped-down protocol with no authentication, no directory browsing, and no encryption, running over UDP (typically port 69). It exists because its simplicity makes it trivial to implement in constrained environments: network switch/router firmware, PXE network-boot loaders, and embedded device bootstrapping all commonly rely on TFTP to fetch a boot image, kernel, or configuration file from a server on the local network.

Beginner examples

• tftp 192.168.1.1 — connect interactively to a TFTP server
• get firmware.bin — inside a session, download a file from the server
• put config.cfg — inside a session, upload a file to the server
• tftp -v 192.168.1.1 -c get boot.img — non-interactive one-shot download with verbose output

tftp 192.168.1.1 -c get firmware.bin

Advanced examples

• Push a new configuration file to a network switch as part of a change window: tftp -v switch-mgmt-ip -c put running-config.cfg
• Pull a device's current firmware image for backup before an upgrade: tftp -m binary 192.168.1.1 -c get current-firmware.bin
• Set up a PXE boot environment where a DHCP server points clients at a TFTP server hosting a bootloader (pxelinux.0) — the client firmware itself acts as the TFTP client here, but you can validate the setup manually with tftp from a workstation.
• Script a firmware retrieval step in an automated network provisioning pipeline, using -c get for a single non-interactive transfer.

tftp -v 10.0.0.1 -c get /configs/router-backup.cfg

Common mistakes

• Assuming TFTP has any authentication — it doesn't; anyone who can reach the TFTP server on the network can typically read or write files, subject only to whatever path restrictions the server enforces.
• Exposing a TFTP server to an untrusted network or the public internet — it should only ever run on an isolated management network or VLAN.
• Forgetting to set the correct transfer mode (binary vs netascii) for firmware images — transferring a binary file in the wrong mode can corrupt it.
• Expecting directory listing or ls-style browsing inside a tftp session — TFTP has no such capability; you must already know the exact remote filename.

Tips

• Use -c get/-c put for one-shot, scriptable transfers instead of the interactive prompt when automating device provisioning or backups.
• Always double-check transfer mode (-m binary for firmware/images) since silent corruption from an incorrect mode can be hard to diagnose after the fact.
• When troubleshooting a PXE boot failure, test the TFTP server manually with a plain tftp client first to isolate whether the problem is TFTP connectivity or something further along in the boot chain (DHCP options, bootloader config).

Best practices

• Never run a TFTP server reachable from untrusted networks — restrict it to a dedicated management VLAN or firewall-isolated segment, since the protocol offers no authentication or encryption whatsoever.
• Use TFTP only for its intended niche (network booting, firmware/config transfer to embedded network gear) — for general file transfer between systems you control, use SFTP/SCP/rsync-over-SSH instead.
• When backing up device configurations via TFTP, keep the retrieved files in a properly access-controlled location afterward, since the transfer itself offered no protection in transit.

Real-world use cases

• PXE network booting: a DHCP server hands a client a TFTP server address and boot filename, and the client's firmware fetches the bootloader/kernel over TFTP.
• Backing up and restoring configuration files on network switches and routers that only expose TFTP (in addition to or instead of SFTP) for this purpose.
• Pushing firmware updates to embedded devices, VoIP phones, or thin clients on an isolated management network.

Common interview questions

• Why does TFTP still exist given how insecure it is? Its extreme simplicity makes it easy to implement in the constrained boot ROM/firmware of network hardware and PXE boot clients, where a full FTP/SFTP stack would be overkill.
• What transport protocol does TFTP use, and why? UDP, chosen to keep the protocol implementation minimal; TFTP layers its own simple acknowledgment/retry scheme on top rather than depending on TCP.
• What's a real security concern with running a TFTP server, and how do you mitigate it? TFTP has no authentication or encryption, so anyone on the reachable network can potentially read/write files; mitigate by isolating the TFTP server on a trusted, restricted management network only.