On Thursday 13 November 2014 10:30:14 Jay Brussels wrote:

I have seen some patches on the listserver that states certain mesh traffic can cause a crash. This is my primary concern.

Which patches are you referring to? For example my patches for batctl [1] are related to a recent patch for batctl tcpdump [2]. So it is neither strictly batman-adv nor for anything in OpenWrt (the affected patch was not yet part of any batctl release).

But there are things which might affect you depending on what you are doing. For example, there is an RCU related fix [3] which is quite important when you are using a Linux kernel < 3.9. But OpenWrt should not use such an old kernel when compiling a recent OpenWrt version. But maybe you still do and we don't know about it. So it is hard to guess what to say to your question.

It is also hard to guess whats your batman-adv configuration. For example I would try to disable network-coding+dat and enable bridge loop avoidance - unless my specific setup requires something else. I know that this is not the default behavior but in my subjective experience the default causes more trouble. Just for reference, this is the default when batman-adv was compiled with all features:

* bridge_loop_avoidance: disabled (I prefer "enabled" because it is better to be save than sorry after you've killed the network with an broadcast packet storm. But don't expect it to be a magical cure for every insane network setup you could imagine) * network_coding: enabled (I prefer disabled unless proven to be helpful in your specific network setup) * distributed_arp_table: enabled (I prefer disabled due to some problems I had with it)

This might be something which could be seen by some people as "not stable" and others might disagree. Or they might completely disagree with my (not science-based) opinion about the better default settings.

Also there is the problem that we don't know which feed you are using. For example there is a patch [4] in the openwrt-routing feed which fixes the problem that the batman-adv config file is cleared after and upgrade. This commit (Hint!!!!) was never merged into the openwrt-feed-batman-adv.git. And this feed also seems to point to an quite old batman-adv/batctl version by default. This can be seen as "instability" depending on your personal view and what you are using to get batman-adv in your firmware. It can affect you but most likely doesn't affect you at all.

And to your question "Is the current OpenWrt release stable enough for deployment". Lets first make it clear that I will now talk about software in general and not batman-adv. Every software has some kind of problems. Many of them are unknown and will hit you from behind when you expect it the least. Therefore, making a general statement without knowing anything about your "deployment" cannot be accurate nor valid. The buggiest software may run fine in a specific environment and the most polished software may cause problems when somebody just (accidentally) finds its Achilles heel. And this can even happen when knowing your "deployment".

But lets just summarize:

* can it be deployed?: yes, people already do it * is it stable enough for deployment?: cannot be answered (see below) * was it deployed and then worked stable?: yes * are there known problems not fixed in openwrt?: yes * are there known problems that affect you?: unknown * is it very likely that these known and fixed problems affect you when assuming everything done "the right way"?: not really (please correct me if there was some change which I missed in maint or ml) * is it possible that there are known and fixed problems which affect you assuming not everything is done "the right way"?: yes * will it work out of the box in every possible environment?: no * will it work in many setups?: yes * will it work in some other setups after changing the config?: yes * would these questions answered the same for many other sw projects?: YES

Kind regards, Sven

[1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-November/012534.html [2] http://git.open-mesh.org/batctl.git/commit/4c39fb823b86036df40187f8bd342fe53... [3] http://git.open-mesh.org/batman-adv.git/commit/1e4a96a4cfdfdf57fecacf1c8fa49... [4] https://github.com/openwrt-routing/packages/commit/bbcc138fc0bbef5094c3928d8...

On Sunday 16 November 2014 07:28:26 Linus Lüssing wrote:

On Sat, Nov 15, 2014 at 07:58:23PM +0100, Sven Eckelmann wrote:

...

• can it be deployed?: yes, people already do it

Is anyone using the latest batman-adv release with bridges?

Maybe I didn't make it clear enough that the outstanding multicast issues and patches are severe (as in makes common setups unusable).

Hm, I am now not sure if we switched topics again. Maybe you can enlighten us. Jay was not perfectly clear in his first mail what what he actually wanted to know. His second mail was refining his question to something like "tell me if I can deploy batman-adv from OpenWrt because I've read the term 'crash' somewhere". I am sure that your critism of OpenWrt is valid and a good point to make. But maybe we can make your answer a little bit more understandable (at least for me):

You are saying something about "outstanding multicast issues and patches" without defining what it means in this mails.

Are there known missing patches/issues for batman-adv which would break "common setups"? If yes, why is multicast_mode enabled by default in batman-adv?

Are there "only" missing patches/issues in the bridge code (the ones you've linked to in the other mail [1]) of OpenWrt which breaks batman-adv with multicast_mode? If yes, why is multicast_mode enabled by default in batman-adv?

Are there "only" missing patches/issues in the bridge code (the ones you've linked to in the other mail [1]) of OpenWrt which breaks batman-adv even without multicast_mode?

Are these missing patches/issues only about bridges + multicast and not about batman-adv?

Kind regards, Sven

[1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-November/012554.html

On Sun, Nov 16, 2014 at 10:14:43AM +0100, Sven Eckelmann wrote:

Yes, there are at least two known problems in batman-adv which are now fixed in maint and can be cherry picked by you. Otherwise these problems would enable multicast optimization when some nodes have bridges (which they shouldn't). This is a bug a not missing feature. So it is still valid that multicast_mode is enabled by default.

I would guess that you can either disable multicast_mode or apply the patches.

Correct.

...

Are there "only" missing patches/issues in the bridge code (the ones you've linked to in the other mail [1]) of OpenWrt which breaks batman-adv with multicast_mode? If yes, why is multicast_mode enabled by default in batman-adv?

I cannot really answer this and will leave it to Linus.

Turning off multicast_mode is only intended for debugging purposes at the moment. batman-adv should never break anything by having multicast_mode enabled (which unfortunately, currently is not the case for a release / OpenWRT but should be again after the two multicast counter fixes which just hit the maint-branch trickled through).

...

Are there "only" missing patches/issues in the bridge code (the ones you've linked to in the other mail [1]) of OpenWrt which breaks batman-adv even without multicast_mode?

I cannot really answer this and will leave it to Linus.

Nope, the bridge patches in OpenWRT don't break the concept of the multicast optimizations or multicast handling in general in batman-adv. The issues of the state of the bridge code in BB are unrelated to batman-adv and happen with any other enslaved network device, too.