We are pleased to announce a new, ROMable version of PCBRIDGE, with
some additional features over the original software. We still plan some
enhancements and changes, but the program is fairly stable at this
point, thus we think it's time to release it.

The software is available by anonymous ftp from pical3.iet.unipi.it
(131.114.9.12), in the directory /pub/bridge.

The following notes apply to PCBRIDGE v.2.77 and higher:

PCBRIDGE v.2.77    by Alessandro Fanelli, Luigi Rizzo (luigi@iet.unipi.it)
05 may 93 18:00   Universita` di Pisa - via Diotisalvi 2, 56126 Pisa, Italy
                         Tel. +39-50-568533  -- Fax +39-50-568522
                (original sources by Vance Morrison, Northwestern University)

Please send your comments and requests to luigi@iet.unipi.it


1. Motivation
=============

PCBRIDGE, in the original version by Vance Morrison, is a quite useful piece
of software. We have been using it for a long time, with great success.
There were, however, a few features we missed:

	- ROMable code. A learning bridge doesn't need any
	  configuration, data, thus it is suitable for a ROM
	  implementation. Also, given that the bridge is usually a
	  unattended device, not having a disk means an increased
	  reliability. Finally, no disk means no MSDOS or other OS license is
	  necessary for the bridge.

	- Auto configuration. It is useful that the bridge can
	  detect its configuration (basically the number of ports) at
	  run time, rather than being forced to have a separate
	  executable for each configuration. This is especially true
	  for a ROM version.

	- Traffic statistics. As the bridge has to analyze
	  all the traffic on the networks it is connected to, it
	  becomes a good candidate for collecting statistics on the
	  traffic. Also, it is important to know informatio on how
	  the bridge is working, e.g. the effectiveness of
	  the filtering performed by the bridge.

	- Remote management. It is useful that the bridge
	  can be managed through the network: it should send
	  its statistics and accept configuration commands
	  from a host on the network.

In the current version of PCBRIDGE, all of these issues have been
solved to some degree. Of course, there are still other features (e.g.
spanning tree algorithm, increased filtering capabilities, etc) that
would be useful and we didn't implement yet.

2. New features

Our PCBRIDGE is based on version 1.21 of PCBRIDGE. The enhancements we made
are mainly related to the WD80x3 version of the bridge, due to the lack
of hardware and interest for other versions of the bridge. We are
confident that the changes we introduced should be easily portable to
other versions of the bridge, but make no promises about them.

We will illustrate the advantages of the new version in some detail.

-- ROMABLE code --
	The sources have been modified in order to produce a ROMable
	code. To this purpose, our code compiles to a .COM file, using
	dynamic allocation for some data blocks (e.g. the filtering
	table) that would not fit into the .COM
		The .COM executable can be run from a disk, or put onto
	an EPROM together with a very simple loader that we include.
	The loader simply copies the .COM bridge code to RAM,
	initializes registers as DOS would do, and jumps to the bridge
	code. The loader can be used for other programs than PCBRIDGE,
	with no changes.

-- Automatic configuration --
	We have added a probe routine (for WD cards) so that the program
	will auto detect, at boot time, which cards are present and
	which ones are not, thus simplifying the use of the bridge. We
	currently use a single executable, compiled for up to 5 card.
	At run time, only existing cards will be used.

-- Loop detection --
	Bridged networks shouldn't have (active) loops, although these
	may be created either by mistake, or on purpose in order to
	increase reliability. If loops are present, bridges must find
	an acyclic graph out of the existing network and work only on
	this graph.
		We don't implement the standard Spanning Tree
	Algorithm, but we DO detect loops and avoid that a bridge will
	retransmit the same packet forever. Loops are detected when a
	bridge sees the same source address on two of its ports. In
	this case, the bridge will disable one of the ports involved in
	the loop, resetting to normal conditions after 10 seconds in
	the hope the loop has been removed. If not, the port will be
	disabled again and again, without retransmitting any packet.
	Note that the loop-detection code is very primitive at this
	time, and we are still working on it. In presence of a loop, a
	multiport bridge is not guaranteed to work, but at least it
	tries not to disturb other stations!

-- Filtering --
	The bridge can be configured in order to pass all packets, or
	filter them depending on ethernet type. Currently this can only
	be set by recompiling the code, or patching it, but we plan to
	make this more easily configurable.

-- Statistics --
	Statistics are accumulated in a set of 48-bit counters. These
	parameters cover both network traffic (# of received packets and
	bytes), and bridge behaviour (# of forwarded, dropped,
	broadcast packets, hash table collisions, interface status).  The
	latter two are of particular importance in measuring the
	effectiveness of the filtering capabilities of the bridge, and
	for monitoring the network.

		Statistics are shown on the screen of the bridge, if
	present.  The software will auto detect a BW or Color screen,
	printing counters in HEX format (because we don't want to waste
	time doing a binary-to-decimal conversion; after all, we only
	want a feeling of what's going on).

		Statistics data are also sent on all the network
	interfaces every 10 seconds, using a proprietary format (which
	is not SNMP). A simple daemon program (also included in the
	sources) running on Unix can monitor the status of all the
	bridges in the network, being extremely helpful in problem
	determination.

-- Remote management --
	The same daemon program which receives statistics is also
	reported of the status of the interfaces: the bridge recognizes
	an open- or short-circuit on the wire (because this gives rise
	to transmission failures due to too many collisions) and also
	reports whether a port is disabled (because of a loop) or not.

		The bridge also accepts a few command from the network:
	DUMP_DATA_SEG	dumps part of the bridge's data structure.
	DUMP_TABLE	dumps part of the bridge's filtering table.
	FLUSH_TABLE	flushes the filtering table.
	RESET		performs a cold reset of the bridge.

	These commands have been inserted mainly for testing purposes,
	and are not really needed during regular use. Actually, we plan
	to remove them in the future.

3. Setting up a bridge

In order to build our bridge, you need:

- a 286+ motherboard with at least 256K RAM, and a power supply.
  We are currently using 386sx-33 motherboards, which prove effective.

- 1(yes, one)..5 ethernet cards (SMC-Elite WD8013 or
  compatibles) configured at any of the following IO addresses:
	0x280, 0x2a, 0x300, 0x320, 0x340.
  Of course, a bridge with one card won't bridge anything, but it will
  monitor network traffic, if you like it.
	We have had very good success with SMC-Elite cards, while older
  WD80x3 clones proved unreliable (i.e. the bridge hangs every now and
  then). This is due to a bug in the old 8390 controllers which is not
  properly dealt with by the bridge software. We didn't fix the bug,
  because we don't know much about it,  and since our bridges with SMC
  cards have been working continuously for over 8 months, we're not too
  concerned about this problem.

- the BRIDGE eprom, or a floppy disk with the BRIDGE software.
  The eprom can be build as indicated in the next section.
  Alternatively, you can put a floppy controller and prepare a bootable
  floppy with the PCbridge code on it.  Either case, the bridge will
  autodetect the existing hardware and start working -- no
  configuration is required.

A video card and monitor, floppy disk, and keyboard are optional
and not required at all for using the bridge.

With all the elements available, you need to:
- configure the ethernet cards with the appropriate IO
  addresses. No interrupts are used, and memory addresses are set at
  run time by the sorftware. Remember to put the eprom on one of them
  (any one) and enable it at address 0xD800.

- assemble the PC with RAM and ethernet cards;
- temporarily using using a video card and keyboard, configure the
  CMOS in order to boot without video, keyboard and disks.
- disconnect video card and keyboard. The bridge is ready.

4. Building the EPROM

The program comes both in source format and executable code. The
assembler requires at least MASM 6.0 to be compiled. Options are

	ml -VM -Duse_filters -Dno_loops bridge.asm

which produces a bridge.com file of about 20K

You can alter the configuration of the bridge which is stored in the
DECLARE.INC file. See the original PCBRIDGE documentation for this.
The binary file (bridge.com) included in the distribution is configured
for passing all packets. If you want to change it, simply recompile the
sources as shown above. Also, have a look at the filtering code in
BRIDGE.INC and CT.INC

In order to produce the eprom, you need to do the following:

- build an eprom image, by compiling and running 'image.c'
- download the image to a eprom programmer. You need a 32K eprom for
  this version of pcbridge.
- burn the eprom.

5. Monitoring the network.

Statistics are sent over the network, via UDP on port 2299, every 10
seconds. A simple program, called pcbridged, will allow you to collect
statistics. pcbridged has been taken from bootpd sources and modified to
serve our purposes. It is a hack, but it works for our purposes.

Commands are accepted via UDP. Check pcbridged.c for more
informations.

6. Future extensions

We are planning the following additions to the bridge code (in order of
importance):

- enable new commands from a manager host.
  Among these commands are:
  - enable/disable bridging on selected ports/hosts.
  - We are very dubious about giving a bridge the ability to download
    and run new code. While it eases management, it can kill a bridge
    (say, if some buggy code is loaded), requiring manual intervention.
- enable software configuration of filtering code.
- add better code for loop detection.
- fix the behaviour for old WD cards

At the moment we don't know whether or not we will be able to add SNMP
support, or the real spanning tree algorithm, or more filtering
capabilities. For some of these issues, you may find it useful some of
the other PD PC-based bridges, such as

- the OSU KarlBridge program, which can be obtained via anonymous ftp
  from nisca.acs.ohio-state.edu, 128.146.1.7, in /pub/kbridge.  Please
  send e-mail to kbridge@osu.edu with questions and comments about it.

- the TAMU bridge and associate software, available via
  anonymous ftp in sc.tamu.edu:pub/security/TAMU

--- end of file ---
