X-Sylpheed-Account-Id:1
S:andy.sharp@onstor.com
SCF:#mh/Mailbox/sent
X-Sylpheed-Sign:0
X-Sylpheed-Encrypt:0
X-Sylpheed-Privacy-System:
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	492C8E44.4050303@onstor.com
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 26 Nov 2008 13:40:27 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Bill Fisher <bfisher@onstor.com>
Subject: Re: VSVR Test Program Description
Message-ID: <20081126134027.53bb3dca@ripper.onstor.net>
References: <492C8E44.4050303@onstor.com>
Organization: Onstor
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 25 Nov 2008 15:46:12 -0800 Bill Fisher <bfisher@onstor.com>
wrote:

> Andy:
> 
> Here is the description of what we talked about.
> 
> In the nfx-tree/code/ssc-mgmt-bus directory, there
> was a BSD socket test program written by Tim Gardner
> that ran under OpenBSD to send neteee messages
> to/from the SSC to the TxRx.
> 
> This was a simple BSD socket based program with a few
> command line options to designate client or server
> along with sending basic messages.
> This covered only bare bones unit testing. The program
> did NOT test all of the neteee protocol features
> like fragmentation, etc. Something else must have
> been used to fully test the neteee module under
> SSC Linux.

Nothing.  I doubt that program was even used.

> The test program assumes the mgmt bus device driver is
> working AND the netee protocol module has been
> debugged. It can run in either "loopback" mode or
> via sending target socket address'es in the
> form <family, backplane, slot, cpu, application>.
> 
> A sample address is <AF_EEE, BPLANE(2), slot, cpu, appl>
> 
> I hacked this program to extend to use as the basis
> of testing the mgmt bus device driver and
> neteee protocol module, under TxRx Linux.
> 
> I have already reworked both the mgmtbus device driver
> to be aware of SMP Linux with locking as well as having the
> proper compilation features specific to both 1125 or 1480's.
> 
> My test program useage line looks like:
> 
> neteee-test:
>   [-a slot.cpu.app] # destination sending address; default: 0.1.1
>   [-i]     # ignore id mismatches; use when rcv from multiple sources
>   [-l]     # length of packet to send
>   [-n num] # number of packets to send/receive
>   [-s|-r]  # send or receive mode; default is send
>            # default: listen/receive address: 0.0.1
>   [-v]     # verbose; output message for each received message
> 
> 
> With this basic client/server side socket program, the
> next step was to extend this unit test program
> to send VSVR messages over the same path.
> So I am extracting the message code from the
> SSC vsvr code and sending sample messages
> to the TxRx daemon side. The TxRx daemon
> simply turns the message around with some
> "canned" reply.
> 
> This is the starting basic unit test program
> for the VSVR message types that get send/received
> from the txrx user daemon. Since VSVR is Phase 2,
> this is the obvious first step. The next step is
> to morph the basic test code which sends and parses
> the various messages into code which implements
> there semantics under TxRx Linux. That is the
> netfilter work and the separate routing tables,
> IP address alias'ing on the interfaces, etc.
> All of the implementation of the "semantics"
> are assigned to you. This simply gets the
> message to the other end, parses it and
> dumps out the various parameters.
> 
> Later,
> 
> -- Bill
> 
> 
> 
> 
