Running TFTP and DHCP safely

Both servers exist for the same situation: equipment that needs something from the network before it can be configured. Both are deliberately temporary — started for a job, stopped afterwards, nothing installed as a service and nothing surviving a restart.

The thing to get right

Bind to the right interface. A second DHCP server on a live network hands out addresses that fight with the real one, and the people affected will not know why. Choose the isolated or bench interface explicitly, be certain which one it is, and stop the server when you are done.

TFTP

1. Point it at a folder — the one with the firmware image in it.
2. Leave read-only on unless the device genuinely needs to write back. A device pulling an image only needs to read.
3. Choose the address to bind to, and start it.
4. Watch the log. Every request appears as it arrives, including the ones for files that do not exist — which is usually how you discover the device is asking for a different filename than you expected.

TFTP has no authentication and no encryption. That is the protocol, not the implementation. Run it on a link you control.

DHCP

1. Set the pool, the lease time, and the gateway and DNS to hand out.
2. Bind it to one interface — see above.
3. Start it, and watch leases appear with the MAC that asked and the name it gave.

There are no reservations, no options beyond gateway and DNS, and no relay support. It is for getting a device addressed on a bench, not for running a network.

Firewall

Windows Firewall normally prompts the first time either server starts. If you dismiss that prompt, nothing will reach the server and it will look broken. See firewall blocking local services.