
=======================================================================
	This directoty is now obsolete, replaced by the ewb directory
=======================================================================

Ethernet to Wireless Bridge
(aka Wireless Distribution System -- WDS)
February 2008

This is the code for an ethernet to wireless bridge.
It acts as a wireless distribution system, bridging an ethernet segment across
a wireless link to the enterprise behind the wireless access point.
This bridge is implemented as a virtual device driver which sits between the
ethernet and wireless drivers and the tcpip stack.
It is by necessity very specific to the Treck interface. 

The bridge (wds) registers as a driver with the Treck stack, using the
naIfConfigCreateInterface function provided in bsp/common/naifconfig.c.
The bridge provides a registry interface for the network drivers below,
providing naEwbConfigCreateInterface and the corresponding support functions
to enable the network drivers to initialize in the manner to which they 
are accustomed.

Calls from the network drivers into Treck functions (tfXXXX()) are generally
replaced at compile time with calls into analogous Bridge functions (bfXXX()). 

After registry is complete, the general data flow through the bridge is:
	Data enters the WDS driver from Treck by the function tfDeviceSend.
	Data enters the WDS drvier from the network drivers by the function
		bfRecvInterface.
	The WDS driver bridges each packet to either the Treck stack 
		(via tfRecvInterface) or a network driver (via bfDeviceSend).

The WDS driver does not instantiate any threads, but runs entirely on 
execution threads initiated from Treck applications or network drivers.
The WDS driver adopts the MAC address of the ethernet interface as the
address to associate with the Treck IP stack. 

The bridging logic is driven from a hash table constructed by the WDS 
on the basis of observing which interface every source MAC address arrives
on, and subsequently forwarding packets to each MAC address based on that
observation.

Buffer handling is the trickiest part of the implementation. Determining
how to free a buffer when its work is done requires close observation.

