[B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
by dan
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.
10 years, 2 months
[B.A.T.M.A.N.] [RFC] ELP
by Marek Lindner
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(-)
10 years, 5 months
[B.A.T.M.A.N.] [PATCH] batman-adv: Initialize lockdep class keys for hashes
by Sven Eckelmann
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
10 years, 5 months
[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
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
10 years, 5 months
[B.A.T.M.A.N.] any throughput mechanism or plans?
by dan
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.
10 years, 5 months
[B.A.T.M.A.N.] question about frag_can_reassemble()
by Dan Carpenter
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
10 years, 5 months
[B.A.T.M.A.N.] [PATCH] batman-adv: make tt_changes_buff API consistent
by Antonio Quartulli
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
10 years, 5 months
[B.A.T.M.A.N.] BW degradation on p2p links?
by Guido Iribarren
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
10 years, 6 months
[B.A.T.M.A.N.] [PATCH] batman-adv: Add routing_algo to README
by Sven Eckelmann
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
10 years, 6 months
