This seems to be a simple and legitimate bug.
atftpd *always* thinks that a request has options set, even when it
doesn't. Here's from a log:
Oct 12 16:55:15 leaf6 atftpd[30694]: received RRQ <filename: kernel, mode:
octet, >
Oct 12 16:55:15 leaf6 atftpd[30694]: sent OACK <>
>From strace:
{"\0\1kernel\0octet\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 516}
Notice that the RRQ has no options set, yet OACK is sent anyways. The
problem stems from opt_support_options(), which always returns 1 after
matching on the final NULL/terminator option in the options list.
This patch fixes the problem for me:
--- tftp_def.h.orig 2006-10-12 17:34:05.000000000 -0500
+++ tftp_def.h 2006-10-12 17:34:07.000000000 -0500
@@ -40,7 +40,7 @@
#define OPT_TIMEOUT 3
#define OPT_BLKSIZE 4
#define OPT_MULTICAST 5
-#define OPT_NUMBER 7
+#define OPT_NUMBER 6
#define OPT_SIZE 12
#define VAL_SIZE MAXLEN
(Notice that there are in fact only six options, not seven.)
The NULL option is being set by opt_parse_request(). I guess there's a
bug there, but OPT_NUMBER prevents the NULL entry from even being
considered by the get/set_option functions. In fact we shouldn't even
need a NULL option in that case...
--
Hollis Blanchard
IBM Linux Technology Center
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
