public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
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.] link alternation when radios are not on batman-adv router?
Date: Fri, 15 Jun 2012 11:55:25 +0200	[thread overview]
Message-ID: <20120615095525.GA32707@pandem0nium> (raw)
In-Reply-To: <4FDA40A5.1050008@inti.gob.ar>

[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]

On Thu, Jun 14, 2012 at 04:51:01PM -0300, gtolon@inti.gob.ar wrote:
> Hi,
> 
>     we are interested too in interface alternating, so we made some
> tests to understand how it works. As you can see on the attached
> sketch.png, we connected two pair of routers using their ethernet
> interfaces, E6 with E7, and E8 with E9. All of them have eth0, and
> an ad hoc interface, wlan0-1, managed by batman. E6 and E8 are in
> channel 11, whereas E7 and E9 are in channel 1. Besides we used two
> other routers, E12 and E13, both in channel 11, with their tx power
> set to just 0 dbm, to avoid a direct sight between them.
> 
>     Then we sent traffic from E12 to E13. We expected that packets
> travelled from E12 to E6, and that E6 forwarded them to his eth0 to
> use the interface alternating feature, making traffic flow to E7,
> then E9, E8 and finally E13. But instead, we observed that the
> actual path was E12--E6--E8--E13. The resulting routes for each
> router are attached in a text file, and also the graph from the
> batctl vd dot command.
> 
>     After this result, we read again the thread mentioned by Guido,
> specially in this part:
> 
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006344.html
> 
>    And if we understand correctly, the alternation feature works
> after the batman path has been selected. So in our case, E12 looks
> at his table to know where to send a packet to E13, and finds E6.
> Then E6 receives the packet and looks in his own table, finding that
> the best path to reach E13 is E8. At this point, the alternating
> should work, but there's only one interface directly connected to
> E8, so the packet goes there, and so on. We think that if E6 and E7
> were not two different routers running batman-adv but they were two
> radios of the same batman-adv router, and the same for E8 and E9,
> the alternating would work, because the unique router would choose
> the best path, and then would find two possible interfaces to the
> same next-hop, changing the interface.

This is entirely correct - batman-adv has only one link to choose from
(E6 -> E8) to reach its best nexthop E8, so there is no way to
"alternate" the interfaces.

>     We'd like to know if this interpretation is correct, and in that
> case, if it were possible to use interface alternating in a case
> like this, with two routers connected to work together. Thanks!

Mhm, with the current implementation - no, unfortunately not. We would
need some kind of multipath routing to select between routes, this is
much more complex.

An alternative might be to use the routers E7/E9 as secondary routers
without batman, but only forwarding traffic between Ethernet and
WiFi. Then the "primary" routers (E6 -> E8) would think they have
an alternative route via Ethernet (because they don't see the
intermediate hops E7/E9). This comes with some caveats however, e.g.
4-addr mode in Ad-Hoc, you need some very simple ethernet forwarder,
and most probably other things I forgot.

Cheers,
	Simon


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2012-06-15  9:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-30 13:35 [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router? dan
2012-03-30 16:33 ` Guido Iribarren
2012-03-30 17:18   ` dan
2012-03-31  3:48     ` Guido Iribarren
2012-03-31 15:45       ` Dan Denson
2012-03-31 18:11         ` Guido Iribarren
2012-03-31 21:03           ` dan
2012-04-01  1:31             ` Nicolás Echániz
2012-04-01  1:53               ` [B.A.T.M.A.N.] [OT] ruci / Was: " Nicolás Echániz
2012-04-01  2:10                 ` dan
2012-06-14 19:51       ` [B.A.T.M.A.N.] " gtolon
2012-06-15  9:55         ` Simon Wunderlich [this message]
2012-06-18 18:46           ` gtolon
2012-07-13 20:56             ` gtolon
2012-07-14 21:30               ` Guido Iribarren
2012-07-14 21:35                 ` Guido Iribarren
2012-07-17 13:36                   ` gtolon

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=20120615095525.GA32707@pandem0nium \
    --to=simon.wunderlich@s2003.tu-chemnitz.de \
    --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