B.A.T.M.A.N March 2010

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

13 participants
22 discussions

[B.A.T.M.A.N.] [PATCH 0/3] Staging: Batman-adv: Bug fixes for 2.6.34-rc2.
by Andrew Lunn 30 Apr '10

30 Apr '10

Hi Greg Here are three patches against 2.6.34-rc2 which we would like including into the next -rc kernel. All three are bug fixes, with the first being a regression relative to 2.6.33 and the second two being older bugs, prescent in 2.6.33. Thanks Andrew Andrew Lunn (1): Staging: batman-adv: don't have interrupts disabled while sending. Linus Luessing (1): Staging: batman-adv: Fix VIS output bug for secondary interfaces Linus Lüssing (1): Staging: batman-adv: Fixing wrap-around bug in vis drivers/staging/batman-adv/proc.c | 51 ++++++--- drivers/staging/batman-adv/vis.c | 235 +++++++++++++++++++++++++------------ drivers/staging/batman-adv/vis.h | 8 +- 3 files changed, 202 insertions(+), 92 deletions(-)

2 6

[B.A.T.M.A.N.] reorganized kernel interface patches (version 3)
by Marek Lindner 05 Apr '10

05 Apr '10

Hi, since my last patches did not trigger too many complaints I went ahead and submitted them. This opens the way for the last series of patches which conclude the matter. All remaining /proc files have been eliminated and moved over to /sys. While doing so, I reworked the interface handling to satisfy an old feature request: interfaces can be added & removed on the fly. On startup batman-adv will scan the system for available interfaces to create a "batman_adv" subfolder in their respective /sys/class/net folder, e.g. eth0: /sys/class/net/eth0/batman_adv This subfolder will contain the settings which are relevant for this interface. You can tell batman-adv to use an interface by writing "bat0" into the mesh_iface file: echo bat0 > /sys/class/net/eth0/batman_adv/mesh_iface or write "none" to deactivate it: echo none > /sys/class/net/eth0/batman_adv/mesh_iface Although only "bat0" is accepted at this point, the syntax already gears towards multiple virtual mesh support. Later you will be able to create/name your virtual meshes by writing into this file. Retrieve the interface status by simply reading its status file: cat /sys/class/net/eth0/batman_adv/iface_status Note: batman-adv will continuously observe the system's interfaces. Whenever new interfaces appear or disappear batman will update the /sys/class/net folders automatically. Also, batman-adv will make sure that incompatible interfaces (e.g. loopback, non-ethernet, etc) won't have the subfolder, hence can't be activated. The batctl interface syntax had to be modified in order to cope with these changes. You can run: batctl interface to get the list of active interfaces and their status. To add or delete interfaces you can run: batctl interface add|del eth0 eth1 .. Since removing an active interface is a tricky thing where many operations can go wrong I expect some crashes/race conditions in the code. I tested it a while on multiple machines with multiple interfaces and it works for me but I'm sure there are more bugs to find. Regards, Marek

2 8

[B.A.T.M.A.N.] Minor change in vis.c
by Nathan Wharton 04 Apr '10

04 Apr '10

With the emphasis on minor. Could: printf("\"%s\" [label=\"%d.%d\"]\n", be: printf("\"%s\" [label=\"%d.%02d\"]\n", instead?

4 5

[B.A.T.M.A.N.] batman-adv 0.2.1 released
by Marek Lindner 22 Mar '10

22 Mar '10

The B.A.T.M.A.N. team hereby announces the release of the first bugfix milestone for the batman-adv 0.2 branch which focuses on stability but also brings improvements and small changes. As the kernel module always depends on the Linux kernel it was compiled against, it does not make sense to provide binaries on our website. As usual, you will find the signed tarballs in our download section: http://downloads.open-mesh.net/batman/releases/batman-adv-0.2.1/ as well as prepackaged binaries in your distribution. Important changes ---------------- The batman-adv logging facilities underwent structural changes to fully integrate into the standard Linux logging mechanisms. Please study the README to get further details on how to access the debug logs. In addition, the "vis" /proc file has been split up into two files: vis_server and vis_data. The vis_server controls the vis server status whereas the vis_data file exports the visualization "raw" data which can be easily parsed by user space tools. Again, details can be found in our documentation. Thanks ---------------- Special thanks go to: * Andrew Lunn for going through the entire code base to refactor the code and adjust the coding style to match standard Linux coding style guidelines * Linus Luessing for his restless testing in so many scenarios and sending a lot of patches and suggestions. Thanks to all people sending in patches: * Andrew Lunn <andrew(a)lunn.ch> * Julia Lawall <julia(a)diku.dk> * Linus Luessing <linus.luessing(a)web.de> * Marek Lindner <lindner_marek(a)yahoo.de> * Simon Wunderlich <siwu(a)hrz.tu-chemnitz.de> * Sven Eckelmann <sven.eckelmann(a)gmx.de> * Sven-Thorsten Dietrich <sdietrich(a)novell.com> batman-adv ---------------- Albeit being a bugfix release we dared to include some bigger changes because we felt their gain outweighs the risk. For instance, we replaced the packet handling thread which was responsible for routing the payload data through the mesh by an advanced skbuff handling technique. Now, packets are received directly by registering the Ethernet type and handling skbs instead of self- allocated buffers which boosts the performance considerably and reduces latency. On the other hand batman-adv is moving towards full Linux kernel integration which requires some significant changes under the hood as well as on the surface. Batman's own logging facility has been removed (the standard Linux logging is used instead). The vis output comes now in a neutral format, easily parsable by user space applications. Since the module entered the official Linux realm several people threw static code analyzers (e.g. Coccinelle, sparse) onto the code to find bugs. Some (possible) memory leaks, optimizations and a false alarms have been found and dealt with. Many more bugs, race conditions and crashes have been fixed. Now, it also is possible to change the MAC address on bat0. batctl ---------------- Since the vis output format has changed, batctl received a parser for the neutral format to convert the output into either dot draw or JSON. If you wish to write your own parser, please see our documentation and/or the batctl code as an example. The batman-adv debug log will show up in the standard kernel logs of your system, hence to access the logs "batctl log" is not needed any longer. Please use the tools provided by your distribution (dmesg/logread/syslog/etc). However, "batctl log" remains available and can be used to filter existing logfiles for batman-adv output and to replace the mac addresses by bat-host names. Happy routing, The B.A.T.M.A.N. team

1 0

[B.A.T.M.A.N.] [PATCH] batman-adv: Update README about vis raw output
by Linus Lüssing 21 Mar '10

21 Mar '10

We are now having a newer, more neutral vis output so that we won't have to change the kernelmodule for adding support of new vis output formats. This patch adds an explanation about this in the README file of batman-adv and removes the description about the dot/json format (they will be added to the README of batctl). Signed-off-by: Linus Lüssing <linus.luessing(a)web.de> --- README | 43 ++++++++++++++++++++++++++++--------------- 1 files changed, 28 insertions(+), 15 deletions(-) diff --git a/README b/README index df21c61..2058a13 100644 --- a/README +++ b/README @@ -1,4 +1,4 @@ -[state: 01-01-2010] +[state: 21-03-2010] BATMAN-ADV ---------- @@ -57,10 +57,11 @@ regular interface: # ping 192.168.0.2 ... +--- If you want topology visualization, your meshnode must be configured as VIS-server: -# echo "server" > /proc/net/batman-adv/vis +# echo "server" > /proc/net/batman-adv/vis_server Each node is either configured as "server" or as "client" (default: "client"). Clients send their topology data to the server next to them, @@ -71,19 +72,31 @@ more vis servers sharing the same (or at least very similar) data. When configured as server, you can get a topology snapshot of your mesh: -# cat /proc/net/batman-adv/vis - -This output format is a graphviz formatted text file which can be -processed with graphviz-tools like dot. -The labels are similar/compatible to the ETX metric, 1.0 means perfect -connection (100%), 2.0 means 50%, 3.0 means 33% and so on. - -Alternatively, a JSON output format is available. The format can be set -using by writing either "dot_draw" or "json" into the vis_format file. -"dot_draw" is selected by default. - -echo "json" > /proc/net/batman-adv/vis_format - +# cat /proc/net/batman-adv/vis_data + +This raw output is intended to be easily parsable and convertable with +other tools. Have a look at the batctl README if you want a vis output +in dot or json format for instance and how those outputs could then be +visualised in an image. + +The raw format consists of comma seperated values per entry where each +entry is giving information about a certain source interface. Each entry +can/has to have the following values: +-> "mac" -> mac address of an originator's source interface + (each line begins with it) +-> "TQ mac value" -> src mac's link quality towards mac address of a neighbor + originator's interface which is being used for routing +-> "HNA mac" -> HNA announced by source mac +-> "PRIMARY" -> this is a primary interface +-> "SEC mac" -> secondary mac address of source (requires preceeding +-> PRIMARY) + +The TQ value has a range from 4 to 255 with 255 being the best. +The HNA entries are showing which hosts are connected to the mesh via bat0 +or being bridged into the mesh network. +The PRIMARY/SEC values are only applied on primary interfaces + +--- In very mobile scenarios, you might want to adjust the originator interval to a lower value. This will make the mesh more responsive to topology changes, but will also increase the overhead. Please make sure -- 1.7.0

1 1

[B.A.T.M.A.N.] batctl manpage adjustments
by Linus Lüssing 21 Mar '10

21 Mar '10

So here are the few modifications made to the batctl manpage. Cheers, Linus :)

1 1

[B.A.T.M.A.N.] [PATCH] batman-adv: Remove dead max addr #define
by Linus Lüssing 21 Mar '10

21 Mar '10

It's not being used anywhere and just misleading, therefore removing it. Signed-off-by: Linus Lüssing <linus.luessing(a)web.de> --- main.h | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/main.h b/main.h index 307a6e6..17d26be 100644 --- a/main.h +++ b/main.h @@ -34,8 +34,6 @@ #define TQ_MAX_VALUE 255 #define JITTER 20 #define TTL 50 /* Time To Live of broadcast messages */ -#define MAX_ADDR 16 /* number of interfaces which can be added to - * batman. */ #define PURGE_TIMEOUT 200000 /* purge originators after time in ms if no * valid packet comes in -> TODO: check -- 1.7.0

1 0

[B.A.T.M.A.N.] [PATCH 1/2] batman-adv: fix aggregation timing bug
by Linus Lüssing 20 Mar '10

20 Mar '10

From: Marek Lindner <lindner_marek(a)yahoo.de> batman-adv aggregates routing packets to reduce the number of packets in the air. Every outgoing packet is compared with other packets in the buffer to determine whether it can be aggregated or not. Packets sent at a lower interval can be held back longer to maximize the aggregation. Due to insufficient checking batman-adv held back all packets for a certain time depending on its own lowest interval rate which slowed down all other nodes. Reported-by: Linus Luessing <linus.luessing(a)web.de> Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de> --- aggregation.c | 12 ++++++++++++ send.c | 10 +--------- 2 files changed, 13 insertions(+), 9 deletions(-) diff --git a/batman-adv-kernelland/aggregation.c b/batman-adv-kernelland/aggregation.c index a829814..0635b5a 100644 --- a/batman-adv-kernelland/aggregation.c +++ b/batman-adv-kernelland/aggregation.c @@ -52,6 +52,8 @@ static bool can_aggregate_with(struct batman_packet *new_batman_packet, */ if (time_before(send_time, forw_packet->send_time) && + time_after_eq(send_time + msecs_to_jiffies(MAX_AGGREGATION_MS), + forw_packet->send_time) && (aggregated_bytes <= MAX_AGGREGATION_BYTES)) { /** @@ -196,6 +198,16 @@ void add_bat_packet_to_list(unsigned char *packet_buff, int packet_len, if (forw_packet_aggr == NULL) { /* the following section can run without the lock */ spin_unlock_irqrestore(&forw_bat_list_lock, flags); + + /** + * if we could not aggregate this packet with one of the others + * we hold it back for a while, so that it might be aggregated + * later on + */ + if ((!own_packet) && + (atomic_read(&bat_priv->aggregation_enabled))) + send_time += msecs_to_jiffies(MAX_AGGREGATION_MS); + new_aggregated_packet(packet_buff, packet_len, send_time, direct_link, if_incoming, own_packet); diff --git a/batman-adv-kernelland/send.c b/batman-adv-kernelland/send.c index 1c82f43..4320855 100644 --- a/batman-adv-kernelland/send.c +++ b/batman-adv-kernelland/send.c @@ -49,15 +49,7 @@ static unsigned long own_send_time(void) /* when do we schedule a forwarded packet to be sent */ static unsigned long forward_send_time(struct bat_priv *bat_priv) { - unsigned long send_time = jiffies; /* Starting now plus... */ - - if (atomic_read(&bat_priv->aggregation_enabled)) - send_time += (((MAX_AGGREGATION_MS - (JITTER/2) + - (random32() % JITTER)) * HZ) / 1000); - else - send_time += (((random32() % (JITTER/2)) * HZ) / 1000); - - return send_time; + return jiffies + (((random32() % (JITTER/2)) * HZ) / 1000); } /* send out an already prepared packet to the given address via the -- 1.7.0

2 3

[B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010
by Michael Fazio 16 Mar '10

16 Mar '10

Hello, My name is Michael. I am currently working on a large robotics project and I am thinking of using B.A.T.M.A.N to facilitate a MANET to communicate between a number of bots and a base station. I was hoping to get a bit of information regarding the suitability of B.A.T.M.A.N for such an application. Any information would be helpful (general or specific). Here are some of the details of our project. We will be using up-to 14 bots in our project (each must be network aware). The area that our bots will be operating in is approximately the size of a football field. There are both indoor and outdoor areas that must be navigated with a significant amount of obstacles. We will be using 802.11a,b,g and possibly n as well as one or more long range VHF links which I am hoping to setup as additional entry points to our bot network. We have various types of data to be communicated on our network including, GPS, basic telemetry, control message, imagery, UAV feeds, point cloud info etc. Some data such as GPS and telemetry is realtime and need not be reliable (we are considering simply UDP broadcasting this data). Other data such as imagery and control messages will require stable links and need to be relatively reliable. We are not yet sure if we will be deploying any specific middleware technology although I am partial to pub/sub middleware. Are there any such middleware that can complement B.A.T.M.A.N? I was hoping to know what type of issues I might run into using B.A.T.M.A.N adv in such a scenario. For instance, what kind of throughput might I expect in the described environment? Link stability issues? General suitability? How would B.A.T.M.A.N compare to OLSR or Babel? I am really interested in anything that anyone has to offer. The reason I am pushing for B.A.T.M.A.N is because of the ability for us to develop our application layer using IPv4 TCP/UDP on-top of a mesh network driven by routers running openWRT & B.A.T.M.A.N. I want to take as much network layer knowledge away from out application layer. Also, does anyone know of other similar usages of B.A.T.M.A.N? I have a bunch of studies from various organizations comparing B.A.T.M.A.N to other solutions but I would really appreciate to hear what the mail list users have to say about their own experiences with B.A.T.M.A.N. I hope this is the right place to be asking all these questions! Thanks Batmen & Batwomen! Michael

4 6

[B.A.T.M.A.N.] reorganized kernel interface patches [part II]
by Marek Lindner 15 Mar '10

15 Mar '10

Hi, since we have initial steps behind us it is time to move on. The following patches convert 4 files from /proc to /sys - nothing fancy here. Please give it a try and let me know what you think. Cheers, Marek

1 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N March 2010