Subject: Re: [Fwd: AODV implementation]

From: [email-masked] (Bill Paul)
Date: Thu, 4 Nov 1999 13:56:44 -0500 (EST)

[...]
> Additionally, we have attempted to include link-layer feedback to allow
> quicker detection of broken links.  We have been using using drivers for
> the Lucent WaveLAN 802.11 PCMCIA cards with drivers from both
> TriplePoint, Inc. and Andy Neuhaus.  Neither have offered any assistance
> in the way of achieving such feedback from their drivers, so this aim
> has been postponed.
[...]
 
Regards the drivers and radio interaction:
 
Note that it is not particularly easy to do this with the WaveLAN/IEEE
cards when operating in "ad-hoc" mode. As I've mentioned in the past,
Lucent doesn't actually implement IBSS mode in the same manner as
the Aironet cards: they actually implement pseudo-IBSS mode, which
operates without any explicit association between stations. Basically,
as soon as you activate the card, you are "connected" to the network.
If another station happens to be within radio range, you will be able
to communicate with it (ping it, open TCP connections, etc...). If
that station moves out of range, you won't get any special indication
from the NIC: the only thing you'll notice is that packets from the
other station have stopped coming. An additional side effect of this
behavior is that it's impossible to group ad-hoc stations into separate
cells at the link layer: all WaveLAN/IEEE stations operating in ad-hoc
mode implicitly end up in the same ad-hoc network and will hear each
other's traffic as long as they're within radio range.
 
My understanding is that Lucent wants to implement proper IBSS mode
in their firmware, however I don't know what their schedule is.
 
With real IBSS mode, ad-hoc stations form a private service set with one
station being the "master" station. Once associated, you can inspect
the BSSID stored in the NIC; this value is unique to the service set,
and is chosen randomly by the master station when it's first activated.
If you move out of range of the service set, this BSSID value will change
(it will become all zeros, or possibly some other "empty" value). This
mechanism is also used in BSS mode with an access point, only in that
case the BSSID is the MAC address of the access point instead of some
random value. (Note that this applies to the WaveLAN/IEEE cards as well:
when a WaveLAN/IEEE card is associated with an access point, the BSSID
will indicate the access point's MAC address. When not associated, the
BSSID contains some bogus value -- if I recally correctly, I think it
contains 44:44:44:44:44:44.)

The Aironet NICs maintain the association with the "master" ad-hoc
station by exchanging beacons. When you see the green LED flickering
even when the host isn't sending any data, those are the beacons being
exchanged. The beaconing interval can be adjusted: the slower you make
it, the more time it will take for the NIC to decide that it has become
disassociated from the ad-hoc service set.
 
With the WaveLAN/IEEE cards, the BSSID has no meaning in "ad-hoc" mode:
it's always an "empty" value whether you're in range of other ad-hoc
stations or not. The only thing you can do to detect "broken links"
is to monitor the signal strength when receiving packets. The host
software has to decide when the signal has degraded enough to consider
the connection between stations to be broken.
 
Both of the Linux drivers mentioned here use the Lucent HCF library
for communication with the NIC (the TriplePoint one uses the commercial,
proprietary version while the other uses the freely available HCF Light
version). I'm reasonably sure there's a way to extract the signal strength
field from the received frame header. In my driver, you can get it by
just reading the wi_q_info field from the wi_frame structure.
 
The source code for aironet/WaveLAN/IEEE cards drivers can be found at: 

http://comet.columbia.edu/cellularip/device/main_code.html
 
We are using these drivers in two projects in the COMET Group:
  
1) Cellular IP (we will release the source code next week)
   see: http://comet.columbia.edu/cellularip

2) INSIGNIA
   see: http://comet.columbia.edu/insignia/

-Bill

-- 
=============================================================================
-Bill Paul            (212) 854-6020 | System Manager, Master of Unix-Fu
Work:         [email-masked] | Department of Electrical Engineering
Home:  [email-masked] | Columbia University, New York City
=============================================================================
"Mulder, toads just fell from the sky!" "I guess their parachutes didn't open."
=============================================================================

---

From: Kevin Purser <[email-masked]>
Date: Fri, 05 Nov 1999 13:18:23 +0100

Bill,

Yes, we are aware of this- I should have been more explicit in my mention of
"link-layer feedback".  Actually, what we want is to receive feedback (in whatever
shape or form) from the driver to realize if a neighbor is down after trying to
forward data to it.  In other words, we're tried to activate something similar to
RTS/CTS mechanisms in the drivers, but to no avail.  We tested this simply by
beginning to periodically ping the neighbor and removing the neighbor's wavelan
card.  Unfortunately, the driver on the maching initiating the ping packets (using
sizes up to 1024 bytes) never threw any indication of a failed link.

Perhaps this clarifies our intentions to some extent?

Kev

--
==========================================
Kevin Purser
Switchlab, Ericsson Radio Systems AB
------------------------------------------
Torshamnsgatan 23, Kista
S-164 80 Stockholm, Sweden
------------------------------------------
Phone: +46 (08) 508 78 101
Fax:   +46 (08) 508 78 090
==========================================