host.txt

开放源码实时操作系统源码.

Host Software for Automated Network Testing for eCos
====================================================

Hugo Tyson, Red Hat, Cambridge UK, 2000-10-20


What Host Software?
-------------------

This note refers to the package CYGPKG_NET_AUTOTEST which lives in
packages/net/autotest in the eCos repository.

It contains, amongst other things, some software to run a "network testing
server" which eCos network test cases (from the same package) use to test
the network stack.

The reason such a server is needed is simple: testing the eCos network
stack involves an external, standard, computer _doing_things_to_ the target
board as well as having the target board's test program do things itself.

For example, one test case (in the main network package, net/tcpip) to test
TFTP will get a file from a server using TFTP and put the data to another
file on the server using TFTP.  This tests the ability of the eCos TCPIP
stack to act as a TFTP client.  But it does not test the eCos TCPIP stack's
TFTP server at all.  To do that an external agent must act as client -
using the standard tftp(1) app on linux, for example - to put and get data
to and from an eCos testcase running on the target, offering a TFTP server.


Quick Start Guide
-----------------

Set up your LINUX machine to serve DHCP to the target you want to test;
ensure that any 10.0.0.x addresses used are given a class C (/24) netmask.
Provide a genuine gateway to the internet via some route; the routing tests
expect to ping www.cygnus.com!  Also let it have the normal networking apps
(tftp, ftp, ping) and servers (tftpd, ftpd) available, plus the SNMP
package from UCD: snmpwalk and snmpstatus and standard MIBs.

Make sure it is on on the same network(s) as the target you want to test.

Set up aliases for loopback interface on the servers: on server for eth0 on
the target, add an alias for 10.0.3.1/24.  For eth1, 10.0.4.1/24.

With a checked-out eCos source tree, change directory into either
packages/net/autotest/current/host or a copy of it, and type make.

Follow the printed instruction to change the simple executable "./_suping"
to su root execution.  You will need to become root temporarily to do this.

Make sure . is on your path and type "awaitorder | obey.sh" to run the
server; it prints info about messages it receives and sends.

The test server is now running.  You can now run test built from the
CYGPKG_NET_AUTOTEST package (packages/net/autotest) on your target and they
will talk to this host test server.


Categories of Tests
-------------------

 o Host passive

	The host is server, the eCos test case is the proactive client.

	Such tests use the host to talk to, where the eCos testcase is the
	client, and the host is the server.  The network testing server is
	not involved in these tests, but other servers which must be set up
	there are used.
 
 o Host proactive

	The host is client to the eCos server.

	The target board running eCos is the server, the host must run
	scripts to do thing to it and report success or otherwise over the
	net.  The eCos test case typically starts a server, issues order
	about how to test it, then sleeps for a time until the test is
	deemed complete.


Building the Network Testing Server
-----------------------------------

Cd into either packages/net/autotest/current/host or a copy of it, and type
make.  The standard makefile just compiles ./awaitorder.c into ./awaitorder
the executable that waits for a request from a testcase and prints it to
its stdout.  It also builds some other utilities that are used by the test
scripts, for example ./tmpfile from ./tmpfile.c - this just creates a file
of random data for passing back and forth.  It also builds _suping: make
sure this is suid-root to be able to flood-ping the target.


Running the Network Testing Server
----------------------------------

Make sure "." is on your path, early enough, then

	awaitorder | obey.sh

This is all you need to do to run the testing server.


"./awaitorder" just waits for a connection on TCP port 9980 and prints what
it receives.  For example, to test it:

		% telnet masala 9980
 you type --->	Eggs, bacon, beans, mushrooms, toast and coffee
		Acknowledged
		Connection closed by foreign host.
		% 

and awaitorder will print as follows:

		 % awaitorder 
		awaitorder: connection from 172.16.19.13:3739
		ORDERS: Eggs, bacon, beans, mushrooms, toast and coffee

and continue waiting for the next order.


"./obey.sh" does rather more.  It assumes that its stdin is connected to a
source of orders, and it expects that lines of input will look like this:

	ORDERS: TFTP_SERV_GET 10.16.19.171 300

or more generally

	"ORDERS:" [XFAIL] <order> <target IP> <extra params...>

The set of valid orders (TFTP_SERV_GET, TFTP_SERV_PUT ...) will expand with
time as we add more tests.

Having checked that an order looks generally valid, and set up some
environment, it then switches on the order to execute a test script to do
what the testcase that sent the order wants.  The extra params are given to
the test script.  The test script is invoked in background, so that several
sessions can be running at once to hit the target board hard, or of course
one network testing server can be servicing several target boards running
different testcases all at once.  After the test script is launched,
obey.sh just loops back to reading an input line, to get the next order.

"XFAIL" in parameter 1 means the target is configured to simulate network
unreliability, or otherwise be uncooperative.  It is passed both to the
individual testing scripts and to the system for returning status messages
to the test target.

This structure is designed to allow separate development and testing of the
individual parts of the network testing server and also of new testcases;
the eCos testcase and its test script can be developed on your desk without
running the network test server - you only need to knit them all together
at the end by adding a simple clause to obey.sh to invoke the test script
automatically.


Test Script Environment
-----------------------

There is some IO redirection nastiness in obey.sh to separate errors from
good status from status to return to the eCos testcase and so on.

awaitorder takes care to issue complaints to stderr, whilst obviously its
stdout is piped in to obey.sh

obey.sh takes care to issue problem reports to stderr, and mere commentary
to stdout; neither is paricularly verbose right now, so there's no need to
so anything special.

Individual test scripts are invoked as follows.  Stdout is directed to a
logfile named uniquely and for the test in question, according the the
variable $LG.  Stderr is piped to an acknowledgement agent, by default
"./sendack.sh", which is invoked with the target address as its argument.
This returns status messages from the host testing script to the eCos
testcase via TCP port 9990.

Let's look at the two example switch cases for the TFTP tests.  There are
two to mostly put versus mostly get files with the eCos TFTP server.

    # Now the main swicth that runs the test script: this is where
    # new testcases are added:
    case $TEST in

    TFTP_SERV_GET)
    tftpget.sh $TARGET $WF/tftpget.$unique ${PARAMS[@]} \
	    2>&1 >$LG/tftpget.$unique | $SENDACK $TARGET & ;;

    TFTP_SERV_PUT)
    tftpput.sh $TARGET $WF/tftpput.$unique ${PARAMS[@]} \
	    2>&1 >$LG/tftpput.$unique | $SENDACK $TARGET & ;;

OK, this is horrid.  But breaking up one example:

this first part is the invokation of the script:

    tftpput.sh $TARGET $WF/tftpput.$unique ${PARAMS[@]}

its arguments are

    tftpput.sh <target IP> <temporary file> <timeout> <filesize>

 o <target IP> is $TARGET, from the original order.

 o obey.sh has invented <temporary file> with a unique id, in the workfiles
   directory, $WF.  It will typically be "/tmp/auto/wf/tftpput.1138".  In
   this example, the test script will make files called
   "/tmp/auto/wf/tftpput.1138.src" and "/tmp/auto/wf/tftpput.1138.tmp" to
   play with; one is created by the tmpfile program, the other read back