B.A.T.M.A.N June 2011

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

14 participants
44 discussions

[B.A.T.M.A.N.] previous tangentially related broadcast issue -- info on MAC80211
by David Beberman 23 Jun '11

23 Jun '11

This is probably well understood by the engineers working on the Linux Wireless layer and those on the batman-adv project. I'm just a user trying to figure out what the best use of the protocol is for my application. This is a follow up explanation for the behavior I have been seeing. I walked through the MAC80211 layer. There are rate control algorithms that are loaded as modules. Currently there seems to be two of them, but more can be registered. Each of these appears to check individually for multicast and broadcast packets. Each broadcast packet uses the lowest basic rate available. The multicast packets use a basic rate from the BSSBasicRateSet that can be user defined. I believe, but have not verified, that batman-adv uses the broadcast address (FF:FF:FF:FF:FF:FF) for broadcast and multicast packets. The MAC80211 layer then uses the lowest basic rate available, which in my case, with a mixed b/g/n is 1 Mbps. For what I am trying to do, this is a problem. However, I would not call this a problem with batman-adv or MAC80211 in general. I can obviously do a hack for my own uses that looks into the packet in the MAC80211 layer to determine if it is a batman-adv broadcast packet and use a different rate. Maybe I can change batman-adv to use a multicast MAC address and pick up the fixed multicast rate that I can configure in MAC80211. None of this should be a general change for either module. Also, last time I looked through the batman-adv code, it did not have a multicast implementation from what I could tell. Seemed like multicast was mapped onto a general broadcast approach. Since my application requires all nodes to send to all other nodes in the system (full mesh), it seemed like broadcast was the best solution, and the docs I read said the same thing. Just thought I'd post a follow up on the broadcast data rate issue in case anybody reads through an archive on this, and wanted to see any resolution to the questions. Also, I saw a question about whether I had turned on aggregation when I increased the OGM rate from 1000 to 100 msecs. Apologies, but I do not remember. I believe I tried it both ways. I was hoping for a decision to go to a multi-hop route would occur faster with a higher OGM rate, when I was using unicast UDP traffic, and my nodes were moving apart. Instead, I found that the decision to go to multi-hop route appeared to take longer. Could easily have been configuration and user error on my part. I was using the batctl ping with the routing flag to see what the route to look at the behavior. Regards, David Beberman

1 0

[B.A.T.M.A.N.] One step back
by Sven Eckelmann 22 Jun '11

22 Jun '11

Hi, after the last mail of David S. Miller, it was more than clear that I am not the right person to speak on behalf of the batman-adv community. I have the same opinion about the always changing protocol as he does. I first struggled with it after getting the batman dissector merged in wireshark, but it is confronting everyone since the merge into the linux kernel began. Andrew already told us that we would need to get some kind of stable on the wire format and some kind of backward compatibility, but it doesn't look like we get there soon. I don't know who currently follows which vision, but I know that all those ideas make the protocol incompatible with the versions before (and this will happen again and again and again ...). I don't have answers how it can be done differently and still the current problems can be solved. That means, I can neither represent the position of the ongoing protocol developments nor the position of the backward compatibility. So, I doubt that I can present the changes to David S. Miller any longer when I am sure that he doesn't like the patches for the same reasons I don't like them. It is better that I don't stand in the way as "grumbling old man" [2] and make the position free for someone who can really speak on behalf of the current active developers of batman-adv. So the first thing I did was a big cleanup. Most of my git repositories are gone now: * ecsv/batctl-rebase / ecsv/master-rebase The development was changed to git some time ago. This makes those repository relatively useless when the development is done in the current branch structure. This means that next gets bugfixes/cleanups which still can be merged by David and then the branch is merged into master instead of cherry picking patches around. After a release the next branch (or better the tag of the release) has to be merged into master (without changing the SOURCE_VERSION in main.h to something else than "devel"), then the next branch merges the master branch and the new development cycle is started in next. * ecsv/debian/batctl ecsv/debian/batmand Those are only backups. I already have backups in different places - so no need to store them again on open-mesh * ecsv/viking That was a private repository - nobody seems to have noticed it. I doubt that those maintainers will merge it soon and I will probably just send them the patches over ml instead of doing a pull request again. * ecsv/git-conversation-svn Project to convert the open-mesh svn to smaller git repositories. Seems to have worked, but is now useless * ecsv/hash_regression Just to show that the hash regression was actually a regression in Linus code. Funny but useless :) * ecsv/post-commit-daemon A daemon which started svn hooks at a later point. Those build scripts on open-mesh were gruel, but I think that we killed them. This makes the script useless for us * ecsv/wireshark-batman-adv ecsv/wireshark-batman Both dissectors are merged in wireshark... somewhat. At least parts of v12/13 are now supported and it was now noticed that the v14 patches cannot be applied out of order... but I am full of hope that the patches will be enter the wireshark svn sometime in the future ("where no man has gone before..."). But is not necessary to have the plugins in an external module. It can't be build against an older version of wireshark and new version of wireshark can't load it due to the conflicting names. * ecsv/linux-merge Ok, this one is not really gone - it just can be found under marek/linux-merge. Maybe it will change the place again. There are also some scripts which run on daily basis and are a little bit more verbose. * /home/batman/linux-next-check/sync-git It downloads the linux-next tree, Linus tree and pushes parts of the changes to linux-merge.git - this should be quite silent. But the ./hooks/manual-hook in /home/batman/linux-next-check/linux-next.git/ is triggered and sends mails about changes in net/batman-adv, Documentation/networking/batman-adv.txt, Documentation/ABI/testing/sysfs-class-net-batman-adv and Documentation/ABI/testing/sysfs-class-net-mesh to the unhappy person mentioned in /home/batman/linux-next-check/linux-next.git/config (currently Marek and Simon) * /home/batman/packet.h_check/check.sh This one just send the difference of packet.h in all branches in batctl and batman-adv to the responsible persons (see the TO="..." at the beginning of the file) * /home/batman/build_test/checkstuff.sh This is more or less the build monster. It builds against kernel 2.6.21 till 2.6.39. I know that it will not work directly against 3.0, but it is no big change to fix it. It uses sparse, checkpatch.pl from linux-next and the minimized kernel sources generated through make_all.sh (of course, this one also doesn't know about 3.0) Marek and Simon will see the rcu warnings every morning till Andrew Morton forward my rcu checkpatch patch or it appears through other channels in linux-next. The rest should be explained on wiki pages, /srv/git/README or some private mails. Kind regards, Sven [1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2011-June/005020.html [2] http://upload.wikimedia.org/wikipedia/en/8/8b/StatlerAndWaldorf.jpg

3 3

[B.A.T.M.A.N.] iperf in 3 node batman-adv network
by Max IP 21 Jun '11

21 Jun '11

Hi all, I am implementing the 3 node batman-adv network. A <---> B <---> C B is the relay point for communication between A and C. I have setup the batman-adv 2011.1.0 in all nodes and succesfully I can communicate and also use avahi between all nodes. Now I want to calculate bandwidth, jitter and throughput patterns. To calculate bandwidth, I used iperf -s on machine A. On machine B, I used iperf -C <ip address of A> This gave me a bandwidth of 89.1 Mbits/sec On machine C, I used iperf -c <ip address of A> This gave me a bandwith of 89.0 Mbits/sec Since, there is relay through B to reach C, I was expecting the bandwith from A to C to be less around half (say 50 Mbits/sec). Is my understanding correct? Please help me. Max

2 1

[B.A.T.M.A.N.] pull request: batman-adv 2011-06-20
by Sven Eckelmann 20 Jun '11

20 Jun '11

Hi, I would like to propose following changes for net-next-2.6/3.1. The first part (1-4) are only only small cleanup patches. The last 8 patches are related to Antonio Quartulli's research "Client announcement and Fast roaming in a Layer-2 mesh network". The technical report isn't published yet, but will hopefully follow soon. He tried to document all important parts in some (unofficial) documents [1,2,3]. thanks, Sven [1] http://www.open-mesh.org/wiki/batman-adv/Client-announcement [2] http://www.open-mesh.org/wiki/batman-adv/Client-roaming [3] http://www.open-mesh.org/wiki/batman-adv/Uevent The following changes since commit ecbd532108cb21d9d3770f73e168bad65d14d9eb: batman-adv: use NO_FLAGS define instead of hard-coding 0 (2011-06-09 20:40:38 +0200) are available in the git repository at: git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/next Antonio Quartulli (8): batman-adv: Unify the first 3 bytes in each packet batman-adv: improved client announcement mechanism batman-adv: improved roaming mechanism batman-adv: protect the local and the global trans-tables with rcu batman-adv: add wrapper function to throw uevent in userspace batman-adv: gateway election code refactoring batman-adv: throw uevent in userspace on gateway add/change/del event batman-adv: improved gateway tq-based selection David Howells (1): batman-adv: count_real_packets() in batman-adv assumes char is signed Sven Eckelmann (3): batman-adv: Move compare_orig to originator.c batman-adv: Keep interface_tx as local function batman-adv: Reduce usage of char net/batman-adv/Kconfig | 1 + net/batman-adv/aggregation.c | 25 +- net/batman-adv/aggregation.h | 8 +- net/batman-adv/bat_sysfs.c | 73 ++- net/batman-adv/bat_sysfs.h | 2 + net/batman-adv/bitarray.c | 8 +- net/batman-adv/bitarray.h | 8 +- net/batman-adv/gateway_client.c | 238 +++++-- net/batman-adv/gateway_client.h | 3 +- net/batman-adv/gateway_common.c | 6 +- net/batman-adv/hard-interface.c | 17 +- net/batman-adv/main.c | 18 +- net/batman-adv/main.h | 27 +- net/batman-adv/originator.c | 17 +- net/batman-adv/originator.h | 8 - net/batman-adv/packet.h | 92 ++- net/batman-adv/routing.c | 317 +++++++-- net/batman-adv/routing.h | 7 +- net/batman-adv/send.c | 92 ++- net/batman-adv/send.h | 2 +- net/batman-adv/soft-interface.c | 26 +- net/batman-adv/soft-interface.h | 1 - net/batman-adv/translation-table.c | 1428 ++++++++++++++++++++++++++++++------ net/batman-adv/translation-table.h | 38 +- net/batman-adv/types.h | 64 ++- net/batman-adv/unicast.c | 3 + net/batman-adv/vis.c | 13 +- 27 files changed, 2080 insertions(+), 462 deletions(-)

2 13

[B.A.T.M.A.N.] [PATCH] batman-adv: Avoid TQ monotonicity violation that can cause loops
by Daniele Furlan 20 Jun '11

20 Jun '11

This patch avoids the broadcast of TQ greater than the average TQ of the current best neighbour. This behaviour could cause loops due to the violation of routing metric monotonicity property. The TQ value for non-received OGM is not set to 0, instead it is set to the average TQ calculated on the global TQ window using 0 as last TQ only for computation. Signed-off-by: Daniele Furlan <daniele.furlan(a)gmail.com> --- routing.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/routing.c b/routing.c index 0ce090c..1487bd3 100644 --- a/routing.c +++ b/routing.c @@ -408,8 +408,14 @@ static void update_orig(struct bat_priv *bat_priv, struct orig_node *orig_node, continue; spin_lock_bh(&tmp_neigh_node->tq_lock); + /* set last tq to 0 only for computing average */ ring_buffer_set(tmp_neigh_node->tq_recv, &tmp_neigh_node->tq_index, 0); + /* set last tq to tq_global_window avg */ + ring_buffer_set(tmp_neigh_node->tq_recv, + &tmp_neigh_node->tq_index, + ring_buffer_avg(tmp_neigh_node->tq_recv)); + /* update tq_avg for this neighbour */ tmp_neigh_node->tq_avg = ring_buffer_avg(tmp_neigh_node->tq_recv); spin_unlock_bh(&tmp_neigh_node->tq_lock); -- 1.7.1

1 0

[B.A.T.M.A.N.] Vis server
by wayne abroue 20 Jun '11

20 Jun '11

Hi All I'm trying to interogate vis on a bat-adv server node, Can anybody point me in the right direction, It's for use with this http://villagetelco.org/2011/06/spud-simple-unified-dashboard-for-mesh-netw… It works with batman, but not with bat-adv. Wayne On 17 June 2011 20:54, wayne abroue <plettpc(a)gmail.com> wrote: > Hi All > > I am trying out spud, looks very good, I'm just needing some info , > google fu is not up to it I'm afraid. > The php scrip interrogates a vis server, I do not have Afrimesh setup, You do need a VIS server but Afrimesh is not required to make Spud work. > Vis is running on my bat-adv network, Gateway node set as vis server > on node and it's accepting info from rest of the network. We haven't actually tried Spud with the batman-adv VIS server so we'd need to check that it was giving the same output as the batman VIS server. > However, It seems I need a external vis server for the script to > interrogate. Or is there a way to interrogate the vis server node from > this machine? In theory, as long as you can see the IP address of the node running the VIS server, that should be sufficient. It may be an incompatibility with the batman-adv VIS output. Cheers... Steve > > Wayne

3 4

[B.A.T.M.A.N.] batman-adv 2011.2.0 released
by Marek Lindner 19 Jun '11

19 Jun '11

The B.A.T.M.A.N. team is publishing its latest edition, 2011.2.0, primarily focusing on bug fixes and compatibility plus some smaller features. 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.org/batman/releases/batman-adv-2011.2.0/ as well as prepackaged binaries in your distribution. Important changes ----------------- A series of patches has been merged that replaces all occurrences of 'HNA' by 'TT' (standing for 'translation table'). Originally, batman-adv inherited the term 'HNA' from our layer 3 implementation which caused some confusion as people expected it to behave in the same way. The new name is meant to outline the difference. Scripts / tools expecting the string 'HNA' in the debugfs / batctl output need to be adjusted. This renaming is the first step in a number of changes regarding the client announcement mechanisms. Expect more to come with the following releases. Thanks ------ Thanks to all people sending in patches: * Andrew Lunn <andrew(a)lunn.ch> * Antonio Quartulli <ordex(a)autistici.org> * Daniele Furlan <daniele.furlan(a)gmail.com> * David Decotigny <decot(a)google.com> * Linus Lüssing <linus.luessing(a)web.de> * Lucas De Marchi <lucas.demarchi(a)profusion.mobi> * Marek Lindner <lindner_marek(a)yahoo.de> * Michał Mirosław <mirq-linux(a)rere.qmqm.pl> * Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> * Simon Wunderlich <siwu(a)hrz.tu-chemnitz.de> * Sven Eckelmann <sven(a)narfation.org> * Sylvestre Ledru <sylvestre.ledru(a)scilab.org> batman-adv ---------- In the aftermath of the orig hash lock removal released with 2011.1.0, batman- adv underwent a stabilization phase in which fixing bugs was the highest priority. Unsurprisingly, the transition to fine grained locking required further attention such as properly protecting data structures with rcu locks. During the debugging phase race conditions were fixed, duplicate code removed, memory leaks eliminated and reference counting imbalances addressed. The backward compatibility with older kernel versions as well as the support of upcoming kernel releases has been thoroughly tested and improved. The local and global translation table output is reflecting the HNA to TT conversion. Adding support for multiple vlan ids to the bridge loop avoidance code is the only noticeable new feature coming with this release. batctl ------ The batctl tool also has been affected by the renaming: the vis data option '--no-HNA|-H' has been renamed to '--no-TT|-T' and the vis data output prints 'label=TT' instead of 'label=HNA'. To be compliant with the JSON Schema the JSON vis data output has been slightly modified. Happy routing, The B.A.T.M.A.N. team

1 0

[B.A.T.M.A.N.] [PATCH] batman-adv: fix cleanup in send_tt_request()
by Marek Lindner 17 Jun '11

17 Jun '11

The ret variable was never set to any value other than 0, therefore the skb and tt_req_node would not be freed in case of an error. Furthermore, the code assumed tt_req_node being always a valid pointer by dereferencing it in the cleanup part. Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de> --- translation-table.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/translation-table.c b/translation-table.c index 373ee81..5f1fcd5 100644 --- a/translation-table.c +++ b/translation-table.c @@ -1012,12 +1012,12 @@ out: int send_tt_request(struct bat_priv *bat_priv, struct orig_node *dst_orig_node, uint8_t ttvn, uint16_t tt_crc, bool full_table) { - struct sk_buff *skb; + struct sk_buff *skb = NULL; struct tt_query_packet *tt_request; struct neigh_node *neigh_node = NULL; struct hard_iface *primary_if; - struct tt_req_node *tt_req_node; - int ret = 0; + struct tt_req_node *tt_req_node = NULL; + int ret = 1; primary_if = primary_if_get_selected(bat_priv); if (!primary_if) @@ -1066,8 +1066,9 @@ out: neigh_node_free_ref(neigh_node); if (primary_if) hardif_free_ref(primary_if); - if (ret) { + if (ret) kfree_skb(skb); + if (ret && tt_req_node) { spin_lock_bh(&bat_priv->tt_req_list_lock); list_del(&tt_req_node->list); spin_unlock_bh(&bat_priv->tt_req_list_lock); -- 1.7.5.3

2 2

[B.A.T.M.A.N.] tangentially driver related question on broadcasts with batman-adv
by David Beberman 16 Jun '11

16 Jun '11

Hi, I'm using batman-adv in two different ways. The first is what it is meant for, mesh routing. Apologies if that is not the correct technical term. The second way I'm using it is to take advantage of broadcasting as a simply floodfill algorithm. All of my nodes transmit to all other nodes on a periodic basis. This is an IPv6 local multicast. I believe this translates to 802.11 MAC FF:FF:FF:FF:FF:FF broadcast address, and everything works. What I noticed with a network sniffer is that all of the broadcasts were sent with 1 Mbps data rate. For some of my systems, I was able to force the rate to a fixed value: iwconfig wlan0 rate 5.5M for example. For other systems, the command is accepted but the broadcast rate stays at 1Mbps. The systems that show this are laptops running Intel iwlagn drivers, as well as external USB Linksys (USB600N) devices with Ralink drivers. I tried both the ubuntu kernel 2.6.32-29-generic and also upgraded it to 2.6.39 downloaded directly from kernel.org. I thought that perhaps the ad-hoc fixed rate behavior might not be implemented in the mac80211/cfg80211 in the earlier kernel versions. I'm running the batman-adv 2011.1.0 release. What I would really want is some way to flood packets to all of my nodes from all of my nodes on a periodic basis. That is, this is a full mesh connection situation. I would somehow like to still take advantage of higher data rates when nodes are closer to each other. Unfortunately, broadcasts do not have full CSMA/CA, only CSMA, so no feedback to do data rate management (I think). Does anyone have experience with using the wireless extensions (iwconfig, wpa_supplicant, wpa_cli, etc.), or the newer "iw" commands to get broadcasts to occur at different data rates in ad-hoc mode? Also: I have tried using unicast packets one for each connected pair and let the batman-adv next-hop routing forward the packets. This does work in a reasonably stable system. The problem is that my nodes have a fairly short data transmit period on the order of 1 second. The nodes are moving around relative to each other also on the order of a few seconds. The routing resolution based on link quality works on the order of 30+ seconds. Thus there can be loss of traffic for a significant period relative to 1 second periods. I did up the OGM rate, 100 msec and even 10 msec just to experiment. This actually seemed to reduce the next-hop decisions, based on the batctl ping results. >From what I can tell reading the algorithms written in the documentation, all next hop decisions are based on link quality. Link quality using roundtrip metrics of broadcast packets. Broadcast packets are transmitted at 1Mbps in my systems, thus the link quality for 2 nodes at a distance that uses 1 Mbps data rate is the same as the link quality for 2 nodes that could use much higher data rates. Since my objective is to deliver the same packet from each source node to all other nodes, using next-hop routing, I end up with my data rates dropping to the minimum to reach the maximum operational distance nodes, even if there are a bunch of nodes in between. When I broadcast, the data rate stays constant and as long as a node can hear at least one other node, it gets all the periodic data from all other nodes. If this makes sense to someone, or I'm missing something obvious, please feel free to clue me in. My next step is to getting into the transmit control flow in the WLAN device drivers for each piece of hardware and see if I can hard code the transmit data rate for broadcast packets. Usually there is a control header for each transmit frame sent to the hardware/firmware. Finding it, and understanding it without documentation is a challenge I've been hoping to avoid. Any help would be appreciated. The only help I can offer in return is that I figured out how to change the operating channel on the Broadcom bcm4329 driver for the HTC Desire in ad-hoc mode. There are a couple of minor errors in the wireless extension handling code. Someone might find that useful. Regards, David Beberman

4 4

[B.A.T.M.A.N.] [PATCH] batman-adv: skbs have to be freed using kfree_skb()
by Antonio Quartulli 16 Jun '11

16 Jun '11

The skb structures have always to be freed using kfree_skb() and not the simple kfree() Signed-off-by: Antonio Quartulli <ordex(a)autistici.org> --- routing.c | 2 +- translation-table.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/routing.c b/routing.c index 30d0f73..41d065e 100644 --- a/routing.c +++ b/routing.c @@ -1299,7 +1299,7 @@ int recv_roam_adv(struct sk_buff *skb, struct hard_iface *recv_if) orig_node_free_ref(orig_node); ret = NET_RX_SUCCESS; out: - kfree(skb); + kfree_skb(skb); return ret; } diff --git a/translation-table.c b/translation-table.c index adecf1b..373ee81 100644 --- a/translation-table.c +++ b/translation-table.c @@ -1199,7 +1199,7 @@ out: if (primary_if) hardif_free_ref(primary_if); if (!ret) - kfree(skb); + kfree_skb(skb); return ret; } @@ -1312,7 +1312,7 @@ out: if (primary_if) hardif_free_ref(primary_if); if (!ret) - kfree(skb); + kfree_skb(skb); /* This packet was for me, so it doesn't need to be re-routed */ return true; } -- 1.7.3.4

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N June 2011