[U-Boot] [RFC] Act as a TFTP server

[Luca Ceresoli]

Hi,

I am going to implement in U-Boot the ability to receive a file via TFTP acting
as a server, not a client. I've sketched up a way to implement it, and I would
appreciate any comments about it.

This is useful to solve the firewall issues that a Management Station can face
when sending files to a U-Boot device. These issues are only partially solved
using CONFIG_TFTP_PORT for '"punching through" the (Windows XP) firewall' (see
the README).

My implementation would be very basic (keep it simple):
- receive only (accept WRQ from remote client, not RRQ);
- the Filename in the WRQ is ignored: the destination is always a user-provided
   memory location;
- binary transfers only: the Mode in the WRQ is ignored; this is allowed by
   RFC1350 (section 5);
- no TFTP Option Extensions (RFC2347);
- no TFTP multicast.

After a preliminary analysis, I think the current TFTP clien implementation can
be mostly reused without code duplication, hence the amount of new code would
be pretty limited.

Even better, it would not increase binary size when the feature is disabled,
as I don't see any need to extend the existing code in a way that cannot be
easily put under appropriate #ifdefs.

 From the user point of view, I would implement a new command, activated only
when CONFIG_CMD_TFTPSRV is defined:

   Usage:    tftpsrv [<loadaddr>]

This would be used almost like tftpboot, except no file name is specified on
the commandline.
<loadaddr>  would default to the environment variable.

Here's a tentative implementation roadmap. It is presented in a roughly
top-down order, from user interface down to low level.
Many steps, except for those in net/tftp.c, are pretty trivial.

- add CONFIG_CMD_TFTPSRV config option;
- include/net.h: add TFTPSRV to proto_t, *as if it were a different protocol*;
   this may look dirty but I believe it makes implementation cleaner;
   - alternative: reuse TFTP protocol, but save in some flag (where?) whether
     the user wants a client or server transfer;
- common/cmd_net.c: add a tftpsrv command and do_tftpsrv() function;
   just like do_tftpb() simply calls netboot_common(TFTP, ...),
   do_tftpsrv() would simply call netboot_common(TFTPSRV, ...);
- common/cmd_net.c: netboot_common() should not need change, except maybe
   for the argv parsing: tftpsrv does not take a "hostaddr:filename" argument;
   to make it simpler, it could accept (but ignore) it if passed;
- net/net.c: change net_check_prereq() as needed: it should not check for
   NetServerIP when protocol==TFTPSRV;
- net/net.c: extend NetLoop() to handle the new protocol: call
   TftpStartServer() (not TftpStart()) when protocol==TFTPSRV;
- net/tftp.c: add TftpStartServer() with a role similar to TftpStart();
   - alternative: extend TftpStart() to handle both client and server mode;
     probably not worth doing as the actions to do are mostly different;
- net/tftp.c: extend the TFTP state machine (TftpHandler() and TftpStart())
   a new STATE_WAITING state (it should be enough);
   - the state machine would be different in the session setup: in
     STATE_WAITING handle WRQ packets and select a new UDP port;
   - after the setup phase, the state machine would converge on the
     currently-implemented STATE_DATA for normal DATA/ACK management.

Do you think my approach is correct?
Would this feature be considered for mainline inclusion?

Thanks in advance,
Luca