host.txt

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

   from the TFTP server.

 o <timeout> is part of the extra params supplied by the eCos testcase,
   which in this case will serve TFTP for about 5 minutes, so it tells the
   test script to diddle it for about 5 minutes too.

 o <filesize> is another param supplied by the eCos testcase, which tells
   the script to create a testfile of a particular size to exercise edge
   conditions wrt the blocksize.

The second part of the example is the IO redirection and backgrounding:

	    2>&1 >$LG/tftpput.$unique | $SENDACK $XFAIL $TARGET & ;;

This sets the script's fd2 to a copy of its stdout, then sets its stdout to
go to the logfile, typically "/tmp/auto/log/tftpput.1138", then pipes the
original stdout which now occupies fd2 into $SENDACK, the acknowledgement
agent, which is itself invoked with the target's IP address and optionally
XFAIL to tell it not to be so upset if it fails to return the result.  The
whole thing is run in background by the "&" and the ";;" is the end of this
case within the switch statement.  Phew!

More briefly, the test script's stdout goes into the logfile and the test
script's stderr goes into $SENDACK (./sendack.sh) and thence to the
testcase.


Typical Output
--------------

This is the output from awaitorder | obey.sh from running just one eCos
testcase, which requests 3 simultaneous TFTP sessions for 5 minutes:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
awaitorder: connection from 10.16.19.171:34554
test TFTP_SERV_PUT; target 10.16.19.171; params 300 512
awaitorder: connection from 10.16.19.171:46052
test TFTP_SERV_PUT; target 10.16.19.171; params 300 513
awaitorder: connection from 172.16.19.171:25388
test TFTP_SERV_PUT; target 172.16.19.171; params 300 512
10.16.19.171: result INFO:<10.16.19.171 is up>
172.16.19.171: result INFO:<172.16.19.171 is up>
10.16.19.171: result INFO:<10.16.19.171 is up>
10.16.19.171: result PASS:<tftp put OK, 300 seconds 513 bytes 20696 xfers>
10.16.19.171: result PASS:<tftp put OK, 300 seconds 512 bytes 14982 xfers>
172.16.19.171: result PASS:<tftp put OK, 300 seconds 512 bytes 12649 xfers>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

and the eCos test case prints, amongst other things, on receipt of the
results via sendack.sh

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
INFO:<10.16.19.171 is up> (10.16.19.171) (from 10.16.19.13:4764)
INFO:<172.16.19.171 is up> (172.16.19.171) (from 172.16.19.13:4765)
INFO:<10.16.19.171 is up> (10.16.19.171) (from 10.16.19.13:4766)
....
PASS:<tftp put OK, 300 seconds 513 bytes 20696 xfers> (10.16.19.171) (from 10.16.19.13:4775)
PASS:<tftp put OK, 300 seconds 512 bytes 14982 xfers> (10.16.19.171) (from 10.16.19.13:4776)
PASS:<tftp put OK, 300 seconds 512 bytes 12649 xfers> (172.16.19.171) (from 172.16.19.13:4777)
....
PASS:<Results from host[s] OK>
EXIT:<Done>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

This output format will change over time as more features may be added, but
this example should convey the general idea.


Individual Host Testing Scripts
-------------------------------

The params and invocation of these is entirely a matter of agreement
between the eCos testcase and the test script.  A new case arm in the
obey.sh switch statement must be written for any new testcase, so the
script's invocation is not prescribed in any way.

For the sake of easier separate development of testcases, it would be
better to follow the pattern of the other testcases, also for consistency
and comprehensibility.  Here are some guidelines and requirements, but
first some assumptions:

 o One test script "does things to" one target board, and more specifically
   one target IP address.  If you want several things done to your target
   board at once, invoke several scripts at once - all on the same IP
   address if you want, that's fine.

 o The test script may need to be told that the target network stack is
   configured to simulate network unreliability, so the test script should
   not expect perfect communications.  Eg. weaker protocols will in fact
   fail - the point of the test is verify that the target does not hang or
   crash or assert-fail and so on; host side network failures within the
   script are unimportant.  Otherwise, the test script should expect
   correct operation in the operations it performs.

 o The network test server can serve testing to many eCos target boards at
   once.  Therefore any particular test script can be invoked several times
   at once to deal with different target boards, if they happen at random
   to run the same testcase at the same time as each other.  Therefore a
   test script should only use temporary files which are uniquely named per
   invocation.

These lead to requirements and guidelines:

 o Take the flag XFAIL optionally as the first argument, if it is XFAIL
   shift to get the other arguments.

 o Take the target IP address as the next argument; it's an obvious place
   for it and you'll certainly need it anyhow.

 o For workfiles, have obey.sh supply a parameter to name such files
   uniquely.  Use a full pathname.  Include the test type also, for example
   "/tmp/auto/wf/tftpput.1138" identifies the file as belonging to the
   tftpput testcase.  Make required workfiles be second and subsequent
   arguments.

 o Further arguments which are arbitrary and passed from the testcase
   should be last, and passed all together.  It's not convenient in the
   shell to split out words 2 through the end from an array if you already
   quoted word one elsewhere, so instead put all the extras together as in
   ${PARAMS[@]} in the tftpput.sh invocation discussed above.


Other Environment
-----------------

 o DHCP

Set up DHCP to support the target board - it's the easiest way.

The tests know which server to talk to by looking in the server ID field of
the bootp information record; if DHCP or BOOTP is used, this will be the
server that served it.  It is also possible to set up the stack with static
initialization of that field - if you do this, make sure it points to a
machine that is running the network test server.

Setting up the server to serve DHCP to the target boards only is easy;
keeping other DHCP servers, who offer dynamic addresses to any new net
presence, from offering service to them requires a little trick.  A dynamic
server should be set up to supply a static address to the target board's
MAC address, with the additional key: "deny booting;".  This does nothing
malicious, but it lets the server recognize the target board and ignore it.

This ensures that the network test server machine "wins" the race to set up
the target, and so ensures that the test talks to the network test server
rather than trying to talk to a global DHCP server.


 o /tmp clearance

The ongoing testing fills /tmp with log files and work files.  The logs
will likely not be very large, but the work files could be a few Mb per
test run.

A cron job to remove everything older than an hour, or some such might be
useful; or if the machine can stand it, just wipe /tmp/auto every night.


 o Ping!

The tests will expect to ping (and flood ping) the server; it should be
allowed to do this back.  An suid executable (CARE!) is needed to enable
this.  "./_suping" is built by the host makefile: make it be suid root.
It is a trivial app that execs ping after setting the effective UID to
root.  This is necessary because ping is an suid-root executable anyway, to
be able to get at raw sockets; it checks the effective UID to decide
whether to permit flood pinging; we need this for the flood tests floodping
and floodpingmux.


 o Network aliases in the loopback interface

The routing tests require a network setup like this:

  10.0.3.1      A.B.C.D   A.B.C.E        N.M.O.P   N.M.O.Q      10.0.4.1
  -------- Box1 ----------------- target ----------------- Box2 --------


Optionally with 10.0.3 and 10.0.4 being real networks, with other stations
on them; addresses 10.0.x.99 are also pinged.  Alternatively, 10.0.3 and
10.0.4 can be aliases for the loopback device in Box1 and Box2 (which may
be the same box really).  A typical setup might really look like:
             
  HOST: eth0 172.16.19.13 ------ 172.16.19.171 eth0 on TARGET
  HOST: eth1 10.16.19.13 -------- 10.16.19.171 eth1 on TARGET
  HOST: lo:0 10.0.3.1
  HOST: lo:1 10.0.4.1

with all netmasks being /24 (255.255.255.0).

This means that the target can only ping addresses 10.0.3.x and 10.0.4.x if
a route has been set up via 172.16.19.13 or 10.16.19.13 (respectively, for
the case of having two distinct hosts).  The routing tests verify that
behaviour.


 o TFTP server and its files

No test of the eCos TFTP client yet, so no details here.

 o FTP server and its files

No test for the eCos FTP client yet, so no details here.



.fin