B.A.T.M.A.N March 2012

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

22 participants
30 discussions

[B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
by dan 17 Jul '12

17 Jul '12

I have an interesting hardware setup I'd like to explore. Basically, I would like to take commodity ubiquiti and/or openmesh hardware and build a mesh with two different node types, some having just 1 radio and others having multiple radios, a standard node and a super node. the standard node is: a picostation flashed to openwrt running batman-adv and running the radio in Ad-Hoc mode. Alternately an OM2P flashed to openwrt. This is the basic client radio the super node is: a group of picostations or nanostations, flashed openwrt in adhoc mode, but acting only as the L2 transport with a router at the center running batman-adv. The idea is that the super nodes have multiple radios in multiple channels and can take advantage of link alternation allowing super nodes to keep much higher bandwidth between them while the standard nodes are cheap. The 'router' MIGHT also have a radio for client access (unifi station flashed to openwrt maybe, or an ALIX board) The supernode will have more CPU and also be the target of backhaul/shorthaul links to cut down on hop count. The main router would also be a batman-adv device, probably an x86 server, and would be the border router for the mesh. some questions, I know that the supernodes will have higher throughput capabilities due to dual mesh radios, but how will batman-adv know this or how would I tell it? Is the internal mechanism for determining the best path going to take this into account? Is there a way to identify a supernode as being a better path above and beyond the automatic batman-adv mechanisms? Is having separate radios connected to a batman-adv router going to behave how I presume? That multiple node2node connections will be identified and the links be alternated when appropriate? If the supernodes have 2 mesh radios, 1 in 5Ghz and 1 in 2.4Ghz, then the standard nodes will only be able to connect to the 2.4Ghz channel which might make it inappropriate to do link alternating on these two links because of the shared traffic. Should batman-adv automatically stop alternating the tx/rx on these links when one of the channels starts to get saturated? some other info: the supernodes may have a link directly to the main distribution point, but may also be linked just to another supernode and not to the main distribution point, or possibly both. the supernodes are likely to have more than 2 mesh radios as some of these could be direction antennas. A supernode might have 3x 2.4Ghz radios for mesh, 2x 5Ghz radios for mesh, and a 2.4Ghz radio for non-mesh clients. These would most likely all be connected to a switch port and only be on a single ethernet interface as far as batman-adv is concerned.

6 16

[B.A.T.M.A.N.] [RFC] ELP
by Marek Lindner 06 Apr '12

06 Apr '12

Hi, after numerous infrastructure changes in the past weeks ELP[1] slowly approaches the state in which it can be tested and later merged into the master branch. Since its initial implementation by Linus Luessing last summer a lot has happened: * the internal protocol name (NDP) was renamed to ELP * the old code was rebased on top of the master branch * the ELP code was adjusted to the many changes in our code base * several patches were squashed together * brought the code in sync with the spec * numerous bugs were fixed (buffer overflow, writing into random memory sections, memory corruptions, locking issues, elp packet length checks, printing the neighbors of the requested mesh only and many more) The ELP code is the first to use the recently introduced routing protocol abstraction. It is not compiled into batman-adv by default, therefore you need to compile with CONFIG_BATMAN_ADV_BATMAN_V=y or modify the makefile. Once the batman-adv kernel module has been loaded you can check for the existence of the new routing protocol: cat /sys/kernel/debug/batman_adv/routing_algos Available routing algorithms: BATMAN IV BATMAN V To activate B.A.T.M.A.N. V (ELP) you should run the following command *before* adding any interface via batctl: echo -n "BATMAN V" > /sys/module/batman_adv/parameters/routing_algo Caveats: * ELP alone (without OGMv2) isn't very useful because ELP handles single hop neighbors only. So don't expect to convert your entire mesh network to B.A.T.M.A.N. V just yet. * The batman-adv routing protocol abstraction still lacks the translation table integration which is why the following patches will lead to a kernel crash. The ELP repository[2] contains a patch to disable the TT propagation partially to mitigate the problem until a proper solution has been implemented. Any comments and suggestions are appreciated. Regards, Marek [1] http://www.open-mesh.org/wiki/batman-adv/ELP [2] http://git.open-mesh.org/?p=marek/batman-adv.git;a=shortlog;h=refs/heads/elp Linus Luessing (5): batman-adv: ELP - adding basic infrastructure batman-adv: ELP - creating neighbor structures, updating LQs batman-adv: ELP - exporting neighbor list via debugfs batman-adv: ELP - adding sysfs parameter for elp interval batman-adv: ELP - add configurable minimum ELP packet length (def: 300B) Makefile | 2 + Makefile.kbuild | 1 + README.external | 1 + bat_algo.h | 6 + bat_debugfs.c | 16 ++ bat_sysfs.c | 8 + bat_v_elp.c | 500 ++++++++++++++++++++++++++++++++++++++++++++ gen-compat-autoconf.sh | 1 + hard-interface.c | 7 + main.c | 1 + packet.h | 20 ++- sysfs-class-net-batman-adv | 13 ++ types.h | 15 ++ 13 files changed, 590 insertions(+), 1 deletions(-)

4 29

[B.A.T.M.A.N.] [PATCH] batman-adv: Initialize lockdep class keys for hashes
by Sven Eckelmann 04 Apr '12

04 Apr '12

The hash for claim and backbone hash in the bridge loop avoidance code receive the same key because they are getting initialized by hash_new with the same key. Lockdep will create a backtrace when they are used recursively. This can be avoided by reinitializing the key directly after the hash_new. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- bridge_loop_avoidance.c | 11 +++++++++++ hash.c | 9 +++++++++ hash.h | 3 +++ 3 files changed, 23 insertions(+), 0 deletions(-) diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c index 8a17a78..c74d8a2 100644 --- a/bridge_loop_avoidance.c +++ b/bridge_loop_avoidance.c @@ -1124,6 +1124,14 @@ out: bla_start_timer(bat_priv); } +/* The hash for claim and backbone hash receive the same key because they + * are getting initialized by hash_new with the same key. Reinitializing + * them with to different keys to allow nested locking without generating + * lockdep warnings + */ +static struct lock_class_key claim_hash_lock_class_key; +static struct lock_class_key backbone_hash_lock_class_key; + /* initialize all bla structures */ int bla_init(struct bat_priv *bat_priv) { @@ -1158,6 +1166,9 @@ int bla_init(struct bat_priv *bat_priv) bat_priv->claim_hash = hash_new(128); bat_priv->backbone_hash = hash_new(32); + hash_set_lock_class(bat_priv->claim_hash, &claim_hash_lock_class_key); + hash_set_lock_class(bat_priv->backbone_hash, &backbone_hash_lock_class_key); + if (!bat_priv->claim_hash || !bat_priv->backbone_hash) return -1; diff --git a/hash.c b/hash.c index 117687b..13d4597 100644 --- a/hash.c +++ b/hash.c @@ -69,3 +69,12 @@ free_hash: kfree(hash); return NULL; } + +void hash_set_lock_class(struct hashtable_t *hash, struct lock_class_key *key) +{ + uint32_t i; + + for (i = 0 ; i < hash->size; i++) { + lockdep_set_class(&hash->list_locks[i], key); + } +} diff --git a/hash.h b/hash.h index d4bd786..7bcb98f 100644 --- a/hash.h +++ b/hash.h @@ -45,6 +45,9 @@ struct hashtable_t { /* allocates and clears the hash */ struct hashtable_t *hash_new(uint32_t size); +/* set class key for all locks */ +void hash_set_lock_class(struct hashtable_t *hash, struct lock_class_key *key); + /* free only the hashtable and the hash itself. */ void hash_destroy(struct hashtable_t *hash); -- 1.7.9.1

2 2

[B.A.T.M.A.N.] [PATCH] batman-adv: unset the TT_CLIENT_PENDING flag if the new local entry already exists
by Antonio Quartulli 04 Apr '12

04 Apr '12

When trying to add a new tt_local_entry, if such entry already exists, we have to ensure that the TT_CLIENT_PENDING flag is not set, otherwise the entry will be deleted soon. Reported-by: Simon Wunderlich <siwu(a)hrz.tu-chemnitz.de> Signed-off-by: Antonio Quartulli <ordex(a)autistici.org> --- translation-table.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/translation-table.c b/translation-table.c index 27753a0..65de6b7 100644 --- a/translation-table.c +++ b/translation-table.c @@ -188,6 +188,8 @@ void tt_local_add(struct net_device *soft_iface, const uint8_t *addr, if (tt_local_entry) { tt_local_entry->last_seen = jiffies; + /* possibly unset the TT_CLIENT_PENDING flag */ + tt_local_entry->common.flags &= ~TT_CLIENT_PENDING; goto out; } -- 1.7.3.4

2 1

[B.A.T.M.A.N.] any throughput mechanism or plans?
by dan 02 Apr '12

02 Apr '12

I can't see anything in my reading on this. Is there a mechanism to identify throughput between two nodes? or between a client and a destination for the purpose of routing through the highest throughput path? For instance, track the maximum throughput on each interface over time. Compare it to the current throughput on the interface and send what is leftover as 'available throughput' with the TQ each node. Now instead of adding up the numbers as with TQ, just take the min. Take the lowest throughput along the path and have a node be able to utilize the highest throughput path that has acceptable TQ. As a node's interface gets loaded up (vs observed maximum) it will inform it's neighbors in the same way it informs them of the TQ of each interface and then the neighbors can choose to route around if there is a good alternate path. Basically, I'm thinking that TQ isn't the only or most optimal way to route simply because available throughput should be considered somehow. As far as I can tell, a 56k link with .001% packet loss is better than a 54Mb link with .1% packet loss, though both are solid interfaces and the 54Mb link should be prefered heavily over the 56k link. The 56k link probably will start dropping packets once it is saturated, but one client might run up against slow ACKs keeping the remote server from sending enough data to saturate the connection so the client could be getting a very slow connection while a 54Mb link sits virtually unused.

5 12

[B.A.T.M.A.N.] question about frag_can_reassemble()
by Dan Carpenter 31 Mar '12

31 Mar '12

Hi Sven, I had a question about the code in frag_can_reassemble(). net/batman-adv/unicast.h 51 52 merged_size = (skb->len - sizeof(*unicast_packet)) * 2; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 53 merged_size += sizeof(struct unicast_packet) + uneven_correction; 54 55 return merged_size <= mtu; 56 } Can the skb->len be less than sizeof(*unicast_packet) (ie 20 bytes)? If "len" is less than 10 then we would return false but if it's over 10 then we would return true. Roughly. regards, dan carpenter

2 1

[B.A.T.M.A.N.] [PATCH] batman-adv: make tt_changes_buff API consistent
by Antonio Quartulli 30 Mar '12

30 Mar '12

The changes buff is not used in a consistent way right now. During the OGM preparation, first the buffer size is read and then it is copied, without any locking mechanism at all. This could obviously raise a race condition. This patch changes the API a little bit and adds a proper locking mechanism in order to avoid such problem. At the same time, the new API proposed in this patch is also more suitable to make the OGM packet preparation independent from the TT code. Signed-off-by: Antonio Quartulli <ordex(a)autistici.org> --- @Marek: this patch is different from the one I sent you before send.c | 36 ++------------ translation-table.c | 135 +++++++++++++++++++++++++++++++++------------------ translation-table.h | 7 ++- types.h | 3 + 4 files changed, 99 insertions(+), 82 deletions(-) diff --git a/send.c b/send.c index 20f6e89..40313b3 100644 --- a/send.c +++ b/send.c @@ -78,48 +78,20 @@ send_skb_err: return NET_XMIT_DROP; } -static void realloc_packet_buffer(struct hard_iface *hard_iface, - int new_len) -{ - unsigned char *new_buff; - - new_buff = kmalloc(new_len, GFP_ATOMIC); - - /* keep old buffer if kmalloc should fail */ - if (new_buff) { - memcpy(new_buff, hard_iface->packet_buff, - BATMAN_OGM_HLEN); - - kfree(hard_iface->packet_buff); - hard_iface->packet_buff = new_buff; - hard_iface->packet_len = new_len; - } -} - /* when calling this function (hard_iface == primary_if) has to be true */ static int prepare_packet_buffer(struct bat_priv *bat_priv, struct hard_iface *hard_iface) { - int new_len; - - new_len = BATMAN_OGM_HLEN + - tt_len((uint8_t)atomic_read(&bat_priv->tt_local_changes)); - - /* if we have too many changes for one packet don't send any - * and wait for the tt table request which will be fragmented */ - if (new_len > hard_iface->soft_iface->mtu) - new_len = BATMAN_OGM_HLEN; - - realloc_packet_buffer(hard_iface, new_len); + int tt_changes = 0; atomic_set(&bat_priv->tt_crc, tt_local_crc(bat_priv)); /* reset the sending counter */ atomic_set(&bat_priv->tt_ogm_append_cnt, TT_OGM_APPEND_MAX); - return tt_changes_fill_buffer(bat_priv, - hard_iface->packet_buff + BATMAN_OGM_HLEN, - hard_iface->packet_len - BATMAN_OGM_HLEN); + tt_changes = tt_alloc_buffer(bat_priv, hard_iface, BATMAN_OGM_HLEN); + + return tt_changes; } static int reset_packet_buffer(struct bat_priv *bat_priv, diff --git a/translation-table.c b/translation-table.c index 934900d..3454879 100644 --- a/translation-table.c +++ b/translation-table.c @@ -273,53 +273,6 @@ out: tt_global_entry_free_ref(tt_global_entry); } -int tt_changes_fill_buffer(struct bat_priv *bat_priv, - unsigned char *buff, int buff_len) -{ - int count = 0, tot_changes = 0; - struct tt_change_node *entry, *safe; - - if (buff_len > 0) - tot_changes = buff_len / tt_len(1); - - spin_lock_bh(&bat_priv->tt_changes_list_lock); - atomic_set(&bat_priv->tt_local_changes, 0); - - list_for_each_entry_safe(entry, safe, &bat_priv->tt_changes_list, - list) { - if (count < tot_changes) { - memcpy(buff + tt_len(count), - &entry->change, sizeof(struct tt_change)); - count++; - } - list_del(&entry->list); - kfree(entry); - } - spin_unlock_bh(&bat_priv->tt_changes_list_lock); - - /* Keep the buffer for possible tt_request */ - spin_lock_bh(&bat_priv->tt_buff_lock); - kfree(bat_priv->tt_buff); - bat_priv->tt_buff_len = 0; - bat_priv->tt_buff = NULL; - /* We check whether this new OGM has no changes due to size - * problems */ - if (buff_len > 0) { - /** - * if kmalloc() fails we will reply with the full table - * instead of providing the diff - */ - bat_priv->tt_buff = kmalloc(buff_len, GFP_ATOMIC); - if (bat_priv->tt_buff) { - memcpy(bat_priv->tt_buff, buff, buff_len); - bat_priv->tt_buff_len = buff_len; - } - } - spin_unlock_bh(&bat_priv->tt_buff_lock); - - return tot_changes; -} - int tt_local_seq_print_text(struct seq_file *seq, void *offset) { struct net_device *net_dev = (struct net_device *)seq->private; @@ -2005,10 +1958,98 @@ static void tt_local_purge_pending_clients(struct bat_priv *bat_priv) } +static void tt_save_events_buff(struct bat_priv *bat_priv) +{ + int count = 0; + int tot_changes_size; + struct tt_change_node *entry, *safe; + + spin_lock_bh(&bat_priv->tt_changes_list_lock); + spin_lock_bh(&bat_priv->tt_changes_tmp_lock); + + bat_priv->tt_num_changes_tmp = atomic_read(&bat_priv->tt_local_changes); + atomic_set(&bat_priv->tt_local_changes, 0); + + kfree(bat_priv->tt_changes_tmp); + + tot_changes_size = tt_len(bat_priv->tt_num_changes_tmp); + bat_priv->tt_changes_tmp = kmalloc(tot_changes_size, GFP_ATOMIC); + if (!bat_priv->tt_changes_tmp) + goto out; + + list_for_each_entry_safe(entry, safe, &bat_priv->tt_changes_list, + list) { + if (count < bat_priv->tt_num_changes_tmp) { + memcpy(bat_priv->tt_changes_tmp + tt_len(count), + &entry->change, sizeof(struct tt_change)); + count++; + } + list_del(&entry->list); + kfree(entry); + } +out: + spin_unlock_bh(&bat_priv->tt_changes_tmp_lock); + spin_unlock_bh(&bat_priv->tt_changes_list_lock); +} + +void realloc_packet_buffer(struct hard_iface *hard_iface, + int new_len) +{ + unsigned char *new_buff; + + /* if we have too many changes for one packet don't send any + * and wait for the tt table request which will be fragmented */ + if (new_len > hard_iface->soft_iface->mtu) + new_len = BATMAN_OGM_HLEN; + + new_buff = kmalloc(new_len, GFP_ATOMIC); + + /* keep old buffer if kmalloc should fail */ + if (new_buff) { + memcpy(new_buff, hard_iface->packet_buff, + BATMAN_OGM_HLEN); + + kfree(hard_iface->packet_buff); + hard_iface->packet_buff = new_buff; + hard_iface->packet_len = new_len; + } +} + +uint16_t tt_alloc_buffer(struct bat_priv *bat_priv, + struct hard_iface *hard_iface, int header_size) +{ + int size; + uint16_t tt_changes_num = 0; + + spin_lock_bh(&bat_priv->tt_changes_tmp_lock); + + size = header_size + tt_len(bat_priv->tt_num_changes_tmp); + if (size != hard_iface->packet_len) + realloc_packet_buffer(hard_iface, size); + + /* check if we really allocated the requested amount of memory */ + if (hard_iface->packet_len == size) { + memcpy(hard_iface->packet_buff + header_size, + bat_priv->tt_changes_tmp, + tt_len(bat_priv->tt_num_changes_tmp)); + tt_changes_num = bat_priv->tt_num_changes_tmp; + } + + kfree(bat_priv->tt_changes_tmp); + + bat_priv->tt_changes_tmp = NULL; + bat_priv->tt_num_changes_tmp = 0; + + spin_unlock_bh(&bat_priv->tt_changes_tmp_lock); + + return tt_changes_num; +} + void tt_commit_changes(struct bat_priv *bat_priv) { uint16_t changed_num = tt_set_flags(bat_priv->tt_local_hash, TT_CLIENT_NEW, false); + tt_save_events_buff(bat_priv); /* all the reset entries have now to be effectively counted as local * entries */ atomic_add(changed_num, &bat_priv->num_local_tt); diff --git a/translation-table.h b/translation-table.h index c43374d..73279f6 100644 --- a/translation-table.h +++ b/translation-table.h @@ -23,8 +23,6 @@ #define _NET_BATMAN_ADV_TRANSLATION_TABLE_H_ int tt_len(int changes_num); -int tt_changes_fill_buffer(struct bat_priv *bat_priv, - unsigned char *buff, int buff_len); int tt_init(struct bat_priv *bat_priv); void tt_local_add(struct net_device *soft_iface, const uint8_t *addr, int ifindex); @@ -54,6 +52,9 @@ void tt_update_orig(struct bat_priv *bat_priv, struct orig_node *orig_node, const unsigned char *tt_buff, uint8_t tt_num_changes, uint8_t ttvn, uint16_t tt_crc); bool tt_global_client_is_roaming(struct bat_priv *bat_priv, uint8_t *addr); - +uint16_t tt_alloc_buffer(struct bat_priv *bat_priv, + struct hard_iface *hard_iface, int header_size); +void realloc_packet_buffer(struct hard_iface *hard_iface, + int new_len); #endif /* _NET_BATMAN_ADV_TRANSLATION_TABLE_H_ */ diff --git a/types.h b/types.h index 15f538a..462ec7a 100644 --- a/types.h +++ b/types.h @@ -198,6 +198,8 @@ struct bat_priv { struct hlist_head forw_bcast_list; struct hlist_head gw_list; struct list_head tt_changes_list; /* tracks changes in a OGM int */ + unsigned char *tt_changes_tmp; + uint16_t tt_num_changes_tmp; struct list_head vis_send_list; struct hashtable_t *orig_hash; struct hashtable_t *tt_local_hash; @@ -217,6 +219,7 @@ struct bat_priv { spinlock_t forw_bat_list_lock; /* protects forw_bat_list */ spinlock_t forw_bcast_list_lock; /* protects */ spinlock_t tt_changes_list_lock; /* protects tt_changes */ + spinlock_t tt_changes_tmp_lock; /* protects tt_changes_tmp */ spinlock_t tt_req_list_lock; /* protects tt_req_list */ spinlock_t tt_roam_list_lock; /* protects tt_roam_list */ spinlock_t gw_list_lock; /* protects gw_list and curr_gw */ -- 1.7.3.4

1 0

[B.A.T.M.A.N.] B.A.T.M.A.N. GSoC 2012 announcement
by Simon Wunderlich 30 Mar '12

30 Mar '12

Hey there, the student application period for the Google Summer of Code 2012 has opened. A chance for any student to get their hands dirty on their favorite OpenSource project and getting its development process and code base to know better during these 2 months - while getting payed for it! As last year, B.A.T.M.A.N. tasks will be done as part of the freifunk project, which again will serve as an umbrella organization for various projects dealing with wireless mesh networks. If you are interested in mesh networking and B.A.T.M.A.N. and if you also love OpenSource software and would like to become a more firm part of it, then please apply on fore freifunk: http://www.google-melange.com/gsoc/org/show/google/gsoc2012/freifunk and get in touch with us via mailinglist and/or IRC. So far the following ideas have been collected which you may apply for: http://wiki.freifunk.net/Ideas#B.A.T.M.A.N. But feel free to tell us your own suggestions and ideas, too. ***** **** *** Student application deadline is the 6th of April!! *** **** ***** - GSoC timeline: http://www.google-melange.com/gsoc/events/google/gsoc2012 - Student Check List: http://wiki.freifunk.net/Student_Check_List - Freifunk GSoC Page: http://www.google-melange.com/gsoc/org/show/google/gsoc2012/freifunk Happy routing, The B.A.T.M.A.N. team

1 0

[B.A.T.M.A.N.] BW degradation on p2p links?
by Guido Iribarren 30 Mar '12

30 Mar '12

Hi, i'm participating in the development of a wireless mesh network in Delta de Tigre, near Buenos Aires, Argentina. Landscape is absolutely flat, with dense forest 15-20mts tall. Nodes are being installed along the river, 50 - 150mts apart, with clear LOS at ground level. I collaborated with Nico Echaniz last month, bulding another community network in Cordoba, and given the success, I decided to start one more here. I'm also really thankful with Elektra, for recommending the tl-m3220 to Nico! We chose batman over olsr, in part because of avahi stuff, but also to have a real-world implementation and thus collaborate in testing / debugging :) So far, there are only 4 working nodes, but luckily I'm already facing unexpected behaviour. I'm sorry for the long email, it's mostly terminal logs. In short, iperf between two neighbouring nodes reports >20mbps, yet running the same iperf between nodes separated by one hop reports inexplicably low <5mbps. Links are point to point, with different radios on different channels, no freq overlap. A=[ath9k]--(50m)--[ath9k]=B=[ath9k_htc]--(150m)--[ath9k_htc]=C=[ath9k]--(50m)--[ath9k]=D A is a tplink mr3420 + wn722n B and C are tplink mr3220 + wn722n D is a tplink mr3220 (single interface) All of them are running openwrt trunk r30919. the internal iface of the mr3x20 uses ath9k, and the wn722n runs with ath9k_htc the link between B and C is done in infrastructure mode, B is ap and C is managed. Radios are set to channel 9, HT40-. C <-> D is made with ath9k , in channel 1 , HT20. (all hostnames have been obscured for readability :P ) nodeB -> nodeC = 31mbps nodeC -> nodeD = 21mbps nodeB -> nodeD = 3mbps nodeD -> nodeC = 21mbps nodeC -> nodeB = 21mbps nodeD -> nodeB = 10mbps nodeD# batctl tr B_mesh traceroute to B_mesh (56:e6:fc:be:29:d3), 50 hops max, 20 byte packets 1: C_mesh (56:e6:fc:b9:b6:47) 1.155 ms 0.834 ms 0.796 ms 2: B_mesh (56:e6:fc:be:29:d3) 6.523 ms 2.719 ms 1.917 ms nodeB# batctl tr D_mesh traceroute to D_mesh (56:e6:fc:b9:b7:01), 50 hops max, 20 byte packets 1: C_mesh (56:e6:fc:b9:b6:47) 1.323 ms 1.117 ms 0.974 ms 2: D_mesh (56:e6:fc:b9:b7:01) 2.278 ms 1.839 ms 2.164 ms ### iperf between nodeB -> nodeC root@nodeB:~# iperf -c nodeC -w 320k -i 1 ------------------------------------------------------------ Client connecting to nodeC, TCP port 5001 TCP window size: 320 KByte ------------------------------------------------------------ [ 3] local 10.6.0.1 port 35759 connected with 10.6.0.32 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 3.63 MBytes 30.4 Mbits/sec [ 3] 1.0- 2.0 sec 3.63 MBytes 30.4 Mbits/sec [ 3] 2.0- 3.0 sec 4.00 MBytes 33.6 Mbits/sec [ 3] 3.0- 4.0 sec 3.63 MBytes 30.4 Mbits/sec [ 3] 4.0- 5.0 sec 3.88 MBytes 32.5 Mbits/sec [ 3] 5.0- 6.0 sec 3.88 MBytes 32.5 Mbits/sec [ 3] 6.0- 7.0 sec 4.00 MBytes 33.6 Mbits/sec [ 3] 7.0- 8.0 sec 3.75 MBytes 31.5 Mbits/sec [ 3] 8.0- 9.0 sec 3.75 MBytes 31.5 Mbits/sec [ 3] 9.0-10.0 sec 3.75 MBytes 31.5 Mbits/sec [ 3] 0.0-10.1 sec 38.0 MBytes 31.7 Mbits/sec ### iperf between nodeC -> nodeD nodeC# iperf -c nodeD -w 320k -i 1 ------------------------------------------------------------ Client connecting to nodeD, TCP port 5001 TCP window size: 320 KByte ------------------------------------------------------------ [ 3] local 10.6.0.32 port 43655 connected with 10.6.0.16 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 2.50 MBytes 21.0 Mbits/sec [ 3] 1.0- 2.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 2.0- 3.0 sec 2.50 MBytes 21.0 Mbits/sec [ 3] 3.0- 4.0 sec 2.88 MBytes 24.1 Mbits/sec [ 3] 4.0- 5.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 5.0- 6.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 6.0- 7.0 sec 2.50 MBytes 21.0 Mbits/sec [ 3] 7.0- 8.0 sec 2.25 MBytes 18.9 Mbits/sec [ 3] 8.0- 9.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 9.0-10.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 0.0-10.1 sec 25.9 MBytes 21.5 Mbits/sec ### Now, enter the mistery.. ### Best iperf run after several attemps yielding 1 - 2 mbps # iperf -c charly-muelle -w 320k -i 1 -t 20 ------------------------------------------------------------ Client connecting to charly-muelle, TCP port 5001 TCP window size: 320 KByte ------------------------------------------------------------ [ 3] local 10.6.0.1 port 55093 connected with 10.6.0.16 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec [ 3] 1.0- 2.0 sec 256 KBytes 2.10 Mbits/sec [ 3] 2.0- 3.0 sec 128 KBytes 1.05 Mbits/sec [ 3] 3.0- 4.0 sec 128 KBytes 1.05 Mbits/sec [ 3] 4.0- 5.0 sec 256 KBytes 2.10 Mbits/sec [ 3] 5.0- 6.0 sec 384 KBytes 3.15 Mbits/sec [ 3] 6.0- 7.0 sec 128 KBytes 1.05 Mbits/sec [ 3] 7.0- 8.0 sec 384 KBytes 3.15 Mbits/sec [ 3] 8.0- 9.0 sec 256 KBytes 2.10 Mbits/sec [ 3] 9.0-10.0 sec 512 KBytes 4.19 Mbits/sec [ 3] 10.0-11.0 sec 512 KBytes 4.19 Mbits/sec [ 3] 11.0-12.0 sec 512 KBytes 4.19 Mbits/sec [ 3] 12.0-13.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 13.0-14.0 sec 512 KBytes 4.19 Mbits/sec [ 3] 14.0-15.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 15.0-16.0 sec 512 KBytes 4.19 Mbits/sec [ 3] 16.0-17.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 17.0-18.0 sec 512 KBytes 4.19 Mbits/sec [ 3] 18.0-19.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 19.0-20.0 sec 512 KBytes 4.19 Mbits/sec [ 3] 0.0-20.3 sec 8.88 MBytes 3.66 Mbits/sec ### and the way back... (i'll snip the logs generously) nodeD# iperf -c nodeC -w320k [ 3] 0.0-10.1 sec 25.5 MBytes 21.2 Mbits/sec nodeC# iperf -c nodeB -w 320k [ 3] 0.0-10.0 sec 25.5 MBytes 21.3 Mbits/sec nodeD# iperf -c nodeB -w320k [ 3] 0.0-10.2 sec 12.3 MBytes 10.0 Mbits/sec This can be reproduced at will, and i don't understand what's happening. Looks like node C is getting .. overwhelmed..(?) when forwarding the packets between B and D Even more intriguing is that the problem is much worse when going B -> D (tenfold slower) than from D -> B (twice slower) ##### more screenlogs follow ### similar in node B and C (in D, there's no wlan1) # batctl -v batctl 2012.0.0 [batman-adv: 2012.0.0] # batctl if wlan0-1: active # ath9k, internal, adhoc mode wlan1: active # ath9k_htc, usb, infrastructure mode # brctl show bridge name bridge id STP enabled interfaces br-lan 8000.228082e1fd06 no wlan0 eth0 bat0 ### originators seen from nodeB nodeB# batctl o | cut -b -100 [B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/56:e6:fc:be:29:d3 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... A_wlan1 0.830s (250) A_wlan1 [ wlan1]: C_mesh ( 0) D_mesh 0.320s (230) C_wlan1 [ wlan1]: C_wlan1 (230) A_mesh 0.890s (250) A_wlan1 [ wlan1]: A_wlan1 (250) C_mesh 0.800s (241) C_wlan1 [ wlan1]: C_wlan1 (241) C_wlan1 0.720s (241) C_wlan1 [ wlan1]: A_wlan1 (226) ### originators seen from nodeC nodeC# batctl o |cut -b -100 [B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/56:e6:fc:b9:b6:47 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... B_mesh 0.830s (255) B_wlan1 [ wlan1]: D_mesh ( 0) A_wlan1 0.180s (242) A_wlan1 [ wlan1]: B_wlan1 (229) B_wlan1 0.280s (255) B_wlan1 [ wlan1]: A_wlan1 (233) D_mesh 0.030s (235) D_mesh [ wlan0-1]: A_wlan1 (194) A_mesh 0.430s (242) A_wlan1 [ wlan1]: B_wlan1 (230) Any ideas, thoughts, pointers? Any additional info needed? I've RTFW, RTFM, and even RTF-PDF concerning bandwidth degradation on single-interface-node mesh networks, and that's the reason why i'm (so far unsuccessfully) trying to overcome that problem with the additional USB interface. Thanks a lot for the attention! Guido

3 5

[B.A.T.M.A.N.] [PATCH] batman-adv: Add routing_algo to README
by Sven Eckelmann 29 Mar '12

29 Mar '12

Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- README | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/README b/README index 01db663..88e8a1a 100644 --- a/README +++ b/README @@ -65,9 +65,9 @@ To deactivate an interface you have to write "none" into its All mesh wide settings can be found in batman's own interface folder: -# ls /sys/class/net/bat0/mesh/ -# aggregated_ogms fragmentation gw_sel_class vis_mode -# ap_isolation gw_bandwidth hop_penalty +# ls /sys/class/net/bat0/mesh/ +# aggregated_ogms fragmentation gw_sel_class routing_algo +# ap_isolation gw_bandwidth hop_penalty vis_mode # bonding gw_mode orig_interval -- 1.7.9.1

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N March 2012