src-test/usr.bin/tftp, branch stable/7

MFC r235211:

2012-05-18T00:03:13Z

General mdoc(7) and typo fixes. PR: 167696

MFC 170382 through 231539

2012-02-11T23:58:07Z

- this records svn:mergeinfo for previously merged changesets This pulls in changes such as: MFC 216370 - Remove adertising clause from UCB copyrighted files in usr.bin MFC 222534 - Fix a couple of spelling errors. MFC 223493 - Remove duplicated header files MFC 223135 - 223491 - man page updates MFC 229403 - Replace index() and rindex() calls with strchr() and strrchr(). MFC 230044 - fgets(3) returns a pointer, so compare against NULL, not integer 0.

MFC: r213099

2010-10-04T19:59:11Z

Make WARNS=6 clean.

MFC: r213075

2010-10-04T19:51:16Z

Try to adhere to style.Makefile(5).

MFC: r213053

2010-10-04T19:40:01Z

Remove an explicit assignment of the CFLAGS variable intended for debugging purposes only.

MFC: r207607, r207621, r209112, r209550, r209551

2010-09-22T21:54:16Z

Go ahead and merge the work edwin@ on tftpd into the tree. It is a lot better than what's in the tree now. Edwin tested it at a prior employer, but can't test it today. I've found that it works a lot better with the various uboot versions that I've used in my embedded work. Here's the pkg-descr from the port that describes the changes: It all started when we got some new routers, which told me the following when trying to upload configuration or download images from it: The TFTP server doesn't support the blocksize option. My curiousity was triggered, it took me some reading of RFCs and other documentation to find out what was possible and what could be done. Was plain TFTP very simple in its handshake, TFTP with options was kind of messy because of its backwards capability: The first packet returned could either be an acknowledgement of options, or the first data packet. Going through the source code of src/libexec/tftpd and going through the code of src/usr.bin/tftp showed that there was a lot of duplicate code, and the addition of options would only increase the amount of duplicate code. After all, both the client and the server can act as a sender and receiver. At the end, it ended up with a nearly complete rewrite of the tftp client and server. It has been tested against the following TFTP clients and servers: - Itself (yay!) - The standard FreeBSD tftp client and server - The Fedora Core 6 tftp client and server - Cisco router tftp client - Extreme Networks tftp client It supports the following RFCs: RFC1350 - THE TFTP PROTOCOL (REVISION 2) RFC2347 - TFTP Option Extension RFC2348 - TFTP Blocksize Option RFC2349 - TFTP Timeout Interval and Transfer Size Options RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) It supports the following unofficial TFTP Options as described at http://www.compuphase.com/tftp.htm: blksize2 - Block size restricted to powers of 2, excluding protocol headers rollover - Block counter roll-over (roll back to zero or to one) From the tftp program point of view the following things are changed: - New commands: "blocksize", "blocksize2", "rollover" and "options" - Development features: "debug" and "packetdrop" If you try this tftp/tftpd implementation, please let me know if it works (or doesn't work) and against which implementaion so I can get a list of confirmed working systems. Author: Edwin Groothuis

MFC: r183858

2010-09-22T21:44:55Z

ANSIfy, plus constify interfaces where possible.

MFC: r183857

2010-09-22T21:43:48Z

Use strlcpy() instead of strncpy() when we want the string to be NUL-terminated.

Merge r201429 from head:

2010-01-17T10:59:07Z

Fix return code in the case of successful file transfer, broken in tftp.c 1.13 PR: bin/117452 Submitted by: Spencer Minear minear securecomputing.com Approved by: ed (mentor, implicit)

MFC: Fix various markup nits.

2007-11-14T19:25:05Z

Approved by: re (kensmith)