B.A.T.M.A.N May 2019

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

9 participants
19 discussions

[B.A.T.M.A.N.] batman-adv and/or batmand porting effort to FreeBSD
by Mahdi Mokhtari 28 Dec '19

28 Dec '19

Hi, After some time of playing with the B.A.T.M.A.N protocol and net-interface on OpenWRT and Debian I was thinking to use it with the servers I use everyday (and maybe on routers/appliances I have nanoBSD on). So I started an effort... (As a background) I already ported some applications to FreeBSD [and I'm maintaining them] and also I did work already on the Linux emulation layer of FreeBSD (FreeBSD has a Linux syscall-emulation and Linux-KPI layers). So my approach (as naturally I didn't expect the build of batman-adv.ko to be successful as is), was based on the approach that we [at FreeBSD] did to port Linux's drm... <https://github.com/FreeBSDDesktop/kms-drm> I ended up in adding some header-files to FreeBSD Linux-KPI (like average.h, percpu.h, ...). Now I'm at a state that Netlink blocks me and I'm to determine next step :-) [Which I don't assume it being trivial with my current approach] So I'd like to ask: 1- Is it better approach to "rewrite" batman-adv.ko [at least Netlink-ish (let's call "Linuxism") parts] than what I'm doing now? 2- Any other efforts are being done out there? 3- is batmand deprecated [So I should mainly focus on batman-adv.ko]? 4- any other comments do you have? :D P.S. sorry if I'm not really good at starting conversation from scratch and out-of-nowhere :D but I hope by continuing the collaboration we can have better (more enriched) FreeBSD and better (as in more portable) B.A.T.M.A.N :-) -- Best regards, MMokhi.

4 3

[B.A.T.M.A.N.] [PATCH v5 0/7] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available
by Marek Lindner 25 Nov '19

25 Nov '19

Under normal circumstances B.A.T.M.A.N. V retrieves the neighbor throughput values to populate its metric tables from the various drivers such as WiFi throughput tables and Ethernet throughput.. Whenever the interface drivers do not export link throughput information manual overrides become necessary. To further automate and thus better support these setups, ELP may call the batman-adv throughput meter to schedule a throughput estimation to be used to populate the metric table. v5: * fix tp_vars refcount on queue_work() failure * squash batadv_tp_start_work() into batadv_tp_start() v4: * read tp measurement result only once v3: * fix ELP tp meter result computation * use batadv_has_timed_out() instead of custom implementation * set ELP tp meter test duration to 1000ms in patch #6 * add comment explaining periodic scheduling v2: * added sysfs attribute to configure tp meter test duration * fixed null pointer dereference in TP meter packet sending routine * fixed storing the measured throughput in the correct variable * checkpatch/kerneldoc/sparse/smatch cleanup Antonio Quartulli (3): batman-adv: tp_meter - prevent concurrent tp_meter sessions by using workqueue batman-adv: tp_meter - don't check for existing session batman-adv: tp_meter - add option to perform one-hop test Marek Lindner (4): batman-adv: tp_meter - allow up to 10 queued sessions batman-adv: tp_meter - add caller distinction batman-adv: ELP - use tp meter to estimate the throughput if otherwise not available batman-adv: ELP - add throughput meter test duration attribute .../ABI/testing/sysfs-class-net-batman-adv | 7 + include/uapi/linux/batadv_packet.h | 2 + net/batman-adv/bat_v.c | 1 + net/batman-adv/bat_v_elp.c | 69 ++- net/batman-adv/bat_v_elp.h | 21 + net/batman-adv/main.c | 10 +- net/batman-adv/main.h | 7 +- net/batman-adv/netlink.c | 3 +- net/batman-adv/routing.c | 6 +- net/batman-adv/sysfs.c | 3 + net/batman-adv/tp_meter.c | 484 +++++++++++------- net/batman-adv/tp_meter.h | 11 +- net/batman-adv/types.h | 36 ++ 13 files changed, 453 insertions(+), 207 deletions(-) -- 2.18.0

2 10

[B.A.T.M.A.N.] [PATCH] batman-adv: handle race condition for claims also in batadv_bla_rx
by Simon Wunderlich 02 Jul '19

02 Jul '19

From: Andreas Pape <apape(a)phoenixcontact.com> Like in the case of the patch for batadv_bla_tx to handle a race condition when claiming a mac address for bla, a similar situation can occur when claiming is triggered via batadv_bla_rx. This patch solves this with a similar approach as for batadv_bla_tx. Signed-off-by: Andreas Pape <apape(a)phoenixcontact.com> --- net/batman-adv/bridge_loop_avoidance.c | 31 ++++++++++++++++++++----------- net/batman-adv/translation-table.c | 26 ++++++++++++++++++++++++++ net/batman-adv/translation-table.h | 3 +++ 3 files changed, 49 insertions(+), 11 deletions(-) diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c index d07e89e..cab8980 100644 --- a/net/batman-adv/bridge_loop_avoidance.c +++ b/net/batman-adv/bridge_loop_avoidance.c @@ -1847,19 +1847,28 @@ bool batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, if (!claim) { /* possible optimization: race for a claim */ - /* No claim exists yet, claim it for us! + /* Make sure this packet is not looping back + * from our own backbone. */ - batadv_dbg(BATADV_DBG_BLA, bat_priv, - "bla_rx(): Unclaimed MAC %pM found. Claim it. Local: %s\n", - ethhdr->h_source, - batadv_is_my_client(bat_priv, - ethhdr->h_source, vid) ? - "yes" : "no"); - batadv_handle_claim(bat_priv, primary_if, - primary_if->net_dev->dev_addr, - ethhdr->h_source, vid); - goto allow; + if (batadv_tt_local_has_timed_out(bat_priv, ethhdr->h_source, + vid, 100)) { + /* No claim exists yet, claim it for us! + */ + batadv_dbg(BATADV_DBG_BLA, bat_priv, + "bla_rx(): Unclaimed MAC %pM found. Claim it. Local: %s\n", + ethhdr->h_source, + batadv_is_my_client(bat_priv, + ethhdr->h_source, vid) ? + "yes" : "no"); + + batadv_handle_claim(bat_priv, primary_if, + primary_if->net_dev->dev_addr, + ethhdr->h_source, vid); + goto allow; + } else { + goto handled; + } } /* if it is our own claim ... */ diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c index e75b493..b908195 100644 --- a/net/batman-adv/translation-table.c +++ b/net/batman-adv/translation-table.c @@ -4380,3 +4380,29 @@ void batadv_tt_cache_destroy(void) kmem_cache_destroy(batadv_tt_req_cache); kmem_cache_destroy(batadv_tt_roam_cache); } + +bool batadv_tt_local_has_timed_out(struct batadv_priv *bat_priv, + const u8 *addr, unsigned short vid, + unsigned int timeout) +{ + struct batadv_tt_local_entry *tt_local_entry; + bool ret = true; + + tt_local_entry = batadv_tt_local_hash_find(bat_priv, addr, vid); + if (!tt_local_entry) + goto out; + /* Check if the client has been logically deleted (but is kept for + * consistency purpose) + */ + if ((tt_local_entry->common.flags & BATADV_TT_CLIENT_PENDING) || + (tt_local_entry->common.flags & BATADV_TT_CLIENT_ROAM)) + goto out; + /* Check that the tt_local_entry has a certain age */ + if (!batadv_has_timed_out(tt_local_entry->last_seen, timeout)) + ret = false; + +out: + if (tt_local_entry) + batadv_tt_local_entry_put(tt_local_entry); + return ret; +} diff --git a/net/batman-adv/translation-table.h b/net/batman-adv/translation-table.h index 411d586..b05d0d8 100644 --- a/net/batman-adv/translation-table.h +++ b/net/batman-adv/translation-table.h @@ -65,5 +65,8 @@ bool batadv_tt_global_is_isolated(struct batadv_priv *bat_priv, int batadv_tt_cache_init(void); void batadv_tt_cache_destroy(void); +bool batadv_tt_local_has_timed_out(struct batadv_priv *bat_priv, + const u8 *addr, unsigned short vid, + unsigned int timeout); #endif /* _NET_BATMAN_ADV_TRANSLATION_TABLE_H_ */ -- 1.7.0.4

3 5

[B.A.T.M.A.N.] [RFC maint v2] batman-adv: fix adding VLANs with partial state
by Marek Lindner 09 Jun '19

09 Jun '19

Whenever a new VLAN is created on top of batman virtual interfaces the batman-adv kernel module creates internal structures to track the status of said VLAN. Amongst other things, the MAC address of the VLAN interface itself has to be stored. Without this change a VLAN and its infrastructure could be created while the interface MAC address is not stored without triggering any error, thus creating issues in other parts of the code. Prevent the VLAN from being created if the MAC address can not be stored. Fixes: 952cebb57518 ("batman-adv: add per VLAN interface attribute framework") Signed-off-by: Marek Lindner <mareklindner(a)neomailbox.ch> --- net/batman-adv/hard-interface.c | 2 +- net/batman-adv/soft-interface.c | 105 ++++++++++++++++++++++++-------- net/batman-adv/soft-interface.h | 3 +- 3 files changed, 83 insertions(+), 27 deletions(-) diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c index c405d15b..0b22cc4d 100644 --- a/net/batman-adv/hard-interface.c +++ b/net/batman-adv/hard-interface.c @@ -1000,7 +1000,7 @@ static int batadv_hard_if_event(struct notifier_block *this, if (batadv_softif_is_valid(net_dev) && event == NETDEV_REGISTER) { batadv_sysfs_add_meshif(net_dev); bat_priv = netdev_priv(net_dev); - batadv_softif_create_vlan(bat_priv, BATADV_NO_FLAGS); + batadv_softif_create_vlan_late(bat_priv, BATADV_NO_FLAGS); return NOTIFY_DONE; } diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c index edeffcb9..728d9d40 100644 --- a/net/batman-adv/soft-interface.c +++ b/net/batman-adv/soft-interface.c @@ -563,16 +563,36 @@ struct batadv_softif_vlan *batadv_softif_vlan_get(struct batadv_priv *bat_priv, } /** - * batadv_softif_create_vlan() - allocate the needed resources for a new vlan + * batadv_softif_destroy_vlan() - remove and destroy a softif_vlan object + * @bat_priv: the bat priv with all the soft interface information + * @vlan: the object to remove + */ +static void batadv_softif_destroy_vlan(struct batadv_priv *bat_priv, + struct batadv_softif_vlan *vlan) +{ + /* explicitly remove the associated TT local entry because it is marked + * with the NOPURGE flag + */ + batadv_tt_local_remove(bat_priv, bat_priv->soft_iface->dev_addr, + vlan->vid, "vlan interface destroyed", false); + + batadv_sysfs_del_vlan(bat_priv, vlan); + batadv_softif_vlan_put(vlan); +} + +/** + * batadv_softif_create_vlan_early() - allocate the needed resources for a new + * vlan, defer sysfs creation till later * @bat_priv: the bat priv with all the soft interface information * @vid: the VLAN identifier * * Return: 0 on success, a negative error otherwise. */ -int batadv_softif_create_vlan(struct batadv_priv *bat_priv, unsigned short vid) +static int batadv_softif_create_vlan_early(struct batadv_priv *bat_priv, + unsigned short vid) { struct batadv_softif_vlan *vlan; - int err; + bool client_added; vlan = batadv_softif_vlan_get(bat_priv, vid); if (vlan) { @@ -590,12 +610,6 @@ int batadv_softif_create_vlan(struct batadv_priv *bat_priv, unsigned short vid) atomic_set(&vlan->ap_isolation, 0); - err = batadv_sysfs_add_vlan(bat_priv->soft_iface, vlan); - if (err) { - kfree(vlan); - return err; - } - spin_lock_bh(&bat_priv->softif_vlan_list_lock); kref_get(&vlan->refcount); hlist_add_head_rcu(&vlan->list, &bat_priv->softif_vlan_list); @@ -604,32 +618,63 @@ int batadv_softif_create_vlan(struct batadv_priv *bat_priv, unsigned short vid) /* add a new TT local entry. This one will be marked with the NOPURGE * flag */ - batadv_tt_local_add(bat_priv->soft_iface, - bat_priv->soft_iface->dev_addr, vid, - BATADV_NULL_IFINDEX, BATADV_NO_MARK); + client_added = batadv_tt_local_add(bat_priv->soft_iface, + bat_priv->soft_iface->dev_addr, vid, + BATADV_NULL_IFINDEX, BATADV_NO_MARK); /* don't return reference to new softif_vlan */ batadv_softif_vlan_put(vlan); + if (!client_added) { + batadv_softif_destroy_vlan(bat_priv, vlan); + return -ENOENT; + } + return 0; } /** - * batadv_softif_destroy_vlan() - remove and destroy a softif_vlan object + * batadv_softif_create_vlan_late() - complete softif vlan creation with the + * sysfs entries * @bat_priv: the bat priv with all the soft interface information - * @vlan: the object to remove + * @vid: the VLAN identifier + * + * Return: 0 on success, a negative error otherwise. */ -static void batadv_softif_destroy_vlan(struct batadv_priv *bat_priv, - struct batadv_softif_vlan *vlan) +int batadv_softif_create_vlan_late(struct batadv_priv *bat_priv, + unsigned short vid) { - /* explicitly remove the associated TT local entry because it is marked - * with the NOPURGE flag - */ - batadv_tt_local_remove(bat_priv, bat_priv->soft_iface->dev_addr, - vlan->vid, "vlan interface destroyed", false); + struct batadv_softif_vlan *vlan; + int ret; + + vlan = batadv_softif_vlan_get(bat_priv, vid); + if (!vlan) + return -ENOENT; + + ret = batadv_sysfs_add_vlan(bat_priv->soft_iface, vlan); - batadv_sysfs_del_vlan(bat_priv, vlan); batadv_softif_vlan_put(vlan); + return ret; +} + +/** + * batadv_softif_create_vlan() - allocate the needed resources for a new vlan + * @bat_priv: the bat priv with all the soft interface information + * @vid: the VLAN identifier + * + * Return: 0 on success, a negative error otherwise. + */ +static int batadv_softif_create_vlan(struct batadv_priv *bat_priv, + unsigned short vid) +{ + int err; + + err = batadv_softif_create_vlan_early(bat_priv, vid); + if (err) + return err; + + err = batadv_softif_create_vlan_late(bat_priv, vid); + return err; } /** @@ -648,6 +693,7 @@ static int batadv_interface_add_vid(struct net_device *dev, __be16 proto, { struct batadv_priv *bat_priv = netdev_priv(dev); struct batadv_softif_vlan *vlan; + bool client_added; int ret; /* only 802.1Q vlans are supported. @@ -683,9 +729,14 @@ static int batadv_interface_add_vid(struct net_device *dev, __be16 proto, * flag. This must be added again, even if the vlan object already * exists, because the entry was deleted by kill_vid() */ - batadv_tt_local_add(bat_priv->soft_iface, - bat_priv->soft_iface->dev_addr, vid, - BATADV_NULL_IFINDEX, BATADV_NO_MARK); + client_added = batadv_tt_local_add(bat_priv->soft_iface, + bat_priv->soft_iface->dev_addr, vid, + BATADV_NULL_IFINDEX, BATADV_NO_MARK); + + if (!client_added) { + batadv_softif_destroy_vlan(bat_priv, vlan); + return -ENOENT; + } return 0; } @@ -850,6 +901,10 @@ static int batadv_softif_init_late(struct net_device *dev) if (ret < 0) goto unreg_debugfs; + ret = batadv_softif_create_vlan_early(bat_priv, BATADV_NO_FLAGS); + if (ret < 0) + goto unreg_debugfs; + return 0; unreg_debugfs: diff --git a/net/batman-adv/soft-interface.h b/net/batman-adv/soft-interface.h index daf87f07..b8a9a3c8 100644 --- a/net/batman-adv/soft-interface.h +++ b/net/batman-adv/soft-interface.h @@ -36,7 +36,8 @@ struct net_device *batadv_softif_create(struct net *net, const char *name); void batadv_softif_destroy_sysfs(struct net_device *soft_iface); bool batadv_softif_is_valid(const struct net_device *net_dev); extern struct rtnl_link_ops batadv_link_ops; -int batadv_softif_create_vlan(struct batadv_priv *bat_priv, unsigned short vid); +int batadv_softif_create_vlan_late(struct batadv_priv *bat_priv, + unsigned short vid); void batadv_softif_vlan_put(struct batadv_softif_vlan *softif_vlan); struct batadv_softif_vlan *batadv_softif_vlan_get(struct batadv_priv *bat_priv, unsigned short vid); -- 2.17.0

4 4

[PATCH v3 0/2] batman-adv: Add routeable multicast optimizations
by Linus Lüssing 08 Jun '19

08 Jun '19

The following patchset fills the next gaps in the multicast address rules page by adding support for group-aware optimizations for multicast addresses of scope greater than link-local. So far, only link-local addresses were optimized as packets with routeable addresses not only need to be forwarded to local multicast listeners but also multicast routers. "Handling rules depending on multicast address:" [0] Before: * Ipv4, link-local: supported without bridges * IPv6, link-local: supported * IPv4, routeable: support planned. * IPv6, routeable: support planned. After: * Ipv4, link-local: supported without bridges * IPv6, link-local: supported * IPv4, routeable: supported without bridges. * IPv6, routeable: supported. Patch 1 adds the detection of multicast routers and announces them via two new flags in its multicast TVLV. TVLV receivers will memorize this and fill lists similar to how we already do for the WANT_ALL_IPV4/IPV6 flags. Currently the detection for bridged-in IPv6 multicast routers is not quite what the RFC for multicast router discovery suggests. But once the MRD implementation in the Linux bridge has matured a bit, I'm going to swap this simplified approach with tapping into the bridge once more, asking the bridge for the presence of multicast routers on the link. (This will then also add support for "IPv4, routeable, with bridges") Then patch 2 implements the changes to the forwarding plane, utilizing the new information we have gathered with the second patch. This patchset is rebased to: "[PATCH v4 0/2] batman-adv: routeable multicast preparations" https://patchwork.open-mesh.org/project/b.a.t.m.a.n./list/?series=262 Regards, Linus [0]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-… --- Changelog v3: * rebased to master + routeable multicast preparations v4 * fixed build errors with CONFIG_IPV6_MROUTE disabled * fixed build errors with CONFIG_IPV6 disabled Changelog v2: * rebased to master * split patchset in two with the intention to ease reviewing (no code changes, just the last two patches here) * removed unncessarilly added newline in batadv_mcast_flags_log() [PATCH 5/6] / [PATCH v2 1/2] * kerneldoc: @BATADV_MCAST_NO_WANT_ALL_RTR6 -> -"NO_" in enum batadv_mcast_flags [PATCH 5/6] / [PATCH v2 1/2]

2 4

Call for participation for BattleMesh V12 (8-14 July 2019, Paris)
by Baptiste Jonglez 31 May '19

31 May '19

Hello, The local organization team is proud to announce that this year's Battlemesh will be held near Paris, from 8 to 14 July! The event aims to bring together people from across the globe who are interested in community networks, including wireless mesh network technologies, fiber infrastructure, Do-It-Yourself Internet Access Providers, and more generally how to create and maintain a thriving community of people involved in building their own networks. We envision 7 days full of expert presentations, practical workshops, late-night hacking sessions, and fruitful discussions: whether you are a mesh networking enthusiast, community networking activist, protocol developer, or have an interest in networking in general, come and join us! More information about the event is available below or on the website: https://www.battlemesh.org/BattleMeshV12 Where ===== Le 6B, 6-10 quai de Seine, 93200 Saint-Denis, France (very close to Paris). GPS: geo:48.93835,2.34259 Map: https://www.openstreetmap.org/?mlat=48.93835&mlon=2.34259#map=18/48.93835/2… Web: https://www.le6b.fr/ Travel directions: https://www.battlemesh.org/BattleMeshV12#Where What ==== We will have organized talks, workshops and discussion panels on community networks and wireless mesh networks. There will also be more informal activities: cooperative hacking, self-organized projects, and (we hope) delightful conversations! A first draft of the schedule (handle with care!) is available here: https://www.battlemesh.org/BattleMeshV12#Talk_Schedule_and_Workshops How to register =============== The event itself is free of charge and open for all! However, it makes the organisation much easier if you tell us in advance that you plan to come. To register: https://www.battlemesh.org/BattleMeshV12#How_to_register Current list of participants: https://battlemesh.org/BattleMeshV12/Participants Accommodation package ===================== For those of you who are looking for a convenient and low cost accommodation option in Paris: we negotiated a special group reservation for 24 people at an hostel. There are still a few beds left, register now before we run out! https://www.battlemesh.org/BattleMeshV12#Accommodation_package Call for participation ====================== We invite participants to propose workshops, talks or panel discussions relating to network infrastructure in general, how it can be built and operated as a common, and how to sustain a community around networking. We welcome contributions that broadly address these questions from any of several perspectives: technical, organisational, economical, regulatory, juridical, political. Deadline: 10 May 2019, now extended to June 7th! To submit an event: https://www.battlemesh.org/BattleMeshV12#Call_for_participation Endorsements ============ If your organization wants to support the event by spreading the word, you can endorse the event. For this, just write an article on your website / blog / social media, and send us an email with the link and your logo to: (v12) at (battlemesh) dot (org) See existing endorsements for a template: https://www.battlemesh.org/BattleMeshV12#Endorsements Contact ======= * Web: https://battlemesh.org/BattleMeshV12 * Contact email (preferred): v12 at battlemesh.org * Public mailing list: https://ml.ninux.org/mailman/listinfo/battlemesh * IRC: irc.freenode.net #battlemesh * Twitter: https://twitter.com/battlemesh/ * Mastodon: https://toot.aquilenet.fr/@battlemesh12 The Local Organization Team =========================== Aube Baptiste Daniele Dash Vi and many other volunteers!

1 0

[PATCH v4 0/2] batman-adv: routeable multicast preparations
by Linus Lüssing 26 May '19

26 May '19

This patchset provides some code restructuring in preparation for the support of routeable multicast addresses. The first one swaps the kernel MAC multicast list with the equivalent IPv4 and IPv6 ones: This allows an easier filtering later. Patch 2 is a first application of such filtering and allows omitting some redundant address additions to the TT. Later, the same will be necessary for routeable multicast addresses. --- Changelog v4: * rebased to master: -> removed [PATCH v3 1/3] (now applied) * fixed build issues with CONFIG_IPV6 disabled Changelog v3: * fixed "From:" address in mail header Changelog v2: * rebased to master * removed already applied patch ("batman-adv: mcast: fix multicast tt/tvlv worker locking") * split patchset in two with the intention to ease reviewing (no code changes, just omitted the last two patches) * kerneldoc: alignment for batadv_mcast_mla_flags_update() [PATCH 2/6] / [PATCH v2 1/3] * fixed compile issues due to a duplicated member in struct * batadv_priv_mcast [PATCH 2/6] / [PATCH v2 1/3] * kerneldoc: added missing @flags for batadv_mcast_mla_flags_update() [PATCH 2/6] / [PATCH v2 1/3] * kerneldoc: @flags -> @tvlv_flags in struct batadv_mcast_mla_flags [PATCH 2/6] / [PATCH v2 1/3]

1 2

[PATCH v2 0/3] batman-adv: routeable multicast preparations
by T_X 25 May '19

25 May '19

This patchset provides some code restructuring in preparation for the support of routeable multicast addresses. The first one adds a slightly cleaner separation of fetching and updating. And by that allows shortening the newly introduced spin-lock. The second one swaps the kernel MAC multicast list with the equivalent IPv4 and IPv6 ones: This allows an easier filtering later. Finally patch 3 is a first application of such filtering and allows omitting some redundant address additions to the TT. Later, the same will be necessary for routeable multicast addresses. --- Changelog v2: * rebased to master * removed already applied patch ("batman-adv: mcast: fix multicast tt/tvlv worker locking") * split patchset in two with the intention to ease reviewing (no code changes, just omitted the last two patches) * kerneldoc: alignment for batadv_mcast_mla_flags_update() [PATCH 2/6] / [PATCH v2 1/3] * fixed compile issues due to a duplicated member in struct batadv_priv_mcast [PATCH 2/6] / [PATCH v2 1/3] * kerneldoc: added missing @flags for batadv_mcast_mla_flags_update() [PATCH 2/6] / [PATCH v2 1/3] * kerneldoc: @flags -> @tvlv_flags in struct batadv_mcast_mla_flags [PATCH 2/6] / [PATCH v2 1/3]

2 4

[PATCH 0/3] batman-adv: broadcast flooding improvements
by Linus Lüssing 25 May '19

25 May '19

Hi, This patchset adds two improvements for the broadcast flooding algorithm: The first patch refactors/reorders the broadcast packet queueing. Before a broadcast packet was always queued. Now the queueing decision is performed on a per interface basis. Also the first broadcast is always transmitted immediately, without queueing now to increase performance. Furthermore this restructuring prepares for the next two patches: Patches 2 and 3 introduce a broadcast-packet-to-unicast mechanism. Similar to the multicast-to-unicast feature of the multicast back-end a broadcast packet is split into multiple unicast transmissions. The major difference here, for the broadcast flooding, is that it is performed on a per-hop instead of the initial originator node basis. This should improve throughput and reliability in densely populated receiver scenarios, where the multicast back-end is not able to operate (the multicast back-end is more targeted at sparsely populated receiver scenarios so far). Regards, Linus

2 8

[PATCH v2 0/2] batman-adv: Add routeable multicast optimizations
by Linus Lüssing 25 May '19

25 May '19

The following patchset fills the next gaps in the multicast address rules page by adding support for group-aware optimizations for multicast addresses of scope greater than link-local. So far, only link-local addresses were optimized as packets with routeable addresses not only need to be forwarded to local multicast listeners but also multicast routers. "Handling rules depending on multicast address:" [0] Before: * Ipv4, link-local: supported without bridges * IPv6, link-local: supported * IPv4, routeable: support planned. * IPv6, routeable: support planned. After: * Ipv4, link-local: supported without bridges * IPv6, link-local: supported * IPv4, routeable: supported without bridges. * IPv6, routeable: supported. Patch 1 adds the detection of multicast routers and announces them via two new flags in its multicast TVLV. TVLV receivers will memorize this and fill lists similar to how we already do for the WANT_ALL_IPV4/IPV6 flags. Currently the detection for bridged-in IPv6 multicast routers is not quite what the RFC for multicast router discovery suggests. But once the MRD implementation in the Linux bridge has matured a bit, I'm going to swap this simplified approach with tapping into the bridge once more, asking the bridge for the presence of multicast routers on the link. (This will then also add support for "IPv4, routeable, with bridges") Then patch 2 implements the changes to the forwarding plane, utilizing the new information we have gathered with the second patch. This patchset is rebased to: "[PATCH v3 0/3] batman-adv: routeable multicast preparations" https://patchwork.open-mesh.org/project/b.a.t.m.a.n./list/?series=252 Regards, Linus [0]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-… --- Changelog v2: * rebased to master * split patchset in two with the intention to ease reviewing (no code changes, just the last two patches here) * removed unncessarilly added newline in batadv_mcast_flags_log() [PATCH 5/6] / [PATCH v2 1/2] * kerneldoc: @BATADV_MCAST_NO_WANT_ALL_RTR6 -> -"NO_" in enum batadv_mcast_flags [PATCH 5/6] / [PATCH v2 1/2]

2 3

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N May 2019