Syslinux - Jul 2002 - tftp-hpa 0.28, 0.29 interoperability problem

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.

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

Hi,

"H. Peter Anvin" <hpa at zytor.com> schrieb am 12.07.02
20:56:16:
> ncrook wrote:
> > 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.
what client is this exactly? A PXE Rom (which card & version?) or something
else?
 
> 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.
Perhaps you should also send it to the list, since I have also some 
knowledge of tftp-hpa, at least I got it working under AIX.

Regards,

Josef

______________________________________________________________________________
500 WEB.Cent Belohnung! Nur noch bis 24. Juli 2002 im WEB.DE Club.
Worauf warten Sie noch? https://digitaledienste.web.de/Club/?mc=021109

Josef Siemes wrote:
> what client is this exactly? A PXE Rom (which card & version?) or
something else?

It's a "something else" - actually, an evaluation board for a MIPS
processor. The
tftp server is provided by MIP's debug monitor, named YAMON.

regards,

Neal.

Hi,

"H. Peter Anvin" <hpa at zytor.com> schrieb am 15.07.02
18:46:10:
> Josef Siemes wrote:
> > 
> > Perhaps you should also send it to the list, since I have also some 
> > knowledge of tftp-hpa, at least I got it working under AIX.
> > 
> 
> Please do *not* send large dump files to the list.  Josef: if you're 
> interested I can forward them to you directly.
Ok, to make this clear: If it's a small trace this could also be sent
to the list. It's also about discussing tftp-hpa.

I'm also interested in bigger traces, maybe I have more time 
hpa has for decoding this, and more eyeballs usually see more.

Regards,

Josef
 
______________________________________________________________________________
FreeMail in der Premiumversion! Mit mehr Speicher, mehr Leistung, mehr 
Erlebnis und mehr Pr?mie. Jetzt unter http://club.web.de/?mc=021105