
Release Pack 1.40 - Beta, July 1994
===================================

This release note covers Ethernet device driver modules for a number
of different Ethernet interfaces manufactured by ANT.  The relevent
driver module and interfaces are as follows:


EtherP
======

The EtherP driver is for driving the Pocket Ethernet Adaptors
(sometimes known as 'PEAs') available from Atomwide and all ANT
dealers.


EtherB
======

The EtherB driver is for driving the Risc PC NICs (for the Network
Slot) available from Acorn, Atomwide and all ANT dealers.



Ether3
======

The Ether3 driver is for driving EtherA (now superceded) and Ether3
Ethernet cards available from Acorn, Atomwide and all ANT dealers. The
range of cards includes those for A400, A3000 and A3020 use. The
former requires a 16 bit version of Ether3, and the others require an
8 bit version of Ether3.



Summary:


Card	Machine		Driver		Notes
----------------------------------------------------------------


PEA	A4, A5000,	EtherP		Requires bidirectional
	A3020, Risc PC			parallel port


Ether3	A400, A540,	Ether3		16 bit variant of Ether3
	Risc PC				driver required (Risc PC
					via A400 style podule slot)


Ether3	A3000, A3010,	Ether3		8 bit variant of Ether3
	A3020				driver required


EtherB	Risc PC		EtherB		Plugs into new style
					Network Slot





What has changed
================

A number of bugs have been fixed, some minor and others not so minor.

Support for ISO packet types has been improved. This is necessary for
correct operation with Aleph One PC Cards and network cards.

Support for multicast packets has been incorporated (see note 1,
below). This is necessary for some operations with Aleph One PC Cards
and network support.

Support for "sink" packet receiption has been extended (see note 1).

A special version with support for promiscuous receiption permits
network monitoring and low level packet repeating (with suitable
additional software).  As neither of these modes of operation is
"typical" of normal user mode operation, and as promiscuous mode
operation inherently poses a security compromise, this version is not
distributed as standard. Network managers may contact ANT directly to
enquire about the availabilty of these items.

Support for the 80C04 CMOS Ethernet controller. These controllers
consume less power and produce less heat.

Previous versions of the Ether3 module supported arbitary mixes of 8
and 16 bit cards. Users who previously used a single Ether3 driver to
support a mixture of 8 and 16 bit Ethernet cards should contact ANT
for assistance.

The syntax and naming of the configuration commands has been improved.
It is suggested that you check the configuration reported after
installing a new Ether3 module to ensure suitable operation.


Note 1: These enhancements are outside the current DCI2b specification
and so may not yet be supported by other manufacturers cards.



Ethernet card selftests
=======================


The first three tests perform basic functionality tests on the Ethernet
controller and the associated buffer memory.



Locate controller  . . . .
--------------------------

This tests that the Ethernet controller can be accessed and that it's
internal registers are operative. This test should never fail.


Interrupts . . . . . . . .
--------------------------

This tests basic functionality of the interrupt generation of
the Ethernet controller. This test should never fail.


Buffer memory  . . . . . .
--------------------------

This tests the buffer memory contained on the Ethernet card. If the
driver module is configured for verbose operation, then more extensive
(and time consuming) tests of buffer memory are performed.  This test
should never fail.

If there is insufficient RMA available for the buffers used by this
test, then it is deemed passed. If selftesting is being reported, this
test is annotated as being skipped if there is not sufficient RMA.


The tests that follow these three basic tests are packet transmission
and receiption tests. There are three variants of the packet test,
performed first in loopback mode within the Ethernet card, and
secondly on the live network (if *Configured for "livewiretest", see
below). These tests verify the correct operation of many components of
the interface.



Loopback, correct CRC  . .
Loopback, incorrect CRC  .
Loopback, controller CRC .



Livewire, correct CRC  . .
Livewire, incorrect CRC  .
Livewire, controller CRC .


If a selftest fails, then this will always be reported on the screen.
If any selftest fails, users a strongly recommended to contant their
network managers.


An Ether3 driver module controlling a 16 bit card with "verbose"
configuration selected produces the following output on selftests:


Locate controller  . . . . 80C04 16 bit MEMC1a in slot 1
Interrupts . . . . . . . . PASSED
Buffer memory  . . . . . . PASSED
Loopback, correct CRC  . . PASSED
Loopback, incorrect CRC  . PASSED
Loopback, controller CRC . PASSED
Livewire, correct CRC  . . PASSED *
Livewire, incorrect CRC  . PASSED *
Livewire, controller CRC . PASSED *


Note: If "nolivewiretest" had been configured, the last three lines
would not have been printed.



Interface Statistics
====================

Each of the Ethernet driver modules described supports a command
to print interface statistics. These commands are:

Driver module           * command
---------------------------------
			       			      
EtherP			EPInfo
EtherB			EBInfo
Ether3			E3Info



Under normal operation, the interface statistics gathered can
generally be ignored. However, as a network problem diagnostic tool,
interface statistics can be invaluable.

The most important thing to do when determing the cause of network
problems is to determine at what level the error is occurring. It
might be a physical problem (network not connected, server on a
physically different and unconnected network), an Internet
configuration problem (only normally encountered with custom Internet
configurations), a routing problem (noT uncommon when initially
connecting multiple networks together), etc.

Two major clues can be obtained from the interface statistics.
Firstly, major packet errors have their own count - if any of these
counts is non-zero, then a low level network problem exists and needs
investigating and correcting. For example, receiption of packets of
CRC errors suggests the network cabling might be faulty somewhere.

The next major clue is the count of packets transmitted and received.
When access to a fileserver or other network facility appears
unavailable, the first thing to determine is whether the server
machine is contactable at all over the network. This is typically
performed with the "ping" (TCP/IP) and "netprobe" (AUN) commands.
Under normal operation, each ping/netprobe causes (at least) one
packet to be transmitted and (at least) one to be received under
normal operation.


As an example of the printing of interface statistics, the following
shows a *E3Info output in "verbose" mode:

*e3info
Ether3 interface statistics

ea0: 80C04 16 bit MEMC1a, slot 1, up, hardware address 00:02:07:00:10:28

Packets received = 15                  Packets transmitted = 1                
Bytes received = 1654                  Bytes transmitted = 46                 
Receive interrupts = 15                Transmit interrupts = 1                
Receive errors = 0                     Transmit errors = 0                    
Rx packet too small = 0                Tx packet too small = 0                
Rx packet too long = 0                 Tx packet too long = 0                 
Rx failed: CRC error = 0               Tx failed: 16 collisions = 0           
Rx failed: no buffers = 0              Tx failed: no buffers = 0              
Rx failed: no memory = 0               Tx failed: no memory = 0               
Receive babble error = 0               Tx failed: blocked = 0                 
Receive dribble error = 0              Unknown frames = 0                     
Buffer overflow = 0                    Failed early read attempts = 0         

Standard clients:

Frame = &0800, ErrLvl=00, AddrLvl=01, FrmLvl=00
Frame = &0806, ErrLvl=00, AddrLvl=01, FrmLvl=00
Frame = &8035, ErrLvl=00, AddrLvl=01, FrmLvl=00

Log: Ether3 messages can appear here



The message log (the section prefixed by "Log:" above) is used
to record the last error delivered by the Ethernet driver module.



Appendix - Configuration Commands and Options for ANT EtherX v1.40
==================================================================

In general, the configuration options available are the same across
Ether3, EtherB and EtherP modules with the same version number. The
EtherP module does not use CMOS RAM to store its configuration
options, as there is none allocated (to the parallel port) that it may
safely use. Instead, EtherP takes an argument string when being loaded
that contains the necessary configuration options.

The general form for configuration is:

*Configure <driver-name> <option> [socket]

Where:

<driver-name> is Ether3, EtherB or EtherP

<option> is one of the options listed below

<socket> specifies a specific expansion card slot to apply the
configuration option to. This paramater is optional. It is used when
an Ether3 module is controlling more than one expansion socket and it
is desired to update the configuration options associated with only
one expansion socket.

By way of example, the following illustrates how to configure "verbose"
operation:

For Ether3 modules:

	*configure Ether3 verbose

For EtherB modules:

	*configure EtherB verbose

For EtherP modules:

The RMload command in the startup file in the files subdirectory
of the !Internet directory that loads the Ethernet module requires
the options appending. A standard startup file contains a section
similar to this:

| Load driver and initialise Ethernet interface, if required

IF "<Inet$EtherIPAddr>" <> "" AND "<Inet$EtherDevice>" <> "" THEN rmload inet:drivers.<Inet$EtherDevice>

This should be changed to something similar to

| Load driver and initialise Ethernet interface, if required,
| including configuration options

IF "<Inet$EtherIPAddr>" <> "" AND "<Inet$EtherDevice>" <> "" THEN rmload inet:drivers.<Inet$EtherDevice> verbose



Configuration options:
======================


Default
-------

This configuration option forces the other configuration options to
their default values, as specified by the Ethernet driver module
itself.

Disable | Enable 
----------------

Under normal use, all available Ethernet cards should be configured to
be enabled. Under exceptional circumstances, network managers may
choose to disable Ethernet cards. The default option is for all
Ethernet interfaces to be enabled.


Strict | Ignore 
---------------

When configured for strict operation, all selftests performed must
pass.

When configured for ignore operation, any failures during live wire
tests (if performed) are ignored. This option should be excercised
with caution.


NoLiveWireTest | LiveWireTest 
-----------------------------

When configured for nolivewiretest, only the loopback packet tests are
performed.

When configured for livewiretest, loopback and livewire packet tests
are performed.


Terse | Verbose 
---------------

Terse/verbose configuration has three main effects:

1) When performing selftests, a terse configuration does not print
anything if the selftests pass, whereas a verbose configuration always
prints the test being conducted and the test result.

2) Verbose selftests perform a more extensive memory test. This adds
notably to the time it takes to perform selftests, but can be a useful
diagnostic aid.

3) A terse configuration lists only non-zero statistics for its 'info'
command. A verbose configuration includes statistics that are zero.

In general, a terse configuration is better suited to mosts users.
Network managers may choose either configuration for normal use. When
determining the cause of network problems, a verbose configuration is
recommended.


OldInet | NewInet
-----------------

Under normal operation, this configuration option should be set to
newinet.

Versions of the internet module prior to version 2.00 are classified
as "Old Internet" and versions including and subsequent to 2.00 are
classified as "New Internet". New internet modules contain an
optimisation to packet receiption that you are strongly recommended to
use if possible.

Use of a new internet module in an environment expecting an old
internet module is operable. However, use of an old version of
internet in an environment expecting a new internet module is NOT
operable. Version 1.40 drivers fully support operation in both old and
new internet environments. The new internet module does offer faster
packet receiption.



Contact details:
================

Support Team
ANT Ltd
PO BOX 300
Cambridge
CB1 2EG

Phone: 0223 567808
Fax: 0223 567801
Email: support@ant.co.uk


End of document
