Problems with Multiple Interfaces
by joe＠careyhome.org
Hi Everybody,
I'm running BATMAN v 2019.2 with ath10k on OpenWRT. The particular router I'm using has two interfaces, 2.4 GHz and 5GHz. With each router using single interface (e.g. 2.4 GHz), it works fine. When I add a second interface (e.g. 5GHz), it sometimes hangs.
I know that BATMAN is expected to alternate between the two interfaces, but that doesn't seem to be working. As you probably know, using two interfaces should dramatically improve throughput if you need to make a hop through another mesh node.
To verify this is the problem, I did a test where I ran three routers, 2.4G <> Dual (2.4G & 5G) <> 5G. I would try to ping between the two routers that were using just a single interface. Obviously, that must hop through the dual radio router. The dual radio router has both interfaces on the bat0 master, and batctl reports they're both active.
The system would sometimes lose link, although batctl would report getting neighbor messages. Even using the batctl ping function doesn't get through. I can see traffic flowing on both the 2.4 GHz and 5GHz interfaces.
I'm happy to provide lots of configuration detail, but I thought I'd start with a high level description in case this is a known problem.
Any assistance is appreciated. Thank you,
--Joe
3 days, 3 hours
How to mesh over ethernet VLAN?
by Andi Depressivum
Hello everybody,
What's the correct setup to mesh also over an existing ethernet VLAN link?
My core network with all routers & servers is running on VLAN 3
(eth0.3 in the routers). How do I have to setup batman-adv to a) mesh
also over this existing link and b) propagate this VLAN also over
wireless links. Bridging eth0.3 with bat0.3 and adding eth0.3 also as
a hardif doesn't work, as it will remove eth0.3 from the bridge.
If I add eth0 instead as hardif the routers are only seeing each other
over wireless link. Or do I have to use a separate VLAN for ethernet
meshing which isn't bridged to a bat0.X interface?
Thanks a lot!
3 days, 14 hours
Batman-adv On Raspberry Pi Zero
by giuseppedv＠gmail.com
Hi all,
I have to create a Mesh Ad-Hoc Wireless Network using a certain number of Raspberry Pi Zero.
I have decided to use Pi Zero Wireless card in ad-hoc mode and use the batman-adv module
to create the mesh over the ad-hoc wireless network. Here my systems:
- Raspberries Pi Zero W V1.1.
- Raspbian Buster: 2021-03-04-raspios-buster-armhf-lite.img
- Kernel: 5.10.17+
- Batman-adv: built-in kernel module.
No problems to create the ad-hoc wireless network between the Zeroes, even if the mtu needed for Batman-adv
complains:
[quote]# ip link set dev wlan0 mtu 1532
Error: mtu greater than device maximum[/quote]
Problems arise when I try to add the wlan0 interface to batman handler (the batman-adv module is loaded
correctly with modprobe or at boot time)
batctl if add wlan0 <--- OK No Problems
but if I want to request the wlan0 status I receive
[quote]batctl if
wlan0: <error reading status> [/quote]
Anyone experienced the same issues?
4 days, 14 hours
[PATCH 0/3] pull request for net-next: batman-adv 2021-04-08
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 b1de0f01b0115575982cf24c88b35106449e9aa7:
batman-adv: Use netif_rx_any_context(). (2021-02-13 18:08:40 +0100)
are available in the Git repository at:
git://git.open-mesh.org/linux-merge.git tags/batadv-next-pullrequest-20210408
for you to fetch changes up to 35796c1d343871fa75a6e6b0f4584182cbeae6ac:
batman-adv: Fix misspelled "wont" (2021-03-30 21:19:50 +0200)
----------------------------------------------------------------
This cleanup patchset includes the following patches:
- for kerneldoc in batadv_priv, by Linus Luessing
- drop unused header preempt.h, by Sven Eckelmann
- Fix misspelled "wont", by Sven Eckelmann
----------------------------------------------------------------
Linus Lüssing (1):
batman-adv: Fix order of kernel doc in batadv_priv
Sven Eckelmann (2):
batman-adv: Drop unused header preempt.h
batman-adv: Fix misspelled "wont"
net/batman-adv/bat_iv_ogm.c | 2 +-
net/batman-adv/bridge_loop_avoidance.c | 1 -
net/batman-adv/types.h | 10 +++++-----
3 files changed, 6 insertions(+), 7 deletions(-)
4 days, 16 hours
IPv4/IPv6 separation in bridge code for multicast routers
by Linus Lüssing
Hi,
I wanted to add the remaining pieces for batman-adv to support
IPv4 multicast groups in bridged setups, next to the IPv6 support
already in place. For which we'd need MRD support. So once more
I'd tap into the bridge for this information from batman-adv.
Then I realized again that the bridge keeps track of the
IGMP/MLD querier per protocol family but not for the multicast
router ports. For the latter we only have one list right now. For
batman-adv we have the multicast router flags and logic already
separate though.
I started separating the router list for IPv4 and IPv6 in the
bridge, but it seems there are already external users for the
protocol family unaware router list right now: netlink and switchdev.
Now I'm wondering:
A) For netlink:
Would it be fine to just add a MDBA_ROUTER_PATTR_FAMILY with
either the value PF_INET or PF_INET6? The downside would be that
a userspace application which does not know this new attribute
yet would potentially see or list a duplicate.
Another option would be to add two separate attributes:
MDBA_ROUTER_PATTR_{INET,INET6}. Which looks a bit more clumsy and
and inflexible to me. But would have a better compatiblity when
userspace requests a router ports dump. For events there'd still
be the same issue of duplicates though, as IPv4 and IPv6 routers
might appear or disappear asynchronously.
B) For switchdev:
I'm not that familiar with switchdev. Should it generally be
possible to separate the protocol family here? Or would it be
better to add a few more lines to the bridge code to
only call switchdev_port_attr_set() when transitioning between
v4-rtr, v6-rtr: (off, off) <=> (on, on) | (on, off) | (off, on)?
At least for a start, maybe?
C)
Or am I missing something in the MRD RFC (RFC4286) which implies
that a Multicast router Advertisement should be interpreted
across protocol families?
Any ideas what might be the best way to tackle this?
Regards, Linus
6 days, 7 hours
