B.A.T.M.A.N

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

15 participants
4308 discussions

[B.A.T.M.A.N.] [PATCH v2] alfred: Request MAC resolution for IPv4 address not in ARP cache
by Jonathan Haws 25 Oct '18

25 Oct '18

When using IPv4, if the remote server is not yet in the ARP cache, the MAC resolution will fail and data appear to not be shared via alfred. Add a routine (modified from batctl sources) to request MAC resolution by simply sending a datagram to the discard port (UDP/9). This adds the remote MAC to the ARP cache, resulting in successful MAC resolution. Fixes: c7da798113a2 ("alfred: IPv4 multicast distribution support.") Signed-off-by: Jonathan Haws <jhaws(a)sdl.usu.edu> --- util.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/util.c b/util.c index dd3f00f..3a0c279 100644 --- a/util.c +++ b/util.c @@ -30,6 +30,7 @@ #include <sys/ioctl.h> #include <sys/time.h> #include <time.h> +#include <unistd.h> #include "alfred.h" int time_diff(struct timespec *tv1, struct timespec *tv2, @@ -80,11 +81,35 @@ bool is_valid_ether_addr(uint8_t addr[ETH_ALEN]) return true; } +static void ipv4_request_mac_resolve(const alfred_addr *addr) +{ + const struct sockaddr *sockaddr; + struct sockaddr_in inet4; + size_t sockaddr_len; + int sock; + char t = 0; + + sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); + if (sock < 0) + return; + + memset(&inet4, 0, sizeof(inet4)); + inet4.sin_family = AF_INET; + inet4.sin_port = htons(9); + inet4.sin_addr.s_addr = addr->ipv4.s_addr; + sockaddr = (const struct sockaddr *)&inet4; + sockaddr_len = sizeof(inet4); + + sendto(sock, &t, sizeof(t), 0, sockaddr, sockaddr_len); + close(sock); +} + int ipv4_arp_request(struct interface *interface, const alfred_addr *addr, struct ether_addr *mac) { struct arpreq arpreq; struct sockaddr_in *sin; + int retries = 1; memset(&arpreq, 0, sizeof(arpreq)); memset(mac, 0, ETH_ALEN); @@ -99,6 +124,14 @@ int ipv4_arp_request(struct interface *interface, const alfred_addr *addr, if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) return -1; + while (retries-- && !(arpreq.arp_flags & ATF_COM)) { + ipv4_request_mac_resolve(addr); + usleep(200000); + + if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) + return -1; + } + if (arpreq.arp_flags & ATF_COM) { memcpy(mac, arpreq.arp_ha.sa_data, sizeof(*mac)); } else { -- 2.17.1

2 2

Re: [B.A.T.M.A.N.] alfred and batadv-vis issue
by Jonathan Haws 25 Oct '18

25 Oct '18

Gary, Interesting. Looking at that code I would think it wouldn't work any different than the original because retries is set to 1, so the first entrance into the first while will reduce that to 0 causing you to never enter that second loop. That should result in the same behavior as if the second loop wasn't even there. If the second ioctl fails, the request still went out to the other device, so will populate the arp cache for the next sync. That's how it worked in my setup. Can you give more details on what is not working? FYI, l'm going to be in the Grand Canyon the next few days and likely won't be able to respond. Thanks! Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: gary <guohuizou2000(a)sina.com> Date: 10/25/18 3:06 AM (GMT-07:00) To: 'Sven Eckelmann' <sven(a)narfation.org>, Jonathan Haws <jhaws(a)sdl.usu.edu> Cc: b.a.t.m.a.n(a)lists.open-mesh.org Subject: RE: [B.A.T.M.A.N.] alfred and batadv-vis issue Hi Sven and Jon, The patch does NOT work for me. I review the code again and find the issue. The following code may make my testbed work. --- a/util.c +++ b/util.c @@ -122,14 +122,14 @@ int ipv4_arp_request(struct interface *interface, const alfred_addr *addr, arpreq.arp_dev[sizeof(arpreq.arp_dev) - 1] = '\0'; if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) - return -1; - - while (retries-- && !(arpreq.arp_flags & ATF_COM)) { - ipv4_request_mac_resolve(addr); - usleep(200000); - - if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) - return -1; + { + while (retries-- && !(arpreq.arp_flags & ATF_COM)) { + ipv4_request_mac_resolve(addr); + usleep(200000); + + if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) + return -1; + } } Regards, Gary -----Original Message----- From: Sven Eckelmann <sven(a)narfation.org> Sent: 2018年10月25日 14:15 To: Jonathan Haws <jhaws(a)sdl.usu.edu> Cc: guohuizou2000(a)sina.com; b.a.t.m.a.n(a)lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] alfred and batadv-vis issue On Mittwoch, 24. Oktober 2018 18:39:43 CEST Jonathan Haws wrote: [...] > I just submitted a patch that pulls the request_mac_resolve() routine > from batctl, modifies it appropriately, and uses it when MAC > resolution isn't from the cache. > > I've tested this with my VM setup here and it works properly (after I > verified that the nodes were not sharing messages first). > > Gary - can you try the patch with your setup and make sure it solves > the problem in your setup as well? The patch can be found at https://patchwork.open-mesh.org/patch/17552/ (or directly on the mailing list) Please reply via mail with a line Tested-by: FirstName LastName <guohuizou2000(a)sina.com> when you've successfully tested it (FirstName and LastName have to be replaced with your actual name). Kind regards, Sven

1 0

[B.A.T.M.A.N.] [PATCH alfred] Request MAC resolution for IPv4 address not in ARP cache
by Jonathan Haws 24 Oct '18

24 Oct '18

When using IPv4, if the remote server is not yet in the ARP cache, the MAC resolution will fail and data appear to not be shared via alfred. Add a routine (modified from batctl sources) to request MAC resolution by simply sending a datagram to the discard port (UDP/9). This adds the remote MAC to the ARP cache, resulting in successful MAC resolution. Signed-off-by: Jonathan Haws <jhaws(a)sdl.usu.edu> --- alfred.h | 1 + util.c | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/alfred.h b/alfred.h index eecfdfd..5771483 100644 --- a/alfred.h +++ b/alfred.h @@ -213,3 +213,4 @@ uint16_t get_random_id(void); bool is_valid_ether_addr(uint8_t *addr); int ipv4_arp_request(struct interface *interface, const alfred_addr *addr, struct ether_addr *mac); +void ipv4_request_mac_resolve(const alfred_addr *addr); diff --git a/util.c b/util.c index dd3f00f..a6a98b9 100644 --- a/util.c +++ b/util.c @@ -30,6 +30,7 @@ #include <sys/ioctl.h> #include <sys/time.h> #include <time.h> +#include <unistd.h> #include "alfred.h" int time_diff(struct timespec *tv1, struct timespec *tv2, @@ -85,6 +86,7 @@ int ipv4_arp_request(struct interface *interface, const alfred_addr *addr, { struct arpreq arpreq; struct sockaddr_in *sin; + int retries = 1; memset(&arpreq, 0, sizeof(arpreq)); memset(mac, 0, ETH_ALEN); @@ -99,6 +101,14 @@ int ipv4_arp_request(struct interface *interface, const alfred_addr *addr, if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) return -1; + while (retries-- && !(arpreq.arp_flags & ATF_COM)) { + ipv4_request_mac_resolve(addr); + usleep(200000); + + if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) + return -1; + } + if (arpreq.arp_flags & ATF_COM) { memcpy(mac, arpreq.arp_ha.sa_data, sizeof(*mac)); } else { @@ -108,3 +118,26 @@ int ipv4_arp_request(struct interface *interface, const alfred_addr *addr, return 0; } + +void ipv4_request_mac_resolve(const alfred_addr *addr) +{ + const struct sockaddr *sockaddr; + struct sockaddr_in inet4; + size_t sockaddr_len; + int sock; + char t = 0; + + sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); + if (sock < 0) + return; + + memset(&inet4, 0, sizeof(inet4)); + inet4.sin_family = AF_INET; + inet4.sin_port = htons(9); + inet4.sin_addr.s_addr = addr->ipv4.s_addr; + sockaddr = (const struct sockaddr *)&inet4; + sockaddr_len = sizeof(inet4); + + sendto(sock, &t, sizeof(t), 0, sockaddr, sockaddr_len); + close(sock); +} -- 2.17.1

2 2

[B.A.T.M.A.N.] Additional Assistance
by Corey Combs 23 Oct '18

23 Oct '18

All, thank you for the replies yesterday. Would you be able to offer some more insight into updating the 2 packages? I have had some successes, but not all the beagle bones have recognized the new version of batman-adv when I run batctl -v. The general method I've been using is the script here https://gist.github.com/marvin/186a609d1e88f7426747 with version 2016.4. The starting version on the Beagle Bones is batctl debian-2012.1.0-1 > [batman-adv 2012.5.0] as mentioned previously. After running this script and doing a $ modprobe batman-adv followed by $ batctl -v I get $ batctl 2016.4 [batman-adv 2012.5.0]. I have also attempted to uninstall batctl and batman-adv with $ apt-get --purge remove batctl and $ apt-get --purge remove batman-adv and reinstall using the script, but that hasn't worked across all devices. The laptop I have is running Debian 9.5 with batctl debian-2016.5-1 [batman-adv 2016.4] and the Beagles are running Debian 7.9. I would like to avoid reimaging the Beagles at this point in time. Please pardon my lack of knowledge on the topic, as I'm still relatively new to Linux and have been learning a great deal in the past few months. I greatly appreciate your help on the topic. Regards, Corey

3 2

[B.A.T.M.A.N.] Version help
by Corey Combs 22 Oct '18

22 Oct '18

Hello, I'm currently working on a project that uses BATMAN for a mesh network across multiple Beagle Bone Blacks which are running a Debian version 7.9 at the moment. They also are running batctl debian-2012.1.0-1 [batman-adv 2012.5.0]. I would like to connect a laptop to the existing network either using Debian or Ubuntu, however I have run into issues with compatibility. I configured everything identically with the laptop and I believe I'm connected to the network, but I cannot see any other devices on the network. Is it advisable to upgrade the version of batctl on the 'bone or downgrade the version on debian or Ubuntu so that the versions align? Or is there something else I am missing in my efforts? My process for configuring the BBB and the laptop follow this construct, using appropriate hardware names when required. I have it all in a script that runs on startup so it differs a little from the lines below. Each node has it's own assigned IP address as well. modprobe batman-adv batctl if add eth0 ifup wlan0 ifconfig wlan0 ifconfig wlan0 down ifconfig wlan0 mtu 1532 iwconfig wlan0 mode ad-hoc essid reynoldsplus ap CA:FE:C0:DE:F0:0D channel 11 batctl if add wlan0 ifconfig wlan0 up ifconfig bat0 up ifconfig bat0 10.200.8.1 route add default gw 10.0.99.1 echo bat0 > /sys/class/net/eth0/batman_adv/mesh_iface echo 1 > /proc/sys/net/ipv4/ip_forward Thank you. Corey

3 2

[B.A.T.M.A.N.] [PATCH 00/38] batctl: pre-netlink restructuring, part 1
by Sven Eckelmann 22 Oct '18

22 Oct '18

Hi, the batctl command already has support to get (previously debugfs) tables via netlink. It does this while still being able to fall back to the old debugfs tables on kernels which don't support the new generic netlink family. Something similar should be done in the future for the settings which are currently part of sysfs. But we can already see that the current integration of netlink in batctl only done in a single file - netlink.c But this file is already starting to be so big that working with it is rather cumbersome. So as first steps: * restructure command registration * move commands in separate files (which should store their actual implementation) * add a new helper command to receive multicast group messages from the kernel More things will follow in the future. Kind regards, Sven Sven Eckelmann (38): batctl: Drop unused define SOCKET_PATH_FMT batctl: Use common code organization for statistics batctl: Drop legacy vis_* related warning messages batctl: Move loglevel command to separate file batctl: Move log command to separate file batctl: Move gw_mode command to separate file batctl: Move routing_algo command to separate file batctl: Rename tp_meter to throughputmeter batctl: Introduce datastructure for subcommands batctl: Add per command flags batctl: Use command structure for remaining subcommands batctl: Use getopt to parse main options batctl: Store usage line next to command batctl: Prepare command infrastructure for shared functions batctl: Add type to command to structure usage output batctl: Convert debug table to command infrastructure batctl: Convert sysfs settings to command infrastructure batctl: Move backbonetable debug table to own file batctl: Move claimtable debug table to own file batctl: Move dat_cache debug table to own file batctl: Move gateways debug table to own file batctl: Move mcast_flags debug table to own file batctl: Move nc_nodes debug table to own file batctl: Move neighbors debug table to own file batctl: Move originators debug table to own file batctl: Move transglobal debug table to own file batctl: Move translocal debug table to own file batctl: Move aggregation setting to own file batctl: Move bonding setting to own file batctl: Move bridge_loop_avoidance setting to own file batctl: Move distributed_arp_table setting to own file batctl: Move fragmentation setting to own file batctl: Move isolation_mark setting to own file batctl: Move multicast_mode setting to own file batctl: Move network_coding setting to own file batctl: Move orig_interval setting to own file batctl: Use external netlink socket for debug tables batctl: Add command to monitor for netlink events Makefile | 42 +- translate.h => aggregation.c | 15 +- ping.h => ap_isolation.c | 15 +- backbonetable.c | 125 ++++ bisect_iv.c | 6 +- bisect_iv.h | 4 - traceroute.h => bonding.c | 15 +- bridge_loop_avoidance.c | 33 + claimtable.c | 130 ++++ dat_cache.c | 146 ++++ debug.c | 203 +----- debug.h | 37 +- distributed_arp_table.c | 33 + event.c | 246 +++++++ fragmentation.c | 33 + functions.c | 18 +- gateways.c | 174 +++++ gw_mode.c | 171 +++++ interface.c | 23 +- ioctl.h | 28 - isolation_mark.c | 35 + log.c | 73 ++ loglevel.c | 147 ++++ main.c | 274 ++++---- main.h | 65 +- man/batctl.8 | 4 + mcast_flags.c | 179 +++++ multicast_mode.c | 33 + interface.h => nc_nodes.c | 14 +- neighbors.c | 141 ++++ netlink.c | 1138 +++---------------------------- netlink.h | 49 +- network_coding.c | 33 + originators.c | 226 ++++++ ping.c | 10 +- routing_algo.c | 130 ++++ ioctl.c => statistics.c | 10 +- sys.c | 432 +----------- sys.h | 39 +- tcpdump.c | 5 +- tcpdump.h | 2 - tp_meter.c => throughputmeter.c | 10 +- tp_meter.h | 28 - traceroute.c | 10 +- transglobal.c | 160 +++++ translate.c | 8 +- translocal.c | 156 +++++ 47 files changed, 2895 insertions(+), 2013 deletions(-) rename translate.h => aggregation.c (67%) rename ping.h => ap_isolation.c (67%) create mode 100644 backbonetable.c rename traceroute.h => bonding.c (68%) create mode 100644 bridge_loop_avoidance.c create mode 100644 claimtable.c create mode 100644 dat_cache.c create mode 100644 distributed_arp_table.c create mode 100644 event.c create mode 100644 fragmentation.c create mode 100644 gateways.c create mode 100644 gw_mode.c delete mode 100644 ioctl.h create mode 100644 isolation_mark.c create mode 100644 log.c create mode 100644 loglevel.c create mode 100644 mcast_flags.c create mode 100644 multicast_mode.c rename interface.h => nc_nodes.c (73%) create mode 100644 neighbors.c create mode 100644 network_coding.c create mode 100644 originators.c create mode 100644 routing_algo.c rename ioctl.c => statistics.c (90%) rename tp_meter.c => throughputmeter.c (97%) delete mode 100644 tp_meter.h create mode 100644 transglobal.c create mode 100644 translocal.c -- 2.19.1

1 40

[B.A.T.M.A.N.] [PATCH 0/5] batman-adv: Tracing and debugfs deprecation cleanups
by Sven Eckelmann 21 Oct '18

21 Oct '18

Hi, the current master branch already contains support to store debug messages to the tracing buffer and to inform users about the deprecation of the debugfs functionality. This patchset is now cleaning it up a little bit more and allows to the tracing infrastructure completely without BATMAN_ADV_DEBUGFS. Kind regards, Sven Sven Eckelmann (5): batman-adv: Drop unused lockdep include batman-adv: Add includes for deprecation warning batman-adv: Improve includes for trace functionality batman-adv: Allow to use BATMAN_ADV_DEBUG without BATMAN_ADV_DEBUGFS batman-adv: Fix description for BATMAN_ADV_DEBUG compat.h | 5 ---- net/batman-adv/Kconfig | 7 +++-- net/batman-adv/bat_iv_ogm.c | 1 - net/batman-adv/debugfs.c | 2 ++ net/batman-adv/log.c | 60 ++++++++++++++++++++----------------- net/batman-adv/trace.c | 2 -- net/batman-adv/trace.h | 6 ++++ 7 files changed, 45 insertions(+), 38 deletions(-) -- 2.19.1

1 5

[B.A.T.M.A.N.] B.A.T.M.A.N. port to ESP32
by John Gorkos 20 Oct '18

20 Oct '18

I'm working on a port of the BATMAN-ADV protocol to FreeRTOS, specifically running on the ESP32 from EspressIF. I'm currently sending and receiving what seem to be correctly formed OGM messages from BATMAN IV. For now, my goal is interoperability with Raspberry Pis running BATMAN from stock Raspbian. >From the RasPi, I am able to see the ESP32 as a neighbor, but not as an originator: pi@pi-16:~ $ sudo batctl n [B.A.T.M.A.N. adv 2017.3, MainIF/MAC: wlan0/b8:27:eb:a0:2a:53 (bat0/e6:46:65:5b:c4:c4 BATMAN_IV)] IF Neighbor last-seen wlan0 30:ae:a4:3b:9a:d4 0.090s pi@pi-16:~ $ sudo batctl o [B.A.T.M.A.N. adv 2017.3, MainIF/MAC: wlan0/b8:27:eb:a0:2a:53 (bat0/e6:46:65:5b:c4:c4 BATMAN_IV)] Originator last-seen (#/255) Nexthop [outgoingIF] Can someone explain to me why this might be occurring, and what I'm missing? Currently, the code is doing two things: sending a new OGM with an incrementing sequence number every 1000 ms, and re-broadcasting any received OGMs with a decremented TTL, modified TQ, and DirectLink flag set whenever it receives them (also every 1000 ms or so). Internally, I'm getting close to having the routing algorithm implemented, but it looks like I'm doing something "wrong" in the eyes of the BATMAN implementation on the Pis. I'd be happy to provide packet dumps on request. Thank you in advance. John Gorkos

3 4

[B.A.T.M.A.N.] BLA and gateway mode
by Марк Коренберг 16 Oct '18

16 Oct '18

Hello, guys. Does anybody know if BLA is somehow connected with gateway mode ? In short, I'm unsure if gateway mode algorythms influence only DHCP traffic. It is not strictly said. Documentation about BLA II use term "gateway". As afr as I understand, there maybe case when BLA gateway is one node, and DHCP gateway is another one. So, the question: does GW functionality influence BLA algorythms ?

4 5

[B.A.T.M.A.N.] Blacklisting specific nodes for traffic routing
by Jake.Harris＠zf.com 15 Oct '18

15 Oct '18

I'm working with a group of about 50 nodes, 40 of which are physically stationary and 10 are mobile. The area is about three football fields with all the nodes evenly distributed while the 10 move around throughout the whole area (specifically there is one on each machine in the factory and one on each fork truck) with all of the fork truck nodes powered off the network is rock solid, but when they are powered up the network becomes flaky with different machine nodes loosing connection. My assumption is the machines notice a fork truck nearby and route their traffic through it as would make sense from their algorithm, but when the hilo goes out of range they seem to not notice and packets sent to the out of range nodes are lost. I looked all over the documentation and haven't found a way to specify which nodes to not allow routes to be built through. The obvious solution is to have the fork trucks connect to the network as clients, but as I'm using raspberry pis (3 b+ specifically) they only have one wireless adapter, and adding a second adapter to each machine is financially infeasible. I was unable to simply connect to the network and send messages, understandably since the batman system uses specific packets to communicate. The two solutions I can think of is to find a way to blacklist the mobile nodes to prevent them becoming hops in the network, or manually create the communication packets on the mobile nodes to send and receive messages while ignoring any route creation messages to likewise prevent them becoming hops. Is there an official way of doing either of these? Thanks, Jake

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N