A TFTP timeout is not one problem — it is a symptom with about eight possible homes, and guessing wastes the evening. This ladder checks them in the order that splits the problem fastest, from the server not even listening to the last-resort settings.
The device says timeout or the transfer crawls and dies, and the internet offers forty random suggestions. Resist them. TFTP is a simple protocol, so its failures live in a short list of places: the server, the address, the firewall, the path, the file, the permissions, and finally the protocol options themselves. Climb this ladder one rung at a time, testing after each — the rung where behaviour changes is where your problem lives. Almost every real case is solved by rung five; the later rungs exist so the rare stubborn case still has somewhere to go.
On the PC: netstat -an | findstr :69. No UDP line on port 69 means the tool is not bound — start it as administrator (port 69 needs elevation), or check whether another TFTP tool or service already owns the port, in which case the second one can never start. Also note which address it bound: if it listened only on a virtual or VPN adapter, devices on the real LAN will never reach it. Set the bind/interface to the LAN adapter's IP in the tool's settings.
Read the command you typed on the device as if seeing it for the first time. The server address must be the PC's current LAN IP — not the address it had yesterday before DHCP renewed it, not the Wi-Fi address when the PC is wired, not the gateway. On the PC, ipconfig shows the truth. For repeated work, give the PC a fixed address or a DHCP reservation so this rung never moves again.
From the device (most switches and routers can ping), ping the PC's address. No reply means the problem is below TFTP entirely: different subnets with no route, a VLAN boundary, a cable or port issue — or the PC's firewall refusing even ping, which itself is a clue pointing at the next rung. From the PC, also ping the device, proving the road works in at least one direction.
Confirm the inbound UDP 69 rule exists (see the firewall guide in this series) — and then check the sneaky one: the network profile. If Windows currently classifies your LAN as a Public network, your Private-profile rule is politely ignored. Set the network to Private in Settings for your own office LAN. Third-party antivirus firewalls can also override Windows Firewall entirely; check there too.
This is the dividing line of all TFTP troubleshooting. Start a transfer and watch the server's log pane. Nothing appears: the request never arrived — the problem is rungs 1–4 (server, address, path, firewall), full stop; do not touch file settings. The request appears, then fails: the network is innocent — climb on to the file-side rungs below.
With requests arriving, failures are now mundane. File not found: the name on the device must match the file in the root folder exactly — spelling, extension, and the folder the tool is really using. Uploads refused while downloads work: the server cannot write — the root folder's permissions, the tool's security setting restricting transfers to downloads only, or (on some older servers) no pre-existing file: create a blank file with the exact target name in the root folder and retry. Access violations reported by the device almost always trace back to this same trio.
A transfer that begins and stalls partway is a different animal. Classic TFTP moves in 512-byte blocks, each individually acknowledged; on lossy or busy links this crawls and can time out — many tools let you raise the block size (for example to 1468) or adjust the timeout/retries, which fixes marginal paths. Keep changes honest and small: try the transfer on a quiet, wired connection first, because a dying transfer on a congested Wi-Fi hop is the network telling the truth. If several devices fail identically while one PC-to-PC test works, suspect the path (an in-between firewall mishandling TFTP's reply ports) and move the server onto the device's own subnet — the oldest and most reliable TFTP fix of all.
The full TFTP server setup — installation, root folder, firewall and a live transfer — is shown step by step in the video.
▶️ Watch Full VideoIf the log shows nothing, the request never reached the tool, so the fault is on the delivery side: server not listening on UDP 69, the device using a wrong or stale server address, no route between subnets, or a firewall (including the Windows Public-profile trap) dropping the packet. The file name and folder cannot be the cause of a request that never arrived.
Reading and writing are gated separately. Uploads fail when the root folder is not writable by the account running the tool, when the tool's security setting allows only sending files, or when an older-style server expects the target file to exist already — creating a blank file with the exact name first solves that last case. Check the tool log: it usually records the refusal reason.
First, remove avoidable loss: use a wired connection and a quiet network moment. Then use the tool's options — a larger block size and a longer timeout with retries are the designed answers for marginal paths. If it still dies, verify how far it gets; failing at exactly the same byte count every time suggests a file or device limit rather than the network, while failing at random points points back to the path.