Re: Bug in tftpd ?
Patches attached: Obtained from: NetBSD (Committed there about 3 months ago after we first spotted the problem in their implementation) -- Pascal Hofstee daeron @ shadowmere . student . utwente . nl begin LOVE-LETTER-FOR-YOU.TXT.vbs I'm a signature virus. Please copy me and help me spread. end --- tftpd.8.origWed Jan 31 11:59:57 2001 +++ tftpd.8 Wed Jan 31 12:04:55 2001 @@ -192,3 +192,9 @@ .Fl c option was introduced in .Fx 5.0 . +.Sh BUGS +Files larger than 33488896 octets (65535 blocks) cannot be transferred +without client and server supporting blocksize negotiation (RFC1783). +.Pp +Many tftp clients will not transfer files over 1678 octets (32767 blocks). + --- tftpd.c.origWed Jan 31 11:55:53 2001 +++ tftpd.c Wed Jan 31 11:58:00 2001 @@ -501,7 +501,7 @@ struct tftphdr *dp, *r_init(); register struct tftphdr *ap;/* ack packet */ register int size, n; - volatile int block; + volatile unsigned int block; signal(SIGALRM, timer); dp = r_init(); @@ -571,7 +571,7 @@ struct tftphdr *dp, *w_init(); register struct tftphdr *ap;/* ack buffer */ register int n, size; - volatile int block; + volatile unsigned int block; signal(SIGALRM, timer); dp = w_init();
Re: Bug in tftpd ?
On Wed, Jan 31, 2001 at 12:13:54PM +0100, Pascal Hofstee wrote: Patches attached: Obtained from: NetBSD (Committed there about 3 months ago after we first spotted the problem in their implementation) Ok .. I noticed a minor glitch in my previous patch .. the "unsigned int" should be "unsigned short" Apparently NetBSD still uses the "unsigned int" so may still show the same problem. New patche attached. -- Pascal Hofstee daeron @ shadowmere . student . utwente . nl begin LOVE-LETTER-FOR-YOU.TXT.vbs I'm a signature virus. Please copy me and help me spread. end --- tftpd.8.origWed Jan 31 11:59:57 2001 +++ tftpd.8 Wed Jan 31 12:04:55 2001 @@ -192,3 +192,9 @@ .Fl c option was introduced in .Fx 5.0 . +.Sh BUGS +Files larger than 33488896 octets (65535 blocks) cannot be transferred +without client and server supporting blocksize negotiation (RFC1783). +.Pp +Many tftp clients will not transfer files over 1678 octets (32767 blocks). + --- tftpd.c.origWed Jan 31 11:55:53 2001 +++ tftpd.c Wed Jan 31 11:58:00 2001 @@ -501,7 +501,7 @@ struct tftphdr *dp, *r_init(); register struct tftphdr *ap;/* ack packet */ register int size, n; - volatile int block; + volatile unsigned short block; signal(SIGALRM, timer); dp = r_init(); @@ -571,7 +571,7 @@ struct tftphdr *dp, *w_init(); register struct tftphdr *ap;/* ack buffer */ register int n, size; - volatile int block; + volatile unsigned short block; signal(SIGALRM, timer); dp = w_init();
Bug in tftpd ?
Hi, I think i just encountered a bug in FreeBSD's tftpd-implementation. Actually it's a bug that i spotted a while back with a friend of mine in NetBSD's implementation, but never really bothered with it since i don't use tftpd myself, but i am in a position now where i need to with FreeBSD. The bug only triggers when trying to fetch files bigger than 32 MB. On NetBSD it happened around a 16 MB boundary ... (but i may have interpreted blocksizes wrong). The issue is located in a minor difference in tftpd's own "block" count and arpa/tftp.h 's struct tftphdr 's "tu_block" type declaration arpa/tftp.h defines the block count: unsigned short tu_block; /* block # */ tftpd.c 's xmitfile and recvfile functions define the block count: volatile int block; What happens is kinda obvious after quite a lot of data has been sent without any problems ... suddenly tftpd's block-counter starts wrapping while arpa/tftp.h's block counter does simply increase more. This results in "TIMEOUT errors" as the block-sequence numbers simply won't match any more. If patches are required let me know ... -- Pascal Hofstee daeron @ shadowmere . student . utwente . nl begin LOVE-LETTER-FOR-YOU.TXT.vbs I'm a signature virus. Please copy me and help me spread. end To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
