commit 34b3c3850e7d ("batman-adv: Distributed ARP Table - create DHT helper
functions") introduced a return check of batadv_compare_eth which uses a
boolean return value since commit 16af73458aca ("batman-adv: main,
batadv_compare_eth return bool"). A relational (<, >, <= or >=) operator
is not the right one for such a check.
Reported-by: David Binderman <dcb314(a)hotmail.com>
Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
---
Cc: David Binderman <dcb314(a)hotmail.com>
Cc: Antonio Quartulli <a(a)unstable.cc>
Cc: Markus Pargmann <mpa(a)pengutronix.de>
---
net/batman-adv/distributed-arp-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c
index 760c0de7..a39a07d6 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -493,7 +493,7 @@ static bool batadv_is_orig_node_eligible(struct batadv_dat_candidate *res,
* the one with the lowest address
*/
if (tmp_max == max && max_orig_node &&
- batadv_compare_eth(candidate->orig, max_orig_node->orig) > 0)
+ batadv_compare_eth(candidate->orig, max_orig_node->orig))
goto out;
ret = true;
--
2.11.0
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.
On Mittwoch, 25. Januar 2017 03:18:10 CET jens wrote:
> On 24.01.2017 14:39, Sven Eckelmann wrote:
> > There is no artificial limit added by batman-adv. But transmitting a lot of
> > broadcasts over 255 virtual links sharing the same physical link
> > might get interesting (independent of batman-adv).
>
> this made me curious , and i modified your script a bit - turns out
> after the 127. IF you add to batman-adv you get an Error -
> all 510 gretap links was succesfully build ...
> # ifconfig |grep gre| wc -l
> 515
> # batctl if|sort|wc -l
> 127
> the error is mainly
> *Error - can't write to file
> '/sys/class/net/gre128/batman_adv/mesh_iface': Cannot allocate memory
[...]
> [113990.684947] [<ffffffff8107c16e>] ? __warn+0xbe/0xe0 [113990.684955]
> [<ffffffffc017a804>] ? batadv_orig_hash_add_if+0x94/0x140 [batman_adv]
> [113990.684961] [<ffffffff811a7b10>] ? kmalloc_slab+0x90/0xa0
> [113990.684966] [<ffffffff811e08c5>] ? __kmalloc+0x25/0x580
> [113990.684971] [<ffffffff815ef9d7>] ? _raw_spin_lock_irqsave+0x17/0x39
> [113990.684977] [<ffffffff81432c11>] ? _crng_backtrack_protect+0x31/0x70
> [113990.684981] [<ffffffff811e0ebc>] ? kmem_cache_alloc_trace+0x9c/0x540
> [113990.684986] [<ffffffff814340b7>] ? get_random_bytes+0xe7/0x1c0
> [113990.684991] [<ffffffffc017a804>] ?
[...]
I would guess that your system mostly fails becauseit cannot handle the
allocation of the "large" arrays which store:
* @bcast_own: set of bitfields (one per hard-interface) where each one counts
* the number of our OGMs this orig_node rebroadcasted "back" to us (relative
* to last_real_seqno). Every bitfield is BATADV_TQ_LOCAL_WINDOW_SIZE bits long.
* @bcast_own_sum: sum of bcast_own
Kind regards,
Sven