B.A.T.M.A.N September 2021

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

6 participants
4 discussions

[PATCH net 00/12] net: iflink and link-netnsid fixes

by Sabrina Dubroca

In a lot of places, we use this kind of comparison to detect if a device has a lower link: dev->ifindex != dev_get_iflink(dev) This seems to be a leftover of the pre-netns days, when the ifindex was unique over the whole system. Nowadays, with network namespaces, it's very easy to create a device with the same ifindex as its lower link: ip netns add main ip netns add peer ip -net main link add dummy0 type dummy ip -net main link add link dummy0 macvlan0 netns peer type macvlan ip -net main link show type dummy 9: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop ... ip -net peer link show type macvlan 9: macvlan0@if9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop ... To detect if a device has a lower link, we can simply check the existence of the dev->netdev_ops->ndo_get_iflink operation, instead of checking its return value. In particular, I attempted to fix one of these checks in commit feadc4b6cf42 ("rtnetlink: always put IFLA_LINK for links with a link-netnsid"), but this patch isn't correct, since tunnel devices can export IFLA_LINK_NETNSID without IFLA_LINK. That patch needs to be reverted. This series will fix all those bogus comparisons, and export missing IFLA_LINK_NETNSID attributes in bridge and ipv6 dumps. ipvlan and geneve are also missing the get_link_net operation, so userspace can't know when those device are cross-netns. There are a couple of other device types that have an ndo_get_iflink op but no get_link_net (virt_wifi, ipoib), and should probably also have a get_link_net. Sabrina Dubroca (12): ipvlan: add get_link_net geneve: add get_link_net Revert "rtnetlink: always put IFLA_LINK for links with a link-netnsid" rtnetlink: always put IFLA_LINK for links with ndo_get_iflink bridge: always put IFLA_LINK for ports with ndo_get_iflink bridge: advertise IFLA_LINK_NETNSID when dumping bridge ports ipv6: always put IFLA_LINK for devices with ndo_get_iflink ipv6: advertise IFLA_LINK_NETNSID when dumping ipv6 addresses net: link_watch: fix operstate when the link has the same index as the device net: link_watch: fix detection of urgent events batman-adv: fix iflink detection in batadv_is_on_batman_iface batman-adv: fix detection of lower link in batadv_get_real_netdevice drivers/net/can/vxcan.c | 2 +- drivers/net/geneve.c | 8 ++++++++ drivers/net/ipvlan/ipvlan_main.c | 9 +++++++++ drivers/net/veth.c | 2 +- include/net/rtnetlink.h | 4 ++++ net/batman-adv/hard-interface.c | 4 ++-- net/bridge/br_netlink.c | 4 +++- net/core/link_watch.c | 4 ++-- net/core/rtnetlink.c | 25 ++++++++++++------------- net/ipv6/addrconf.c | 11 ++++++++++- 10 files changed, 52 insertions(+), 21 deletions(-) -- 2.28.0

10 months, 2 weeks

Bonding Alternating

by brian.edmisten＠viasat.com

Before Adding radios to my setup I connected to computers with three NICs each. I added all three interfaces to the mesh interface bat0 on each. I then run iperf across it and all the traffic seems to go on one interface. I run iperf3 with -p 4 so there are multiple streams. Changing it to bonding does not seem to change the behavior. batctl o - shows all three interfaces batctl n - shows three interfaces -This I thought seemed odd as its one neighbor across three links batctl tg - shows all clients Via one address If anyone can point me at what to look at next or what might be wrong would help. I am using BATMAN_V version 2019.4 in kernel 5.4.68.

1 year, 6 months

Re: Some bugs in batmand(Github)

by Sven Eckelmann

On Monday, 6 September 2021 14:59:12 CEST Ryan Cai wrote: > I am Ryan Cai, coming from HK. Recently, I am looking at batmand, which is really cool. However, I found some potential improper locking bugs due to the unreleased locks like here, https://github.com/open-mesh-mirror/batmand/blob/df6fcb8706d325b3fd4c700049…, the lock could not correctly be released when the middle break statement is executed. The bug pattern also exists in [1]. Could you confirme these? I would love to create PR for these. [...] > [1] > https://github.com/open-mesh-mirror/batmand/blob/df6fcb8706d325b3fd4c700049… > https://github.com/open-mesh-mirror/batmand/blob/df6fcb8706d325b3fd4c700049… Please contact the maintainer Elektra and the mailing list about it [1]. Btw. I don't see how the break inside the loop should affect the unlocking. The pthread_mutex_unlock comes after the loop and not as part of the loop. And we are also not doing any work via Github. Please use the normal contribution [2] procedure and don't open PRs on random github repositories. Kind regards, Sven [1] https://www.open-mesh.org/projects/open-mesh/wiki/MailingList [2] https://www.open-mesh.org/projects/open-mesh/wiki/Contribute

1 year, 6 months

Dynamic DHCP server assignment and spin-up on batman-adv mesh network

by tanner.perkins＠cnftech.com

If this is not the best place to ask questions regarding mesh networks utilizing the batman-adv kernel module, I apologies and please point me to where I need to be. I'm looking to set up distributed mesh network using the batman-adv Linux kernel module. However, I don't want to have to statically assign IP addresses to all my nodes therefore my first thought was to use DHCP. The problem arises in my scenario that any node could come and go in the mesh network as they move in and out range of the network. Therefore manually allocating a single or even a few DHCP servers isn't realistic as that DHCP server may drop out of the network at anytime. Is there a dynamic way to reassign the DHCP server based on the nodes still within the network when the previous DHCP server drops from the network? Thanks, -tdev

1 year, 6 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N September 2021