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.] batctl vd dot buggy
by Gioacchino Mazzurco 13 Jul '11

13 Jul '11

on our server we have batman-adv from 2.6.38 kernel the output of batctl vd dot results buggy eigenServer gioacchino # batctl -v batctl 2011.1.0 as you can see here http://eigenlab.org/status.php a lot of blue cluster are missing also on node with multiple interfaces so the topology draw is badly affected by this :|

5 13

[B.A.T.M.A.N.] UDP and TCP bandwidth test for 802.11g in batman-adv 2011.1.0
by Max Ip 11 Jul '11

11 Jul '11

Hi all, I have network connection of two laptops connected through wifi in Access Point mode with bandwidth 54Mbps (802.11g). Laptop A ---- Access point ------ Laptop B 192.168.1.2 ---- 192.168.1.220 ------ 192.168.1.3 I used netperf to measure the bandwidth and CPU utilization Without installing batman-adv on Laptop A and Laptop B , the results of netperf are: netperf -H 192.168.1.3 -t TCP_STREAM -l 10 -c TCP throughput : 11.89 Mbps TCP CPU usage: 1.73 % netperf -H 192.168.1.3 -t UDP_STREAM -l 10 -c UDP throughput: 22.5 Mbps UDP CPU usage: 1.8 % Now, after I installed batman-adv 2011.1.0 on Laptop A and Laptop B. To the nodes Laptop A and Laptop B I assigned IP address: sudo ifconfig bat0 10.42.43.1 (laptop A) sudo ifconfig bat0 10.42.43.2 (laptop B) The protocol runs fine and the originators are seen on both sides. Also, the avahi-discover shows both laptops. When I now tried to measure the throughput, netperf -H 192.168.1.3 -t TCP_STREAM -l 10 -c TCP throughput : 9.23 Mbps TCP CPU usage: 3.91 % netperf -H 192.168.1.3 -t UDP_STREAM -l 10 -c UDP throughput: 3200 Mbps UDP CPU usage: 51% Why would the UDP throughput be so high? There is no possibility to have it so high. Is it because of the bad configuration in access point as it is non batman interface or sth else? What do you think? Thanks. Max Max

2 3

[B.A.T.M.A.N.] [PATCH] batctl: keep local table consistency for further TT_RESPONSE
by Antonio Quartulli 08 Jul '11

08 Jul '11

To keep transtable consistency among all the nodes, an originator must not send not yet announced clients within a full table TT_RESPONSE. Instead, deleted client have to be kept in the table in order to be sent within an immediate TT_RESPONSE. In this way all the nodes in the network will always provide the same response for the same request. All the modification are committed at the next ttvn increment event. Signed-off-by: Antonio Quartulli <ordex(a)autistici.org> Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de> --- packet.h | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/packet.h b/packet.h index 590e4a6..b76b4be 100644 --- a/packet.h +++ b/packet.h @@ -84,7 +84,9 @@ enum tt_query_flags { enum tt_client_flags { TT_CLIENT_DEL = 1 << 0, TT_CLIENT_ROAM = 1 << 1, - TT_CLIENT_NOPURGE = 1 << 8 + TT_CLIENT_NOPURGE = 1 << 8, + TT_CLIENT_NEW = 1 << 9, + TT_CLIENT_PENDING = 1 << 10 }; struct batman_packet { -- 1.7.3.4

2 1

[B.A.T.M.A.N.] [PATCH] batctl: avoid uninitialized variable when compiling bisect
by Marek Lindner 08 Jul '11

08 Jul '11

Reported-by: Max Ip <ipmax2011(a)googlemail.com> Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de> --- bisect.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/bisect.c b/bisect.c index f6f171e..d3789aa 100644 --- a/bisect.c +++ b/bisect.c @@ -194,7 +194,7 @@ static int routing_table_new(char *orig, char *next_hop, char *old_next_hop, cha struct seqno_event *seqno_event; struct rt_table *rt_table, *prev_rt_table = NULL; struct rt_hist *rt_hist; - int i, j; + int i, j = -1; if (!curr_bat_node) { fprintf(stderr, "Routing table change without preceding OGM - skipping"); @@ -331,7 +331,6 @@ static int routing_table_new(char *orig, char *next_hop, char *old_next_hop, cha } if (prev_rt_table) { - j = -1; for (i = 0; i < prev_rt_table->num_entries; i++) { /* if we have a previously deleted item don't copy it over */ if (prev_rt_table->entries[i].flags == RT_FLAG_DELETE) { -- 1.7.5.3

1 1

[B.A.T.M.A.N.] pull request: batman-adv 2011-07-08
by Marek Lindner 08 Jul '11

08 Jul '11

Hi, I have another small but important set of changes I'd like to get pulled into net-next-2.6/3.1. Despite our best efforts, recent tests and reviews of the protocol changes we have introduced a couple of weeks ago made it quite obvious that some bugs slipped through. The implementation of said protocol does not handle all corner cases in the way it should, thus provoking inconsistent states in the mesh. These 4 patches are meant to address the found issues. Thanks, Marek

2 6

[B.A.T.M.A.N.] [PATCHv3 0/3] Implement the AP-Isolation mechanism
by Antonio Quartulli 07 Jul '11

07 Jul '11

This is the third version of the AP-Isolation patchset. The patches have been rebased on top of the master branch but they have been left mostly unmodified. The Ap-isolation mechanism will prevent (if enabled) WIFI clients to communicate with other WIFI clients over the mesh network. WIFI check on a client is done by default while the isolation is performed only if the mechanism is enabled either on the receiver and on the transmitter side. Ap-isolation can be enabled or disabled by means of a new sysfs attribute (a batctl patch has also been provided to toggle interact with it). Thank you all. Regards, Antonio Quartulli

1 5

[B.A.T.M.A.N.] [PATCH] batman-adv: request the full table if tt_crc doesn't match
by Antonio Quartulli 07 Jul '11

07 Jul '11

In case of tt_crc mismatching for a certain orig_node after applying the changes, the node must request the full table immediately. Signed-off-by: Antonio Quartulli <ordex(a)autistici.org> --- routing.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/routing.c b/routing.c index 2cb98be..010ebb7 100644 --- a/routing.c +++ b/routing.c @@ -91,6 +91,11 @@ static void update_transtable(struct bat_priv *bat_priv, * to recompute it to spot any possible inconsistency * in the global table */ orig_node->tt_crc = tt_global_crc(bat_priv, orig_node); + + /* If something went wrong we must request the full table now */ + if (orig_node->tt_crc != tt_crc) + goto request_table; + /* Roaming phase is over: tables are in sync again. I can * unset the flag */ orig_node->tt_poss_change = false; -- 1.7.3.4

2 2

[B.A.T.M.A.N.] [PATCHv2 0/3] Solve consistency issues in TT code
by Antonio Quartulli 07 Jul '11

07 Jul '11

Hello all, this is the second version of the TT consistency fix patchset. The beautification patches have been removed as they were probably introducing a few new problems (thanks Sven for pointing me to the C99 documentation) while the remaining 4 patches have been merged in a more logical way. Here is a little overview: - 1/3 solves a 'little' bug found today. - 2/3 fixes the way local tables are handled - 3/3 fixes the roaming phase in order to keep consistency For more details, please read the commit messages. Thansk you! Regards, Antonio Quartulli

2 6

[B.A.T.M.A.N.] [PATCH 0/6] Solve consistency issues in TT code
by Antonio Quartulli 06 Jul '11

06 Jul '11

Hello everybody. In the current TT implementation there are some cases where transtable consistency is not kept. In particular, it is possible to observe this problem in case of a tt_response issued after a request for full-table: if the responding node is _the real destination of the request_ then it will send within the response message also those clients added after the last ttvn increment. This will cause an inconsistency because now we have different nodes with the same ttvn value but with different tables for the same originator. These patches are meant to solve this issue and keep consistency among nodes. Patches 1) and 2) introduce beautifications only. This change helped in writing patches 5) and 6) by reducing the code complexity. I would like to read some feedbacks even about the patch decomposition, which could probably be improved :-) Thank you all. Regards, Antonio Quartulli

2 12

[B.A.T.M.A.N.] Disconnecting the nodes in batman-adv 2011.1.0
by Max Ip 06 Jul '11

06 Jul '11

Hi all, I have three nodes (connected through wifi) running batman-adv, node_1 ------ node_2 ------node_3 They have ip address ipv4 10.42.43.1 , 2 , 3 respectively. Now, all the nodes are connected to each other. To see the bandwidth and jitter patterns through relaying, I decided to disconnect node_1 and node_3. In node_1 , sudo iptables -A INPUT -s 10.42.43.3 -j DROP When, I now run batman-adv protocol, node_1 still finds node_3 without node_2 being involved. Though they cannot ping and avahi doesn't run, batman-adv shows them as 1 hop neighbors. How can I disconnect node_1 from node_3 so that I can see the 2 hop patterns. Thankyou in advance. Max

5 11

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