[syslinux] Re: Allwell doesn't respond to OACK with ACK in TFTP

Neologism Neologism at POBox.COM
Mon Feb 4 02:14:29 PST 2002

Ok, I've got some more information.  I hacked out the loop in tftp-hpa
that waits for the ACK.  Yay, open source!  Thank you!  Frustration
level is lower.

However, problem is not solved: server now sends DATA packet, but
Allwell ignores it like a prom queen ignoring a computer geek.  Same
behavior ensues (timeout).

Ok, so now I try using the -r option of tftp-hpa, and disallow the
blksize option the Allwell is asking for.  tftp-hpa does the right
thing, giving a DATA packet with the standard blocksize.  Again, the
Allwell is an ice queen.

It looks like Jason Bodnar had the same problem earlier:
Jason, did you get it working?

Matt Butcher seems to have gotten it to work
Matt, thank you for your document.  It was helpful for me right up to
the point where I can't get it to work.  Can you see what I'm doing

Can anyone help me with this or do I throw the Allwell into the river?


On Mon, 2002-02-04 at 01:43, Neologism wrote:
> I'm trying to network-boot a GCT Allwell set-top box without success. 
> My frustration level is high.
> The problem seems to be that the Allwell is sending a RRQ with an
> option.  tftp-hpa responds with an OACK, and waits for the corresponding
> ACK from the Allwell.  The Allwell never sends that ACK, but instead
> continues with the same RRQ until timeout.
> Having read RFC1782, this makes me think the TFTP client in the Allwell
> is broken.  Ack! Ack ack ack ack ack.  Ack, thpppht.  What do I do?
> The packets follow:
> RRQ:
>     Trivial File Transfer Protocol
>         Opcode: Read Request (1)
>         Source File: pxelinux.0
>         Type: octet
>         Option: blksize = 1456
>     Trivial File Transfer Protocol
>         Opcode: Option Acknowledgement (6)
>         Option: blksize = 1456

More information about the Syslinux mailing list