[B.A.T.M.A.N.] Debian Testing kernel module, BATMAN_V not supported

[B.A.T.M.A.N.] Debian Testing kernel module, BATMAN_V not supported

[Fox, Fred]

When I try to set the routing algorithm to use BATMAN_V it returns the error:

[ 2327:090973] batman_adv: Routing algorithm 'BATMAN_V' not supported

Running batctl -v shows:

batctl Debian 2017.4-1 [batman_adv: 2017.3]

The kernel version from uname -a is:

Linux [host] 4.14.0-3-686 #1 SMP Debian 4.14.13-1 (2018-01-14) i686 GNU/Linux

I am guessing that the option CONFIG_BATMAN_ADV_BATMAN_V=n was used when the kernel module was compiled.

- Is disabling BATMAN_V the default for most distributions?
- Is it because of stability issues with current wireless drivers (as reading the mailing list implies)?
- Does anyone know what distributions enable BATMAN_V for their kernels?

In testing BATMAN_IV with my hardware, I noticed that as long as Node A could see Node C, it would communicate directly with it, even if the links between nodes A-B and nodes B-C had much higher throughput (tested with batctl tp). Would like to see if BATMAN_V would select the higher throughput path.




This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

Re: [B.A.T.M.A.N.] Debian Testing kernel module, BATMAN_V not supported

[Sven Eckelmann]

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

On Freitag, 16. Februar 2018 18:52:45 CET Fox, Fred wrote:
> 
> When I try to set the routing algorithm to use BATMAN_V it returns the error:
> 
> [ 2327:090973] batman_adv: Routing algorithm 'BATMAN_V' not supported
[...]
> I am guessing that the option CONFIG_BATMAN_ADV_BATMAN_V=n was used when the kernel module was compiled.
> 
> - Is disabling BATMAN_V the default for most distributions?

Most likely. This option is disabled by default in the kernel and I would 
guess that most distributions don't manually enable it. An exception is 
OpenWrt/LEDE.

If you want that Debian enables the option then you have to sent a wishlist 
bug report [1] against the Linux package in Debian [2]. 

> - Is it because of stability issues with current wireless drivers (as reading the mailing list implies)?

Hm? Where did somebody write something like that?

The code itself is just not often used (afaik) and rather experimental.

There is one big problem with wifi driver: only wifi drivers with 
minstrel(-ht) support provide a useful *expected throughput* via cfg80211 - 
something which B.A.T.M.A.N. V requires to work correctly. So you are 
currently limited to drivers like ath5k/ath9k or mt76.

[...]
> In testing BATMAN_IV with my hardware, I noticed that as long as Node A could see Node C, it would communicate directly with it, even if the links between nodes A-B and nodes B-C had much higher throughput (tested with batctl tp). Would like to see if BATMAN_V would select the higher throughput path.

B.A.T.M.A.N. IV is not using a throughput based metric - instead it uses loss. 
You can try to tweak your wifi settings a little bit to help B.A.T.M.A.N. IV 
to calculate better routes - the most important setting is the multicast rate. 
Make sure that have increased it (a lot) to avoid sending the OGMs at the 
lowest rate (which has most of the time also the highest success rate).

But when you really need a throughput based metric then you should either 
rebuild your kernel with B.A.T.M.A.N. IV enabled or just build the external 
kernel module [3] with:

    make CONFIG_BATMAN_ADV_BATMAN_V=y
    sudo make CONFIG_BATMAN_ADV_BATMAN_V=y install
    sudo rmmod batman-adv
    sudo modprobe batman-adv

Check that you have really loaded correct module.

> This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

Please try not to add such things to your mails when you send them to *public* 
mailing lists.

Kind regards,
	Sven

[1] https://www.debian.org/Bugs/Reporting
[2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes&src=linux
[3] https://www.open-mesh.org/projects/open-mesh/wiki/Download#batman-adv-in-the-Linux-tree

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [B.A.T.M.A.N.] Debian Testing kernel module, BATMAN_V not supported

[Sven Eckelmann]

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

On Freitag, 16. Februar 2018 18:52:45 CET Fox, Fred wrote:
> In testing BATMAN_IV with my hardware, I noticed that as long as Node A could see Node C, it would communicate directly with it, even if the links between nodes A-B and nodes B-C had much higher throughput (tested with batctl tp). Would like to see if BATMAN_V would select the higher throughput path.

Forgot something: You can also increase the hop penalty [1] on all nodes to 
let B.A.T.M.A.N. IV know that it should prefer shorter paths (as in hop
count - not as in packet loss).

But first try to increase the multicast rate on all nodes. Also make sure that 
the wifi driver/hw is actually using the multicast rate setting. For example 
by monitoring the rate with wireshark [2] or a similar tool on a wifi monitor 
interface [3].

Kind regards,
	Sven

[1] https://www.open-mesh.org/projects/batman-adv/wiki/Tweaking#hop-penalty
[2] https://www.wireshark.org/
[3] https://wireless.wiki.kernel.org/en/users/documentation/iw#adding_interfaces_with_iw

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]