[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.
-hpa
More information about the Syslinux
mailing list