[B.A.T.M.A.N.] [Battlemesh] Battlemesh v5 tests
kerneis at pps.jussieu.fr
Wed Mar 7 23:18:48 CET 2012
[CC: b.a.t.m.a.n at lists.open-mesh.org, see note 3 in particular]
On Wed, Mar 07, 2012 at 06:17:52PM +0100, Antonio Quartulli wrote:
> Technical details about what? Interface-alternating? It is there!
> Gabriel wrote the link.
No. Please re-read my email carefuly. The wiki contains a rough explanation of
the general principle (ie. “same interface = bad, different interface = good”).
Not the actual algorithm used by batman-adv (quoting from the wiki: “the
algorithm tries to avoid forwarding packets on the interface which just received
Note that the wiki has been updated since then, by Simon with a few more
details , and by Marek with benchmark results from WBMv3.
> Gabriel said he has not enough time to look into it. I'm sorry, but I don't think
> this is a good reason to blame batman-adv devs :P
I finally decided to settle this issue and spent my breakfast reading
batman-adv/routing.c  instead of my favorite newspaper. Here is what I
At all times, batman-adv maintains a list of "bonding candidates" for each
node (bonding_candidate_add, called from bat_iv_ogm.c:699).
Some node "neigh" is a bonding candidate for another node "orig" if and only
- neigh and orig have the same primary address, ie. are in fact the same
- the links to reach them have the same quality up to some additive
constant (BONDING_TQ_THRESHOLD = 50) ,
- orig does not already have another bonding candidate for the same
interface, because it could interfere – but what if the neigh has a better
link quality, isn’t it a pity to ignore it?
Then, assuming that "interface alternating" is enabled, the list of bonding
candidates is used on every route selection (find_ifalter_router, called
More precisely, once batman has chosen a next-hop router for a packet based
on its classical routing algorithm, it walks the list of the bonding
candidates associated to the primary interface for this router . It
selects the actual next-hop on the following criteria:
- it must not be on the same interface as the packet came in,
- its quality must be as high as possible (given the previous constraint).
This is the kind of explanation I would have loved to find on the wiki. By the
way, consider it public domain and feel free to copy/paste/correct it if you
It is still not clear to me exactly why this works, but I believe this is what
the code does, and is definitely easier to discuss than generic, unsubstantiated
 “Interface alternating is only performed if the two candidate links to the
next hop have a similar quality.”
 By the way, there is something I don’t understand: neigh_node->tq_avg will be
accepted event if it is far greater than router->tq_avg + BONDING_TQ_THRESHOLD.
Shouldn’t it be: abs(neigh_node->tq_avg - router->tq_avg) > BONDING_TQ_THRESHOLD?
 Why the primary and not the chosen router directly? Is the bonding
candidates list always associated to the primary interface?
More information about the B.A.T.M.A.N