Bug 104218 – atftp-0.7 password extension

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Matthew Almond 2005-08-29 20:19:06 UTC]

In some fairly specific circumstances, a variant of atftp with password support
is needed to flash the firmware of some linksys routers. I found the patch
listed at:

http://www.hadess.net/files/patches/atftp-linksys-password-support.patch

Unfortunately, it does not apply cleanly to v0.7 (it was made for v0.6.2), so I
basically re-implemented it for the current version. 

Reproducible: Always
Steps to Reproduce:
1. Execute "atftp --help"
2. Note the "-P, --password" option.
Actual Results:  
Usage: tftp [options] [host] [port]
 [options] may be:
  -g, --get                : get file
      --mget               : get file using mtftp
  -p, --put                : put file
  -l, --local-file <file>  : local file name
  -r, --remote-file <file> : remote file name
  --tftp-timeout <value>   : delay before retransmission, client side
  --option <"name value">  : set option name to value
  --mtftp <"name value">   : set mtftp variable to value
  --no-source-port-checking: violate RFC, see man page
  --verbose                : set verbose mode on
  --trace                  : set trace mode on
  -V, --version            : print version information
  -h, --help               : print this help

 [host] is the tftp server name
 [port] is the port to use

Expected Results:  
Usage: tftp [options] [host] [port]
 [options] may be:
  -g, --get                : get file
      --mget               : get file using mtftp
  -p, --put                : put file
  -l, --local-file <file>  : local file name
  -r, --remote-file <file> : remote file name
  -P, --password <password>: specify password (Linksys ext.)
  --tftp-timeout <value>   : delay before retransmission, client side
  --option <"name value">  : set option name to value
  --mtftp <"name value">   : set mtftp variable to value
  --no-source-port-checking: violate RFC, see man page
  --verbose                : set verbose mode on
  --trace                  : set trace mode on
  -V, --version            : print version information
  -h, --help               : print this help

 [host] is the tftp server name
 [port] is the port to use

Please see attachment for actual fix.

[Comment 1 Matthew Almond 2005-08-29 20:21:34 UTC]

Created attachment 67243 [details, diff]
atftp-0.7-password.patch

Apply after atftp-0.7-gcc.patch

[Comment 2 Seemant Kulleen (RETIRED) 2005-09-14 12:47:29 UTC]

Mr. Almond, so I'm gonna take this bug because I'm starting to work with openwrt
stuff as well, so I'll throw this in.  Any chance you can help me debug atftp on
amd64 though?  One of the tests in the testsuite is failing (during make check):

Testing blksize option ...
 minimum ... OK
 maximum ... OK
 block size 8 bytes ... OK
 block size 256 bytes ... OK
 block size 1428 bytes ... OK
 block size 16000 bytes ... OK
 block size 64000 bytes ... OK
 block size 65465 bytes ... ERROR

[Comment 3 Matthew Almond 2005-09-14 23:55:55 UTC]

From what I can tell, this probably isn't an amd64 or new problem related to
this patch. I'm using x86 and I get:

Testing blksize option ...
 minimum ... OK
 maximum ... OK
 block size 8 bytes ... OK
 block size 256 bytes ... OK
 block size 1428 bytes ... OK
 block size 16000 bytes ... OK
 block size 64000 bytes ... ERROR
 block size 65465 bytes ... ERROR

on both atftp-0.7 and atftp-0.7-r1 (my overlay version with the extra patch in).
I'm going to be out of town for a few days, but will make a note to investigate
the nature of this problem to the best of my abilities.

[Comment 4 Matthew Almond 2005-09-19 21:12:02 UTC]

(In reply to comment #3)
> From what I can tell, this probably isn't an amd64 or new problem related to
> this patch. I'm using x86 and I get:
> 
> Testing blksize option ...
>  minimum ... OK
>  maximum ... OK
>  block size 8 bytes ... OK
>  block size 256 bytes ... OK
>  block size 1428 bytes ... OK
>  block size 16000 bytes ... OK
>  block size 64000 bytes ... ERROR
>  block size 65465 bytes ... ERROR
> 
> on both atftp-0.7 and atftp-0.7-r1 (my overlay version with the extra patch in).
I have three similarly configured machines - the server does still produce this
output, but I found my other server and desktop produce output like yours. I had
a look at the RFC in question:

http://www.faqs.org/rfcs/rfc2348.html

and I see that 'Valid values range between "8" and "65464" octets, inclusive.'
Therefore it appears to be a minor bug in the test itself. Indeed, I added an
extra test for the size 65464 in test/test.sh and it passes that.

Should I split this side issue off into another bug?

[Comment 5 Seemant Kulleen (RETIRED) 2005-10-21 05:20:22 UTC]

matthew, sure

[Comment 6 INODE64 Sistemas 2005-11-03 09:56:20 UTC]

Created attachment 72039 [details]
atftp-0.7-r1.ebuild

update ebuild with debian and password,pcre patchs
and new USE (readline and pcre)

see for pcre patch:
http://bugs.gentoo.org/show_bug.cgi?id=109638

[Comment 7 Robin Johnson 2006-05-26 14:29:18 UTC]

seemant: hope you don't mind, I'm working on atftp at the moment, so I'm taking this, and commiting after testing (along with all the rest of the bugs against atftp).

[Comment 8 Robin Johnson 2006-05-26 14:47:54 UTC]

in cvs thanks.