Subject: [manet] MANETs, 802.11, channels and frequencies

From: Claudio Lavecchia <[email-masked]>
Date: Wed, 09 Mar 2005 11:15:22 +0100

Hello everybody,

I have a question concerning the setup of a testbed for a MANET based on 
802.11.
In fact I am maintaining such a testbed and lately I have noticed weird 
behaviors from 802.11 devices.

My testbed is done of PDAs (ipaq 3950 with Familiar Linux OS) and 
laptops. I use PCMCIA WLAN adapters (dell truemobile 1150) that work 
with Orinoco driver. I route the traffic using OLSR in the Unik 
implementation.
The wireless connectivity among the nodes of my MANET has been really 
unstable those last days to the point that even pings between two nodes 
of the network were failing.

This is my analysis of the thing, I would like to know if someone shares 
my idea:
Essential requirement to have two devices communicating using 802.11 
WLAN adapters in ad-hoc mode is that the two cards must be set to 
operate on the same channel (= same frequency). Wireless extensions 
implemented by the Linux driver provide the administrator with a command 
that sets the channel. This command is "iwconfig channel XXX". Now when 
I try to use this command, I observe that the channel is not always set 
correctly. As a result of this, my devices are not set on the same 
channel and there is no wireless connectivity.
The intuition I have (and I really don't know whether this is right or 
not) is that when you do a "iwconfig channel XXX", the WLAN adapter is 
set to the required channel but it keeps monitoring what happens in 
other channels, too. If it hears "beacons" in channel XXX it will stay 
tuned to this channel. If there are no "beacons" in channel XXX, but it 
hears some beacons in channel YYY, the WLAN  adapter will  autonomously 
reset its channel to channel YYY. I am not 100% that talking of 
beaconing is correct in this scenario, as we are talking of ad-hoc mode, 
but beacons can be for example the ones coming from the routing protocol.

Can anyone put the light in this darkness?

Thanks a lot

Claudio

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Andrés Lagar Cavilla <[email-masked]>
Date: Wed, 09 Mar 2005 07:08:38 -0500

Hi Claudio

I had a similar experience in which two Enterasys RoamAbout cards (attached 
to laptops, Orinoco driver as well) would stop speaking to each other even 
in close proximity. Eventually they would reconnect, but for unpredictable 
amounts of time. This made any experimentation pretty much impossible.

In this case the reason was not the channel but the cell number. For some 
reason, 802.11 ad hoc (IBSS) generates a random cell number on which all 
stations agree: this has been brought up recently in the mailing list. 
However, the two laptops would "de-associate" themselves, i.e. disagree on 
their cell numbers. One would stay within its 00:02:xx:xx:xx:xx cell, while 
the other one switched to a (presumably default) 44:44:44:44:44:44 cell. 
This effectively prevented communication.

Apparently, in IBSS (aka ad hoc) mode, one of the machines assumes the role 
of a master, sending beacons to all the cell members. It was clear that 
beacons were not being received, and hence the de-association. We solved 
this by switching to a proprietary ad hoc mode with the command "iwpriv 
set_port3 1". This ad hoc mode is outside the 802.11 standard, but needs no 
cell agreement (both machines stood in cell 00:00:00:00:00:00 the whole 
time). Things went like a breeze after that, everything worked perfectly 
with no fluctuations or performance downgrades. This "Lucent demo" ad hoc 
mode may not be available outside Orinoco cards, though
Cheers

Andres

At 05:15 AM 3/9/2005, Claudio Lavecchia wrote:
>My testbed is done of PDAs (ipaq 3950 with Familiar Linux OS) and laptops. 
>I use PCMCIA WLAN adapters (dell truemobile 1150) that work with Orinoco 
>driver. I route the traffic using OLSR in the Unik implementation.
>unstable those last days to the point that even pings between two nodes of 
>the network were failing.
>
>Essential requirement to have two devices communicating using 802.11 WLAN 
>adapters in ad-hoc mode is that the two cards must be set to operate on 
>the same channel (= same frequency). Wireless extensions implemented by 
>the Linux driver provide the administrator with a command that sets the 
>channel. This command is "iwconfig channel XXX". Now when I try to use 
>this command, I observe that the channel is not always set correctly. As a 
>result of this, my devices are not set on the same channel and there is no 
>wireless connectivity.
>not) is that when you do a "iwconfig channel XXX", the WLAN adapter is set 
>to the required channel but it keeps monitoring what happens in other 
>channels, too. If it hears "beacons" in channel XXX it will stay tuned to 
>this channel. If there are no "beacons" in channel XXX, but it hears some 
>beacons in channel YYY, the WLAN  adapter will  autonomously reset its 
>channel to channel YYY. I am not 100% that talking of beaconing is correct 
>in this scenario, as we are talking of ad-hoc mode, but beacons can be for 
>example the ones coming from the routing protocol.
>

---

From: Claudio Lavecchia <[email-masked]>
Date: Wed, 09 Mar 2005 14:03:30 +0100

Andres,

What you say is very interesting.
I observed exactly the same fluctuations in the cell number. I tought 
that that might be the reason for the communication breakdown  I was 
experiencing but at that time I concluded that when devices work in 
ad-hoc mode, the constraint of having the same cell number was kind of 
weak. In short I concluded that two devices can communicate even when 
they do not have the same cell number because when they work in ad-hoc 
mode the concept of association loses its relevance. Reading your 
suggestion I realize that my deduction could have been wrong.
So, I have now a few questions for you:

1) Are you sure that your problems were caused by cell number and not by 
channel?
2) Do you think that there could be some relationship between cell 
numbers and channels?
3) What does your "iwpriv set_port3 1" command do exactly? I guess in 
order to have my testbed running "as breeze" (I like the image!) I 
should just execute this on all the devices?

Thanks a lot for your contribution!

Claudio

Andrés Lagar Cavilla wrote:

> Hi Claudio
>
> I had a similar experience in which two Enterasys RoamAbout cards 
> (attached to laptops, Orinoco driver as well) would stop speaking to 
> each other even in close proximity. Eventually they would reconnect, 
> but for unpredictable amounts of time. This made any experimentation 
> pretty much impossible.
>
> In this case the reason was not the channel but the cell number. For 
> some reason, 802.11 ad hoc (IBSS) generates a random cell number on 
> which all stations agree: this has been brought up recently in the 
> mailing list. However, the two laptops would "de-associate" 
> themselves, i.e. disagree on their cell numbers. One would stay within 
> its 00:02:xx:xx:xx:xx cell, while the other one switched to a 
> (presumably default) 44:44:44:44:44:44 cell. This effectively 
> prevented communication.
>
> Apparently, in IBSS (aka ad hoc) mode, one of the machines assumes the 
> role of a master, sending beacons to all the cell members. It was 
> clear that beacons were not being received, and hence the 
> de-association. We solved this by switching to a proprietary ad hoc 
> mode with the command "iwpriv set_port3 1". This ad hoc mode is 
> outside the 802.11 standard, but needs no cell agreement (both 
> machines stood in cell 00:00:00:00:00:00 the whole time). Things went 
> like a breeze after that, everything worked perfectly with no 
> fluctuations or performance downgrades. This "Lucent demo" ad hoc mode 
> may not be available outside Orinoco cards, though
> Cheers
>
> Andres
>
>> I have a question concerning the setup of a testbed for a MANET based 
>> on 802.11.
>> In fact I am maintaining such a testbed and lately I have noticed 
>> weird behaviors from 802.11 devices.
>>
>> unstable those last days to the point that even pings between two 
>> nodes of the network were failing.
>>
>> This is my analysis of the thing, I would like to know if someone 
>> shares my idea:
>> implemented by the Linux driver provide the administrator with a 
>> command that sets the channel. This command is "iwconfig channel 
>> XXX". Now when I try to use this command, I observe that the channel 
>> is not always set correctly. As a result of this, my devices are not 
>> set on the same channel and there is no wireless connectivity.
>> The intuition I have (and I really don't know whether this is right 
>> or not) is that when you do a "iwconfig channel XXX", the WLAN 
>> adapter is set to the required channel but it keeps monitoring what 
>> happens in other channels, too. If it hears "beacons" in channel XXX 
>> it will stay tuned to this channel. If there are no "beacons" in 
>> channel XXX, but it hears some beacons in channel YYY, the WLAN  
>> adapter will  autonomously reset its channel to channel YYY. I am not 
>> 100% that talking of beaconing is correct in this scenario, as we are 
>> talking of ad-hoc mode, but beacons can be for example the ones 
>> coming from the routing protocol.
>>