[B.A.T.M.A.N.] tangentially driver related question on broadcasts with batman-adv

[B.A.T.M.A.N.] tangentially driver related question on broadcasts with batman-adv

[David Beberman]

Hi,
I'm using batman-adv in two different ways.
The first is what it is meant for, mesh routing.  Apologies if that
is not the correct technical term.

The second way I'm using it is to take advantage of broadcasting
as a simply floodfill algorithm.  All of my nodes transmit to all other nodes
on a periodic basis.  This is an IPv6 local multicast.  I believe this
translates to 802.11 MAC FF:FF:FF:FF:FF:FF broadcast address, and
everything works.

What I noticed with a network sniffer is that all of the broadcasts were sent
with 1 Mbps data rate.  For some of my systems, I was able to force
the rate to a fixed value:  iwconfig wlan0 rate 5.5M
for example.

For other systems, the command is accepted but the broadcast rate
stays at 1Mbps.
The systems that show this are laptops running Intel iwlagn drivers,
as well as external USB Linksys (USB600N) devices with Ralink drivers.
I tried both the ubuntu kernel 2.6.32-29-generic and also upgraded
it to 2.6.39 downloaded directly from kernel.org.
I thought that perhaps the ad-hoc fixed rate behavior might not be
implemented in the mac80211/cfg80211 in the earlier kernel versions.

I'm running the batman-adv 2011.1.0 release.

What I would really want is some way to flood packets to all of my
nodes from all of my nodes on a periodic basis.  That is, this is a
full mesh connection situation.
I would somehow like to still take advantage of higher data rates when
nodes are closer to each other.  Unfortunately, broadcasts do not have
full CSMA/CA, only CSMA, so no feedback to do data rate management (I
think).

Does anyone have experience with using the wireless extensions
(iwconfig, wpa_supplicant, wpa_cli, etc.), or the newer "iw" commands
to get broadcasts to occur at different data rates in ad-hoc mode?

Also:
I have tried using unicast packets one for each connected pair and let
the batman-adv next-hop routing forward the packets.  This does work
in a reasonably stable system.  The problem is that my nodes have a
fairly short data transmit period on the order of 1 second.
The nodes are moving around relative to each other also on the order
of a few seconds.
The routing resolution based on link quality works on the order of 30+
seconds.  Thus there can be loss of traffic for a significant period
relative to 1 second periods.
I did up the OGM rate, 100 msec and even 10 msec just to experiment.
This actually seemed to reduce the next-hop decisions, based on the
batctl ping results.
From what I can tell reading the algorithms written in the
documentation, all next hop decisions are based on link quality. Link
quality using
roundtrip metrics of broadcast packets.
Broadcast packets are transmitted at 1Mbps in my systems, thus the
link quality for 2 nodes at a distance that uses 1 Mbps data rate is
the same as the link quality for 2 nodes that could use much higher
data rates.
Since my objective is to deliver the same packet from each source node
to all other nodes, using next-hop routing, I end up with my data
rates dropping to the minimum to reach the maximum operational
distance nodes, even if there are a bunch of nodes in between.

When I broadcast, the data rate stays constant and as long as a node
can hear at least one other node, it gets all the periodic data from
all other nodes.

If this makes sense to someone, or I'm missing something obvious,
please feel free to clue me in.

My next step is to getting into the transmit control flow in the WLAN
device drivers for each piece of
hardware and see if I can hard code the transmit data rate for
broadcast packets.  Usually there is
a control header for each transmit frame sent to the
hardware/firmware.  Finding it, and understanding it
without documentation is a challenge I've been hoping to avoid.

Any help would be appreciated.
The only help I can offer in return is that I figured out how to
change the operating channel on the Broadcom bcm4329 driver for the
HTC Desire in
ad-hoc mode. There are a couple of minor errors in the wireless
extension handling code.
Someone might find that useful.

Regards,
David Beberman

Re: [B.A.T.M.A.N.] tangentially driver related question on broadcasts with batman-adv

[Daniele Furlan]

2011/6/16 David Beberman <dbeberman@gmail.com>:
> Hi,
> I'm using batman-adv in two different ways.
> The first is what it is meant for, mesh routing.  Apologies if that
> is not the correct technical term.
>
> The second way I'm using it is to take advantage of broadcasting
> as a simply floodfill algorithm.  All of my nodes transmit to all other nodes
> on a periodic basis.  This is an IPv6 local multicast.  I believe this
> translates to 802.11 MAC FF:FF:FF:FF:FF:FF broadcast address, and
> everything works.
>
> What I noticed with a network sniffer is that all of the broadcasts were sent
> with 1 Mbps data rate.  For some of my systems, I was able to force
> the rate to a fixed value:  iwconfig wlan0 rate 5.5M
> for example.
>
The standard fix the broadcast rate to 1 Mbs for 802.11b
and 6 Mbs for 802.11g. Since most of the wireless lan work
in mixed mode, the broadcast ends up to be sent at 1Mbs.

> For other systems, the command is accepted but the broadcast rate
> stays at 1Mbps.
> The systems that show this are laptops running Intel iwlagn drivers,
> as well as external USB Linksys (USB600N) devices with Ralink drivers.
> I tried both the ubuntu kernel 2.6.32-29-generic and also upgraded
> it to 2.6.39 downloaded directly from kernel.org.
> I thought that perhaps the ad-hoc fixed rate behavior might not be
> implemented in the mac80211/cfg80211 in the earlier kernel versions.
>
You can use the command:
iw wlan0 set bitrates legacy-2.4 12 18 24
for example to let wlan0 use onbly 12 18 and 24 Mbs, in any
case anyhow this applies only to unicast communication.

> I'm running the batman-adv 2011.1.0 release.
>
> What I would really want is some way to flood packets to all of my
> nodes from all of my nodes on a periodic basis.  That is, this is a
> full mesh connection situation.
> I would somehow like to still take advantage of higher data rates when
> nodes are closer to each other.  Unfortunately, broadcasts do not have
> full CSMA/CA, only CSMA, so no feedback to do data rate management (I
> think).
>
> Does anyone have experience with using the wireless extensions
> (iwconfig, wpa_supplicant, wpa_cli, etc.), or the newer "iw" commands
> to get broadcasts to occur at different data rates in ad-hoc mode?
>
I think it is not possible, maybe you can try to hardcode it in the
driver code but I don't know if it could work.

> Also:
> I have tried using unicast packets one for each connected pair and let
> the batman-adv next-hop routing forward the packets.  This does work
> in a reasonably stable system.  The problem is that my nodes have a
> fairly short data transmit period on the order of 1 second.
> The nodes are moving around relative to each other also on the order
> of a few seconds.
> The routing resolution based on link quality works on the order of 30+
> seconds.  Thus there can be loss of traffic for a significant period
> relative to 1 second periods.
> I did up the OGM rate, 100 msec and even 10 msec just to experiment.
> This actually seemed to reduce the next-hop decisions, based on the
> batctl ping results.
> From what I can tell reading the algorithms written in the
> documentation, all next hop decisions are based on link quality. Link
> quality using
> roundtrip metrics of broadcast packets.

The algoritm is not based on RTT but on the number of routing
management frame correctly received through the path.

> Broadcast packets are transmitted at 1Mbps in my systems, thus the
> link quality for 2 nodes at a distance that uses 1 Mbps data rate is
> the same as the link quality for 2 nodes that could use much higher
> data rates.

This is partially true, it depends on the unicast data rate of the alternative
multi-hop path. But if the difference is great (1Mbs vs 54Mbs) you are
right.

> Since my objective is to deliver the same packet from each source node
> to all other nodes, using next-hop routing, I end up with my data
> rates dropping to the minimum to reach the maximum operational
> distance nodes, even if there are a bunch of nodes in between.
>
> When I broadcast, the data rate stays constant and as long as a node
> can hear at least one other node, it gets all the periodic data from
> all other nodes.
>
The rate of broadcast is constant, it does not depend from BATMAN.

> If this makes sense to someone, or I'm missing something obvious,
> please feel free to clue me in.
>
> My next step is to getting into the transmit control flow in the WLAN
> device drivers for each piece of
> hardware and see if I can hard code the transmit data rate for
> broadcast packets.  Usually there is
> a control header for each transmit frame sent to the
> hardware/firmware.  Finding it, and understanding it
> without documentation is a challenge I've been hoping to avoid.
>
> Any help would be appreciated.
> The only help I can offer in return is that I figured out how to
> change the operating channel on the Broadcom bcm4329 driver for the
> HTC Desire in
> ad-hoc mode. There are a couple of minor errors in the wireless
> extension handling code.
> Someone might find that useful.
>
> Regards,
> David Beberman
>
Someone other surely it is more qualified on this field.

Regards,

-- 
Daniele Furlan

Re: [B.A.T.M.A.N.] tangentially driver related question on broadcasts with batman-adv

[Daniel Seither]

Hi!

Am 16.06.2011 00:04, schrieb David Beberman:
> The second way I'm using it is to take advantage of broadcasting
> as a simply floodfill algorithm.  All of my nodes transmit to all other nodes
> on a periodic basis.  This is an IPv6 local multicast.  I believe this
> translates to 802.11 MAC FF:FF:FF:FF:FF:FF broadcast address, and
> everything works.
> 
> What I noticed with a network sniffer is that all of the broadcasts were sent
> with 1 Mbps data rate.

This is the behavior specified in IEEE 802.11 [1], §9.6 (Multirate support):
"All frames with multicast and broadcast in the Address 1 field that
have a UP of zero shall be transmitted at one of the rates included in
the BSSBasicRateSet parameter, regardless of their type or subtype."

The basic rate set seems to often consists only of small rates such as 1
or 2 MBit/s in 11g networks. However, I couldn't find out how to get the
basic rates supported by my wifi card or configured in the wireless
stack. Does anyone know how to do this?

- Daniel

[1] http://standards.ieee.org/getieee802/download/802.11-2007.pdf

Re: [B.A.T.M.A.N.] tangentially driver related question on broadcasts with batman-adv

[Marek Lindner]

On Thursday, June 16, 2011 12:04:41 AM David Beberman wrote:
> I did up the OGM rate, 100 msec and even 10 msec just to experiment.
> This actually seemed to reduce the next-hop decisions, based on the
> batctl ping results.

Did you disable aggregation while using these short intervals ?


> My next step is to getting into the transmit control flow in the WLAN
> device drivers for each piece of
> hardware and see if I can hard code the transmit data rate for
> broadcast packets.  Usually there is
> a control header for each transmit frame sent to the
> hardware/firmware.  Finding it, and understanding it
> without documentation is a challenge I've been hoping to avoid.

The linux wireless list (http://linuxwireless.org/en/developers/MailingLists) 
might be a more suitable place to discuss this kind of topic. 

Regards,
Marek

Re: [B.A.T.M.A.N.] tangentially driver related question on broadcasts with batman-adv

[David Beberman]

Hi Dan,

So far, with Linux, I have only used the iwconfig and iw tools.
For one of the drivers, using iwconfig, I was able to set the data rate,
which was used for broadcasts.  I could set the data rate to both
802.11b and 802.11g rates.  However, the hardware would send
a CTS frame and apparently an 802.11g frame with what appears
to be corruption giving a CRC error for all 802.11g rates.  This only
occurred when a node detects the presence of other nodes operating
at 802.11b/g, which corresponds to 802.11n coexistence behavior.
Not what I was expecting.
For other drivers, I was unable to get anything but 1 Mbps broadcasts.
As I think this is useful for floodfill types of data traffic
requirements, as opposed
to unicast or multicast, my next step is to take a look at the Linux
MAC80211 layer.  This is very much a "corner case" use for mesh
networks, but I happen to need it.  Still hoping for a simple solution
to this.

David

On Thu, Jun 16, 2011 at 5:20 AM, Daniel Seither <post@tiwoc.de> wrote:
> Hi!
>
> Am 16.06.2011 00:04, schrieb David Beberman:
>> The second way I'm using it is to take advantage of broadcasting
>> as a simply floodfill algorithm.  All of my nodes transmit to all other nodes
>> on a periodic basis.  This is an IPv6 local multicast.  I believe this
>> translates to 802.11 MAC FF:FF:FF:FF:FF:FF broadcast address, and
>> everything works.
>>
>> What I noticed with a network sniffer is that all of the broadcasts were sent
>> with 1 Mbps data rate.
>
> This is the behavior specified in IEEE 802.11 [1], §9.6 (Multirate support):
> "All frames with multicast and broadcast in the Address 1 field that
> have a UP of zero shall be transmitted at one of the rates included in
> the BSSBasicRateSet parameter, regardless of their type or subtype."
>
> The basic rate set seems to often consists only of small rates such as 1
> or 2 MBit/s in 11g networks. However, I couldn't find out how to get the
> basic rates supported by my wifi card or configured in the wireless
> stack. Does anyone know how to do this?
>
> - Daniel
>
> [1] http://standards.ieee.org/getieee802/download/802.11-2007.pdf
>