[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inetutils-1.3.2 tftp file limit 16MB
From: |
Alain Magloire |
Subject: |
Re: inetutils-1.3.2 tftp file limit 16MB |
Date: |
Tue, 18 Dec 2001 20:27:20 -0500 (EST) |
Bonjour
> At 09:53 -0500 12/18/01, Alain Magloire wrote:
> >
> >
> >Unless I missed the obvious, changing this will make it impossible to work
> >with other
> >since you are changing the struct size, tftp.h is an expose file and
> >provided for
> >convenience if the platform does not have it in /usr/include/arpa/tftp.h
>
> I disagree: changing from short to u_short still occupies 2 bytes, and only
> affects the interpretation of the sign, for example whether 0x8000 is smaller
> or larger than 0x7fff. Of course for best advantage both server and client
> should probably change (I've only documented the client doing an integer
> overflow in processing the block number during ack, but I imagine server will
> have the same difficulty), but the client should see no difference in the
> size or contents of the tftphdr data structure. I see that the Solaris
> include file /usr/include/arpa/tftp.h was not used for the GNU compilation,
> according to file access time (don't know why).
>
Yes, Sergey/Richard set me straight, for some reason, I was seing "int".
You can browse the list:
http://mail.gnu.org/pipermail/bug-inetutils/
The current source is on CVS and snapshots on ftp://alpha.gnu.org/gnu/inetutils
http://savannah.gnu.org/projects/inetutils
You can browse the source(CVSWeb)
> I should mention that the same 16 MB+ file was transmitted successfully via
> TFTP from a Windows NT server to our Cisco router, so I believe such a
> (ridiculously) large file can be transmitted via this protocol.
> Unfortunately I have not had the time to try and recompile GNU tftp/tftpd to
> test my proposed changes.
>
I will gladly accept a patch(with ChangeLog) against:
inetutils/header/arpa/tftp.h