sorry for forwarding - mail got filtered...
Betreff: Re: [Freifunk.luebeck-devel] [Freifunk-Bonn] [B.A.T.M.A.N.] On
compat version 15 in the Freifunk-KBU network
Datum: Sun, 19 May 2013 14:49:45 +0200
Von: Jan Lühr <ff(a)jluehr.de>
An: "Allgemeine Mailingliste zum Freifunk Köln, Bonn und Umgebung"
CC: The list for a Better Approach To Mobile Ad-hoc Networking
Am 19.05.2013 um 12:40 schrieb Simon Wunderlich:
On Sun, May 19, 2013 at 10:52:01AM +0200, Jan Lühr wrote:
> Hello folks,
> I'd like to give some thought's for the upcoming batman-adv release,
especially on compat version 15. This somewhat summarizes my discussion with T_X on the
wireless community weekend (WCW -- 2013-05-10 - 2013-05-12).
> It's not my intention to bash on batman-adv in general or to
start flame-wars (like: batman-adv vs. olsr or something else) - I'd like to provide
some statement on the impact of the upcoming protocol changes.
Thanks for your feedback. Yes, we are preparing a compat bump (actually for a long time
now) and it's good to discuss it. :)
Thanks for your detailed answer - I'll cut some parts for better readability.
> 1. The upcoming protocol change appears to be painful - we have no suitable
> 13 nodes in the next months - by that, we'll probably have
some compat 13 ones for at least 1/2 year. There is no way of telling newer nodes to use
compat version 13. Since some "supernodes" (dedicated servers) are part of the
batman-adv cloud, we need twice the servers as well.
> Upgrading to compat version 15 will require a huge amount of work: New
infrastructure (servers) must be deployed and nodes meshing with each other must be
upgraded in parallel.
Btw, it's interesting that you use compat version 13 - only one release had that
included, and we are
on compat 14 for quite some time ...
(...) - yes, I know. Theses nodes are quite old. I guess this somewhat illustrates the
> 2. Backwards-compatilibilty doesn't seem to be a design target.
Actually, that is one of the main design targets. We are aware that with our current
packet type design,
we cannot change even parts of the protocol without breaking compatibility. This has
bothered us for quite
some time and we have worked on solutions to prevent compat bumps as good as possible.
We have introduced
different means [2,3] to be able to add new features, change features, let sub-features
protocols (by using TVLVs) without breaking the rest and ensure compatibility on their
own , route even
yet unknown packets on their own , ... Actually the TVLV thing is pretty similar to
(e.g. IEEE 802.11) which use that to ensure backwards compatiblity for years. The goal
is to keep the
compat bump stable for at least a decade now, if not longer. No guarantees of course,
but this compat
bump is made to CREATE backwards compatiblity. :)
Note that the compat bump is not released yet but still only in our development branch.
Thanks for the details. I understand your reasons for changing the protocol - and I'm
perfectly fine with that. I know that manets are an area of active research.
Bit this won't be a problem at all, if upcoming batman-adv versions are capable if
"speaking" older compat versions. If done so, we (as in Freifunk-KBU) would be
able to simple "choose" the compat version for our network - and pick a newer
one if needed.
> Since batman-adv depends on the kernel (old batman-adv versions
won't build with recent kernels) using 14 will not be an option in a few months: If
some router hardware requires recent Kernel / OpenWRT releases version 14 might no longer
I think it would be possible to maintain older releases of batman-adv and add
compatibility code for
newer kernels. We are doing the same now to provide compatibility for older kernels .
be happy if someone (you?) would take over that job, I guess it would mostly mean to
test new kernels
and add a little bit of compat code like we do for the old kernels. You are welcome to
such "stable" versions. :)
Hmm... well, I'm not into kernel development, but I could maintain some CI services
for testing. I'll ask some our folks on our next community meeting.
> -> We're aware, that we cannot use version 14 in some months
> -> At the point, when 14 becomes unusable (introduced into OpenWRT Kernels /
release we need -- or Debian), we will almost certainly discontinue batman-adv and go one
with sth. else. (Due to kernel deps it's easier to run batman-adv / olsr in parallel
than two different version of batman-adv)
I don't see that by releasing batman-adv with the new compat version, suddenly your
- in Debian you usually keep the same kernel for YEARS, and in OpenWRT you can just keep
package at the desired version number. The only problem you might run into is that newer
not work, as stated above.
Actually, it has consequences: About 5-8 months ago (don't remember the details).
2011.2 didn't build on Attitude Adjustment (12.09) (OpenWRT issue? Kernel Issue? I
don't remember ...), while newer TP Link 1043nd models needed 12.09 (brick,
otherwise). At that time we're eager of deploying compat 14 releases - succeeding
about 3,5 months ago.
But in the aftermath of it, we noticed that we did not succeed in upgrading the whole
network - since upgrading some nodes is still impossible because of organizational issues.
Some people complained about the effort needed - for valid reasons, imho (although we
provided free vodka at our release party ;-) )
To be honest: I don't like to be stuck at this, again. With compat 15 on the horizon,
we're in the need of finding adequate strategies.
Do you have something in your mind?
> -> Maybe, some future version of batman-adv addresses
backwards-compatibility. Maybe, in 2018 we will have a look at batman-adv again -
noticing, that batman-adv remained stable (or migratable) over the last years and start
using it again. Maybe, batman-adv will fit our needs, then.
You are free to use whatever you want. I think I've made a clear point that this
compat bump is designed
to address the compat issues we had. What you roll out then is up to you (personally
I'd be interested
what you'll use instead) - but I guess you'll miss a lot of very nice features
of batman-adv. ;)
Yeah - I guess I'll miss some features - and there is no decision yet (not even
However - in retrospect - kernel-dependencies will be taken into account this time.