Manual

Chapter 36. Tests and Demonstrations
This is only partially interactive. You need to set things up on the “server” in order for this to work, and you will
need to look at the server afterwards to confirm that all was well.
For each interface in turn, this test attempts to read by tftp from the server, a file called tftp_get and prints the
status and contents it read (if any). It then writes the same data to a file called tftp_put on the same server.
In order for this to succeed, both files must already exist. The TFTP protocol does not require that a WRQ request
_create_ a file, just that it can write it. The TFTP server on Linux certainly will only allow writes to an existing
file, given the appropriate permission. Thus, you need to have these files in place, with proper permission, before
running the test.
The conventional place for the tftp server to operate in LINUX is /tftpboot/; you will likely need root privileges
to create files there. The data contents of tftp_get can be anything you like, but anything very large will waste
lots of time printing it on the test’s stdout, and anything above 32kB will cause a buffer overflow and unpredictable
failure.
Creating an empty tftp_put file (eg. by copying /dev/null to it) is neatest. So before the test you should have
something like:
-rw-rw-rw- 1 root 1076 May 1 11:39 tftp_get
-rw-rw-rw- 1 root 0 May 1 15:52 tftp_put
note that both files have public permissions wide open. After running the test, tftp_put should be a copy of
tftp_get.
-rw-rw-rw- 1 root 1076 May 1 11:39 tftp_get
-rw-rw-rw- 1 root 1076 May 1 15:52 tftp_put
tftp_server_test - runs a tftp server for a short while
This test is truly interactive, in that you can use a standard tftp application to get and put files from the server, during
the 5 minutes that it runs. The dummy filesystem which underlies the server initially contains one file, called “uu”
which contains part of a familiar text and some padding. It also accommodates creation of 3 further files of up to
1Mb in size and names of up to 256 bytes. Exceeding these limits will cause a buffer overflow and unpredictable
failure.
The dummy filesystem is an implementation of the generic API which allows a true filesystem to be attached to
the tftp server in the network stack.
We have been testing the tftp server by running the test on the target board, then using two different host computers
connecting to the different target interfaces, putting a file from each, getting the “uu” file, and getting the file from
the other computer. This verifies that data is preserved during the transfer as well as interworking with standard
tftp applications.
Maintenance Tools
set_mac_address - set MAC address(es) of interfaces in NVRAM
This program makes an example ioctl() call SIOCSIFHWADDR “Socket IO Set InterFace HardWare ADDRess”
to set the MAC address on targets where this is supported and enabled in the configuration. You must edit the source
to choose a MAC address and further edit it to allow this very dangerous operation. Not all ethernet drivers support
398