B.A.T.M.A.N September 2022

b.a.t.m.a.n@lists.open-mesh.org

7 participants
8 discussions

by Charles Chien

Hello developers, We’re currently trying to install batman-adv on an ARM platform but we ran into some issues and we would appreciate your help to answer our questions below: Is the batman-adv module compatible with an ARM processor (Raspberry PI 4)? I’m trying to install batman-adv onto an ARM Raspberry PI 4 with a Debian based Linux distribution (Pop OS). However, when I run “modprobe batman-adv”, it returns a FATAL error complaining that the module is not found in the “/lib/modules” directory. Where can I find/download the “.ko” for batman-adv for the ARM platform? And if I need to recompile the .ko file for ARM, is there an online repository where I can find the original source code for the batman-adv driver? -- Regards, Charles

7 months

[PATCH 0/4] pull request for net-next: batman-adv 2022-09-16

by Simon Wunderlich

Hi Jakub, hi David, here is a little cleanup pull request of batman-adv to go into net-next. Please pull or let me know of any problem! Thank you, Simon The following changes since commit 568035b01cfb107af8d2e4bd2fb9aea22cf5b868: Linux 6.0-rc1 (2022-08-14 15:50:18 -0700) are available in the Git repository at: git://git.open-mesh.org/linux-merge.git tags/batadv-next-pullrequest-20220916 for you to fetch changes up to 76af7483b3c7c42571aae767b553ef7d436305e9: batman-adv: remove unused struct definitions (2022-09-15 08:16:05 +0200) ---------------------------------------------------------------- This cleanup patchset includes the following patches: - bump version strings, by Simon Wunderlich - drop unused headers in trace.h, by Sven Eckelmann - drop initialization of flexible ethtool_link_ksettings, by Sven Eckelmann - remove unused struct definitions, by Marek Lindner ---------------------------------------------------------------- Marek Lindner (1): batman-adv: remove unused struct definitions Simon Wunderlich (1): batman-adv: Start new development cycle Sven Eckelmann (2): batman-adv: Drop unused headers in trace.h batman-adv: Drop initialization of flexible ethtool_link_ksettings net/batman-adv/bat_v_elp.c | 1 - net/batman-adv/main.h | 2 +- net/batman-adv/trace.h | 2 -- net/batman-adv/types.h | 39 --------------------------------------- 4 files changed, 1 insertion(+), 43 deletions(-)

8 months, 2 weeks

[PATCH 0/1] pull request for net: batman-adv 2022-09-16

by Simon Wunderlich

Hi David, hi Jakub, here is a bugfix for batman-adv which we would like to have integrated into net. Please pull or let me know of any problem! Thank you, Simon The following changes since commit 568035b01cfb107af8d2e4bd2fb9aea22cf5b868: Linux 6.0-rc1 (2022-08-14 15:50:18 -0700) are available in the Git repository at: git://git.open-mesh.org/linux-merge.git tags/batadv-net-pullrequest-20220916 for you to fetch changes up to b1cb8a71f1eaec4eb77051590f7f561f25b15e32: batman-adv: Fix hang up with small MTU hard-interface (2022-08-20 14:17:45 +0200) ---------------------------------------------------------------- Here is a batman-adv bugfix: - Fix hang up with small MTU hard-interface, by Shigeru Yoshida ---------------------------------------------------------------- Shigeru Yoshida (1): batman-adv: Fix hang up with small MTU hard-interface net/batman-adv/hard-interface.c | 4 ++++ 1 file changed, 4 insertions(+)

8 months, 2 weeks

[PATCH 1/2] alfred: remove unnecessary backslash

by Marek Lindner

Signed-off-by: Marek Lindner <mareklindner(a)neomailbox.ch> --- alfred.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/alfred.h b/alfred.h index 97f0093..a4a3d37 100644 --- a/alfred.h +++ b/alfred.h @@ -210,7 +210,7 @@ int unix_sock_close(struct globals *globals); int unix_sock_req_data_finish(struct globals *globals, struct transaction_head *head); void unix_sock_events_close_all(struct globals *globals); -void unix_sock_event_notify(struct globals *globals, uint8_t type,\ +void unix_sock_event_notify(struct globals *globals, uint8_t type, const uint8_t source[ETH_ALEN]); /* vis.c */ int vis_update_data(struct globals *globals); -- 2.37.2

8 months, 2 weeks

[PATCH] batman-adv: remove unused struct definitions

by Marek Lindner

Signed-off-by: Marek Lindner <mareklindner(a)neomailbox.ch> --- net/batman-adv/types.h | 39 --------------------------------------- 1 file changed, 39 deletions(-) diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h index 2be5d4a7..758cd797 100644 --- a/net/batman-adv/types.h +++ b/net/batman-adv/types.h @@ -1740,45 +1740,6 @@ struct batadv_priv { #endif }; -/** - * struct batadv_socket_client - layer2 icmp socket client data - */ -struct batadv_socket_client { - /** - * @queue_list: packet queue for packets destined for this socket client - */ - struct list_head queue_list; - - /** @queue_len: number of packets in the packet queue (queue_list) */ - unsigned int queue_len; - - /** @index: socket client's index in the batadv_socket_client_hash */ - unsigned char index; - - /** @lock: lock protecting queue_list, queue_len & index */ - spinlock_t lock; - - /** @queue_wait: socket client's wait queue */ - wait_queue_head_t queue_wait; - - /** @bat_priv: pointer to soft_iface this client belongs to */ - struct batadv_priv *bat_priv; -}; - -/** - * struct batadv_socket_packet - layer2 icmp packet for socket client - */ -struct batadv_socket_packet { - /** @list: list node for &batadv_socket_client.queue_list */ - struct list_head list; - - /** @icmp_len: size of the layer2 icmp packet */ - size_t icmp_len; - - /** @icmp_packet: layer2 icmp packet */ - u8 icmp_packet[BATADV_ICMP_MAX_PACKET_SIZE]; -}; - #ifdef CONFIG_BATMAN_ADV_BLA /** -- 2.37.2

8 months, 2 weeks

Re: [pim] draft-ietf-6lo-multicast-registration-08 replacing MLD

by Linus Lüssing

On Mon, Aug 08, 2022 at 10:21:05AM -0700, Stig Venaas wrote: > Hi 6lo and draft authors > > I have some concerns about this draft replacing MLD for group registration. > > Having 2 different protocols for the same thing can be problematic. > Hosts or routers may need to support both protocols. Is it clear which > one should be used in different environments? Is there a chance that > both may be used at the same time in a network? In particular, is > there a chance that a router may need to simultaneously support both > protocols on an L3 interface? In that case it must be considered how > the two protocols interoperate. > > Also, we have been pushing the use of SSM in the IETF for a very long > time, but this draft only supports ASM since only a group address is > provided. > > It would be good to have some more info on the need to replace MLD. I > understand there are concerns about packet loss, limited resources > etc. > > Regards, > Stig Hi, Is there some good overview and/or presentation of this alternative concept available somewhere? The introduction of draft-ietf-6lo-multicast-registration-08 as is is a bit difficult to start with as its introduction references a lot of other, fairly new RFCs (which generally is fine for me, avoids duplication; just not that easy to start with as a first read :D ). I'm very interested in this topic as we too are experiencing several drawbacks with the current MLD approach in our layer 2 mesh networks based on B.A.T.M.A.N. Advanced [0]. Typically people use 802.11 based WiFi routers with fixed line power with batman-adv. At least for larger installations. While if I understand correctly this new RFC is focusing on off-grid LoRaWAN based mesh nodes, right? Might be interesting to check if for these two different radio technologies we face similar issues, but also if we might have differing requirements. To avoid that we would need a third protocol later... --- batman-adv currently makes use of MLD snooping [1]. The four main issues we are/were facing: 1) MLD overhead is high with default intervals for the mesh network sizes we are working with (> 1000 mesh nodes and > 2000 client devices) 2) MLD is too slow and unreliable with default intervals for a lossy, dynamic mesh network. -> we can't fix both 1) + 2) by tuning MLD querier parameters 3) MLD querier selection is not robust enough in a dynamic mesh network, lowest MAC addrdess for the querier is a bad criteria, we don't want a barely connected node with high packet loss at the edge of the wifi mesh network to take over such an essential roll; actually we don't want any mesh node to take over a central role, batman-adv was designed to work as a fully decentral mesh of equal nodes without any reliabilities 4) IGMPv2/MLDv1 Report suppression [2]; RFC4541 ("Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" is not feasible solution/workaround for us always forwarding all multicast traffic to the querier would lead to congestion On the other hand power consumption of MLD as noted in the draft is not a big issue for us right now, though it might be related to 1). The workaround for our four issues we came up with is to split the layer 2 broadcast domain per mesh node with layer 2 filtering of MLD [3]. So regarding MLD it is now behaving more like a layer 3 mesh network, where each WiFi router / mesh node is its own querier for its local Wifi clients. And between the mesh nodes we exchange listener state through the batman-adv protocol, sort of like a one-way proxy, as its more efficient for us right now. The downside is that it is one-way right now, so each batman-adv node will have the listener state which is enough for us right now to ensure that within the layer 2 broadcast domain multicast works fine. However a remote batman-adv node won't translate it back to MLD, so layer 3 multicast routers won't be informed. Also its ASM only at the moment. But I would celebrate it if we could just get rid of these workarounds by simply having a more robust, more decentral but also less costly MLDv3 (and especially no more MLDv1). --- I'll also be at the Wireless Battlemesh [4] in Rome, Italy, with several other batman-adv developers next week and we will be talking about mesh networks the whole week. Feel free to stop by if you can, it's an awesome event :-). Or would anybody be interested to exchange our experiences with MLD in mesh networks remotely during that week? I could put an official slot on the Battlemesh schedule, if people would be interested. Regards, Linus [0]: https://www.open-mesh.org/projects/batman-adv/wiki [1]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations [2]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-… [3]: https://gluon.readthedocs.io/en/latest/package/gluon-mesh-batman-adv.html#m… [4]: https://www.battlemesh.org/

8 months, 2 weeks

[PATCH] batman-adv: Fix hang up with small MTU hard-interface

by Shigeru Yoshida

The system hangs up when batman-adv soft-interface is created on hard-interface with small MTU. For example, the following commands create batman-adv soft-interface on dummy interface with zero MTU: # ip link add name dummy0 type dummy # ip link set mtu 0 dev dummy0 # ip link set up dev dummy0 # ip link add name bat0 type batadv # ip link set dev dummy0 master bat0 These commands cause the system hang up with the following messages: [ 90.578925][ T6689] batman_adv: bat0: Adding interface: dummy0 [ 90.580884][ T6689] batman_adv: bat0: The MTU of interface dummy0 is too small (0) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1560 would solve the problem. [ 90.586264][ T6689] batman_adv: bat0: Interface activated: dummy0 [ 90.590061][ T6689] batman_adv: bat0: Forced to purge local tt entries to fit new maximum fragment MTU (-320) [ 90.595517][ T6689] batman_adv: bat0: Forced to purge local tt entries to fit new maximum fragment MTU (-320) [ 90.598499][ T6689] batman_adv: bat0: Forced to purge local tt entries to fit new maximum fragment MTU (-320) This patch fixes this issue by returning error when enabling hard-interface with small MTU size. Signed-off-by: Shigeru Yoshida <syoshida(a)redhat.com> --- net/batman-adv/hard-interface.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c index b8f8da7ee3de..dce5557800e9 100644 --- a/net/batman-adv/hard-interface.c +++ b/net/batman-adv/hard-interface.c @@ -700,6 +700,9 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface, int max_header_len = batadv_max_header_len(); int ret; + if (hard_iface->net_dev->mtu < ETH_MIN_MTU + max_header_len) + return -EINVAL; + if (hard_iface->if_status != BATADV_IF_NOT_IN_USE) goto out; -- 2.37.2

8 months, 3 weeks

zero hop penalty interface?

by dan

Hi all. I'm struggling to find an answer to this specific question about path selection. I'm looking at building a prototype mesh out of the banana pi BPI-R3. That's a dual band wifi 6/6e router that runs open-wrt. 1x 2.4Ghz and 1x5-6Ghz. I would build this as a quasi-dual radio mesh. ie, I want to favor the 5-6Ghz radio and add a large hop penalty to the 2.4Ghz so that it's only used for backup. The 2.4Ghz is a fraction the speed of the 5-6Ghz. What I'm considering is that as I saturate the 'single radio mesh' that the 5-6Ghz radios is essentially making since 2.4Ghz is purposely high-cost, I may want to add a second unit starting from the main uplink out as a secondary mesh, then linking both units together via 2.5-5GbE ports on the device. The question is, can I make the hop penalty zero so the mesh treats this pair of routers basically as one? for instance data comes into node10a's 5Ghz radio, I'd like that to try to go across the 'zero cost' ethernet and exit via node10b's 5Ghz radio to make this effectively a dual radio mesh. Ultimately the same would be true of the 2.4Ghz but again, that's ideally for backup meshing as it should look like an expensive hop.

8 months, 3 weeks

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N September 2022