[syslinux] tftp-hpa 0.28, 0.29 interoperability problem

ncrook ncrook at micron.com
Fri Jul 12 04:00:18 PDT 2002


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]

[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)

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?

thanks,

Neal.
---
Neal Crook
UK Design Centre
Micron Europe Ltd.




More information about the Syslinux mailing list