All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.