ATFTP LOCAL LISTEN PATCH

You'll be interested in this patch if you run "Advanced TFTP" ("atftp") software (http://freshmeat.net/projects/atftp/).

The Technical Explanation

The patch adds the "--listen-local" command-line option to in.tftpd. This option forces the daemon to listen on a local network address (0.0.0.0 or a local interface).

Normally this is not necessary. However, it is necessary if you run the atftp server on a Linux box and your tftp clients cause the daemon to listen on the broadcast address (255.255.255.255). In most cases it does not happen, but some clients, such as Sparcstation 20, do it.

The Linux kernel (as of the 2.4 series) ignores network packets directed to a local broadcast address. Unless you apply the patch, you're out of luck, because there aren't any kernel options to fix it, and if you're savvy enough to add an SO_BROADCAST socket option to the code, you'll find that Linux ignores that, too. So this patch allows the tftpd service to respond to clients that would otherwise be unable to communicate with your server.

The Layman Explanation

If you've got a tftpd service running and you're stumped because you're tftp clients aren't booting, chances are you need to apply this patch to let them communicate.

The History

How did I come to discover this obscure problem? At the New Mexico Tech Computer Center (http://www.nmt.edu/tcc) we have some Sparcstation 20s that are configured as thin clients. When they boot, they first send out a RARP request, our server responds and gives them their IP address. Then, they use that ip to request a file through TFTP, the file resides on the TFTP server and is a Linux kernel image. This is part of the LTSP (Linux Terminal Service Project). During boot up, the client will send out a DHCP request, load its hostname and gets the location of the server that will give it its root filesystem.

The clients weren't booting tftp, so through a variety of trial-and-error, looking at logs and using tcpdump, I located the problem. I tried to find a kernel option that would fix it, tried to locate something in /proc/sys, and also tried to use SO_BROADCAST, but nothing worked. So I wrote the patch.

This was two years ago, and it's been happy ever since.

The Patch

This patch is for atftp version 0.7. That's the version I've been using on our tftp server for the past two years and it's been working great. In fact, by the looks of it, there isn't a newer version. So you should be good to go.

This patch is under a BSD style license, which means you can use it, modify it, distribute it, as long as you adhere to the terms of the license, which basically state that you gotta keep the copyright notice and license text with the patch. Read the top portion of the patch for details. Download it here: ./download/atftp-0.7-listenlocal.patch. The md5 checksum is: c7f4cf5a1c21c37d2545cabb0bfca883

Usage

Real easy to use. Once you get the source patched, then set up your server something like the following:
/system/atftp/sbin/in.tftpd --listen-local --logfile /var/log/atftpd.log --verbose=6 --user tftp.tftp /tftpboot/

The exact incantation of course will vary depending on how you launch in.tftpd, from xinetd, rc.d, or whatever.

Who am I

When I wrote this patch, I was the Engineering Manager for the Computer Center at New Mexico Tech (http://www.nmt.edu/tcc/). I now wear a different hat, but I still maintain this patch. I've also got another Sourceforge project: http://sftplogging.sourceforge.net. More information about me is there on the "About the Author" link.

I'm curious to hear if anyone else uses this patch other than me. If you need to talk to me, send me email: mikem@nmt.edu.