public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Daniele Furlan <daniele.furlan@gmail.com>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] tangentially driver related question on broadcasts with batman-adv
Date: Thu, 16 Jun 2011 11:20:00 +0200	[thread overview]
Message-ID: <BANLkTinXYst_C920Cad4vcYHo8O2URdeoA@mail.gmail.com> (raw)
In-Reply-To: <BANLkTi=HCdWDjTQER8uOP48RW-XsZ6ehaQ@mail.gmail.com>

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

  reply	other threads:[~2011-06-16  9:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-15 22:04 [B.A.T.M.A.N.] tangentially driver related question on broadcasts with batman-adv David Beberman
2011-06-16  9:20 ` Daniele Furlan [this message]
2011-06-16  9:20 ` Daniel Seither
2011-06-16 13:21   ` David Beberman
2011-06-16 10:40 ` Marek Lindner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTinXYst_C920Cad4vcYHo8O2URdeoA@mail.gmail.com \
    --to=daniele.furlan@gmail.com \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox