These modifications require no
changes to the clients configuration.  This has the side effect that
automatic configuration of addresses is not possible with this package.  
The terrestrial network is brought into the ad hoc network much as any other
ad hoc node, receiving and producing route requests as normal.

The only assumption is that the entire ad hoc network can be aggregated
into a single subnet (of any bit length).

Client configuration
====================

Make sure you have a default route that uses the wireless interface.
For example if your wireless interface is eth0, this is as simple as:
route add default eth0

Gateway configuration
=====================

Unicast Operation
-------------------
For unicast operation, the gateway does not require a terrestrial routing
daemon, assuming static routes exist in the kernel's routing daemon.  For
multicast behavior, a terrestrial routing daemon (such as DVMRP or MOSPF)
is required for proper operation.  For basic unicast operation (assuming
it has not been compiled with -DMAODV), add -w parameter to the aodv
start-up:

aodvd -i eth1 -w

If you wish to run a terrestrial routing daemon, you can choose to either
export the ad hoc network as OSPF External LSAs, or have the ospf daemon
sit on the interface as if it was a normal wired interface.  The
configuration we used is:

routerid 192.168.1.1
area 0.0.0.0
interface eth0 1
area 0.0.0.1
interface eth1 1
passive

eth1 is the wireless interface and eth0 is the wired interface.
The passive option keeps ospf from flooding onto that interface.  

Multicast Operation
-------------------
Multicast operation requires the use of a multicast routing daemon,
maodv-umd will not touch the multicast routing table while in gateway mode.
This is necessary due to the tenuous nature of vifs and mrcs.  Our testing
used mospf with the following configuration:

routerid 192.168.1.1
mospf
area 0.0.0.0
interface eth0 1
area 0.0.0.1
interface eth1 1
passive

Any routing daemon should work so long as it can listen on both interfaces
and respond to IGMPv1.  maodv-umd will create and inject IGMPv1 packets 
into the wireless  
interface so that the terrestrial router can treat the ad hoc network as a
normal wired interface using IGMP as the group management protocol instead
of needing to process MAODV.

Additionally, due to some issues with the multicast packet relaying in the
maodv-umd gateway code, a default multicast route is needed on the gateway
that routes onto the wireless network.  If the wireless interface is eth1,
this should be:

route add -net 224.0.0.0/4 eth1

Once this configuration is performed, the two routing daemons can be
started and restarted in any order:

aodvd -i eth1 -w
ospfd

It is worth mentioning that if the maodv-umd daemon is restarted, all
knowledge of participating multicast groups on the wireless network is
lost.  Once the group hellos are received, this situation should be
quickly resolved.

Final Notes
-----------
The aodv gateway code can only handle one wireless network per gateway.
Attempts to use more than one are undefined and will probably end in
tears.