[syslinux] tftp-hpa 0.28, 0.29 interoperability problem

H. Peter Anvin hpa at zytor.com
Fri Jul 12 11:54:09 PDT 2002

ncrook wrote:
> Hi,
> I have a tftp client which loads quite happily from a tftpd built
> from netkit-tftp-0.16 but which fails to load from from a tftpd built
> from tftp-hpa 0.29. In both cases, tftpd was built from pristine
> sources and run from xinetd under Redhat 7.3.
> [netkit-tftp-0.16 is the ancestor of tftp-hpa, predating HPA's
> maintenance of same]

Sort of.  netkit-tftp-0.12 is the ancestor of tftp-hpa. :)

> [the tftp client also..
> .. fails with the prebuilt tftpd in RH7.3, which is a patched
>    tftp-hpa 0.28
> .. succeeds with a solaris tftpd of some irrelevant vintage
> .. succeeds with a prebuilt tftpd in RH6.2, which is a patched
>    netkit-tftp-0.16
> ]
> Using tftpd built from 0.29 I have also tried running with all the
> -r switches, via xinetd and also in stand-alone mode with this
> incantation:
> [stop xinetd]
> /blah/tftpd -l -u root -s /tftp_files -v -v -r timeout -r tsize \
> -r blksize -r blksize2
> but get the same results. In all failing cases, the failure mode is
> that a small file (5114 bytes or smaller) can be loaded by the client
> successfully, but a larger file (5142 bytes or larger) causes the client
> to hang and then fail with what it reports as a data timeout error.
> After a failure, "ps -aux | grep tft" shows 2 daemon processes running,
> one the child of the other. After a short time, the child terminates.
> When I look in my system log files, I get: 
> in.tftpd[1488]: RRQ from XX.XX.XX.XX filename foo
> which is logged at level LOG_NOTICE. If I start up tftpd with a bogus
> command option I get something like:
> in.tftpd[8286]: Unknown option: gl
> which is logged at level LOG_ERR. I never get any other log messages
> from tftpd (ie done of the other LOG_ERR things that tftpd detects appear
> to occur in my system)

Pass the -v option in increasing numbers until you get the log messages 
you want.

> Currently, I have no way to point the finger of blame towards either
> the server or the client. My immediate work-around has been to use
> the netkit-tftp-0.16 version, but this rather a shame.
> Finally, my question: can anyone suggest tools and tecniques that I
> can use for further debug/investigation?

Capturing a packet trace of a full session with:

	tcpdump -s 2000 -w packet.dump host <client>

... and sending it to me is the first thing to do.  Please send both a 
packet trace of a successful connection and an unsuccessful connection. 
    All the log messages run with tftpd -v -v -v would help too.


More information about the Syslinux mailing list