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.] [PATCHv2 0/7] DAT: Distributed ARP Table
by Antonio Quartulli 21 Nov '11

21 Nov '11

Hello people, **** This is the second version of this patchset. Some bugs/typ0s have been corrected. Each patch contains in its header the change made from the previous version. Moreover a 7th patch has been included which add a compile-time option to enable/disable DAT. **** as most of you may already know, last summer I've been working on the B.A.T.M.A.N.-Adv GSoC project named "DAT: Distributed ARP Table". For who wants to get deeper into the details of the project there are two links: - The GSoC proposal [1] - The DAT wikipage on open-mesh.org [2], with status and ideas description Just to recap: DAT is a distributes hash table meant to store ARP entries for fast lookup. In a normal scenario, whenever a node wants to communicate with another one, it first needs to issue a broadcast ARP request in order to retrieve its PHY/MAC address. In a sparse network a broadcast message could be lost several times before reaching the real destination so creating high latencies. With DAT, every ARP entries (a pair [IP addr, MAC addr]) is stored on a "computed" set of nodes, therefore in case of ARP request theses nodes can directly be contacted (in unicast) and the needed information can be quickly fetched. Cheers, Antonio [1] http://www.google-melange.com/gsoc/project/google/gsoc2011/ordex/4001 [2] http://www.open-mesh.org/wiki/batman-adv/GSOC2011_DAT

2 10

[B.A.T.M.A.N.] Connecting non-batman nodes to a mesh network
by Panayot Daskalov 20 Nov '11

20 Nov '11

Hi All, I want to ask for your advice about a batman problem I am facing. I have a mesh network of custom build embedded Linux devices. The devices have only network one interface and this is the Wi-Fi that is used by batman. So far the mesh is running OK, but at some point I need to be able to connect with a laptop (non-Linux) to the network and access some of the devices via its IP address. I tried simply connecting to the adhoc network and setting a static IP to my laptop. I have managed to do that, but I can't access the nodes from the mesh. I read the instruction for mixing with non-batman devices by bridging the bat0 interface with the "non-batman" interface, but as far as I understand that applies to systems with at least 2 network interfaces e.g one for batman nodes and one for the non-batman. So my question is - can I mix non-batman and batman nodes when I have only one network interface on the batman nodes? If yes, then how? Thanks in advance. Best regards, Panayot P.S I am using batman-adv 2011.2.0, because I can't cross compile the latest version against the kernel I use on the devices - 2.6.28. Also I don't use batctl.

1 0

[B.A.T.M.A.N.] Very strange behaviour
by Filippo Sallemi 19 Nov '11

19 Nov '11

Hi, I'm just working on script that try to autorecover the node in case of failure and I noticed something very strange. Ii have 3 node setted to channel 3. Well when I change the channel of one of these nodes for example from 3 to 5 after some time I can see however the entirely topology of my network. How it is possible? My script is not ready and iwconfig output show the changed channel!!!! apparently do not have the same behavior if channel is far from other nodes (es 6) This is very very strange for me! Rgds -- Filippo Sallemi

3 2

[B.A.T.M.A.N.] [PATCH 0/5] Loop-freness for B.A.T.M.A.N.
by Daniele Furlan 18 Nov '11

18 Nov '11

This series of patches introduce a correction in tq metric and forwarding rules of ogm packets. In the current configuration routing loops scenario can emerge due to some conceptual errors such the global tq window and the forwarding of ogm coming from sub-optimal paths substituting ogm tq with the average of current router. An example scenario has been realized also in simulation using qemu. Can be demonstrated as already done for DSDV[1], that is a protocol very similar to batman, that a proper forwarding policy together with a strict control on metric monotonicity (as suggested in [2]) are sufficient to guarantee loop-freeness for the protocol. I apologize in advance if the source style is not the best possible, but I hope that the ideas will applied after a phase of code revision. Cheers, Daniele Furlan [1] C. Perkins, P. Bhagwat, ”Highly-dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers”, Proc. SIGCOMM ’94, pp. 234-244 [2] Y. Yang, J. Wang, R. Kravets, ”Designing routing metrics for mesh networks”, In WiMesh, 2005.

3 4

Re: [B.A.T.M.A.N.] B.A.T.M.A.N Digest, Vol 59, Issue 21
by gtolon＠inti.gob.ar 18 Nov '11

18 Nov '11

Thank you for the advice Marek! We've setted the mcast_rate in 18000 using uci and it's quite better! Unfortunately we've found a problem apparently related with ath9k driver, so we couldn't go on with more complicated routes tests. Thanks! > ------------------------------ Message: 4 Date: Wed, 16 Nov 2011 > 11:30:05 +0800 From: Marek Lindner <lindner_marek(a)yahoo.de> To: "The > list for a Better Approach To Mobile Ad-hoc Networking" > <b.a.t.m.a.n(a)lists.open-mesh.org> Subject: Re: [B.A.T.M.A.N.] Problem > to find better Route Message-ID: > <201111161130.05500.lindner_marek(a)yahoo.de> Content-Type: Text/Plain; > charset="iso-8859-1" On Wednesday, November 16, 2011 01:59:11 > gtolon(a)inti.gob.ar wrote: >> > Thank you for your answers. I copy the Originator's tables for the three >> > nodes: >> > >> > [..] >> > >> > This is a typical state of the tables. We tryed setting the hop pennalty >> > parameter to 1, but the behaviour hasn't changed. > The TQ values are quite close, so I can imagine that batman has a hard time > finding the better path. You could try to set the broadcast rate to a fixed > value (5.5 or even 18) to force the driver to not send the broadcasts at such > a low rate. > > Cheers, > Marek > > > ------------------------------ > > Message: 5 > Date: Wed, 16 Nov 2011 09:32:11 +0100 > From: Antonio Quartulli<ordex(a)autistici.org> > To: The list for a Better Approach To Mobile Ad-hoc Networking > <b.a.t.m.a.n(a)lists.open-mesh.org> > Subject: Re: [B.A.T.M.A.N.] Problem to find better Route > Message-ID:<20111116083210.GA17049(a)ritirata.org> > Content-Type: text/plain; charset=utf-8 > > On Wed, Nov 16, 2011 at 11:30:05 +0800, Marek Lindner wrote: >> > The TQ values are quite close, so I can imagine that batman has a hard time >> > finding the better path. You could try to set the broadcast rate to a fixed >> > value (5.5 or even 18) to force the driver to not send the broadcasts at such >> > a low rate. > Can you really do that? > > > Cheers, > > -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto > "Che" Guevara ------------------------------ Message: 6 Date: Wed, 16 > Nov 2011 16:49:46 +0800 From: Marek Lindner <lindner_marek(a)yahoo.de> > To: "The list for a Better Approach To Mobile Ad-hoc Networking" > <b.a.t.m.a.n(a)lists.open-mesh.org> Subject: Re: [B.A.T.M.A.N.] Problem > to find better Route Message-ID: > <201111161649.46492.lindner_marek(a)yahoo.de> Content-Type: Text/Plain; > charset="utf-8" On Wednesday, November 16, 2011 16:32:11 Antonio > Quartulli wrote: >> > On Wed, Nov 16, 2011 at 11:30:05 +0800, Marek Lindner wrote: >>> > > The TQ values are quite close, so I can imagine that batman has a hard >>> > > time finding the better path. You could try to set the broadcast rate to >>> > > a fixed value (5.5 or even 18) to force the driver to not send the >>> > > broadcasts at such a low rate. >> > >> > Can you really do that? > Yap. If you want to find out how: google is your friend.:-) > > Cheers, > Marek > > > ------------------------------

1 0

[B.A.T.M.A.N.] [PATCH 1/5] Rename 'tq_avg' field of struct 'neigh_node' in 'tq'.
by Daniele Furlan 17 Nov '11

17 Nov '11

This patch rename the 'tq_avg' field of struct 'neigh_node' in 'tq'. This will reflect the absence of an averaging of tq values. Signed-off-by: Daniele Furlan <daniele.furlan(a)gmail.com> --- bat_iv_ogm.c | 20 ++++++++++---------- gateway_client.c | 36 ++++++++++++++++++------------------ originator.c | 8 ++++---- routing.c | 4 ++-- types.h | 2 +- vis.c | 8 ++++---- 6 files changed, 39 insertions(+), 39 deletions(-) diff --git a/bat_iv_ogm.c b/bat_iv_ogm.c index 3512e25..d39938c 100644 --- a/bat_iv_ogm.c +++ b/bat_iv_ogm.c @@ -468,7 +468,7 @@ static void bat_ogm_forward(struct orig_node *orig_node, { struct bat_priv *bat_priv = netdev_priv(if_incoming->soft_iface); struct neigh_node *router; - uint8_t in_tq, in_ttl, tq_avg = 0; + uint8_t in_tq, in_ttl, tq = 0; uint8_t tt_num_changes; if (batman_ogm_packet->ttl <= 1) { @@ -487,17 +487,17 @@ static void bat_ogm_forward(struct orig_node *orig_node, /* rebroadcast tq of our best ranking neighbor to ensure the rebroadcast * of our best tq value */ - if (router && router->tq_avg != 0) { + if (router && router->tq != 0) { /* rebroadcast ogm of best ranking neighbor as is */ if (!compare_eth(router->addr, ethhdr->h_source)) { - batman_ogm_packet->tq = router->tq_avg; + batman_ogm_packet->tq = router->tq; if (router->last_ttl) batman_ogm_packet->ttl = router->last_ttl - 1; } - tq_avg = router->tq_avg; + tq = router->tq; } if (router) @@ -507,9 +507,9 @@ static void bat_ogm_forward(struct orig_node *orig_node, batman_ogm_packet->tq = hop_penalty(batman_ogm_packet->tq, bat_priv); bat_dbg(DBG_BATMAN, bat_priv, - "Forwarding packet: tq_orig: %i, tq_avg: %i, " + "Forwarding packet: tq_orig: %i, tq: %i, " "tq_forw: %i, ttl_orig: %i, ttl_forw: %i\n", - in_tq, tq_avg, batman_ogm_packet->tq, in_ttl - 1, + in_tq, tq, batman_ogm_packet->tq, in_ttl - 1, batman_ogm_packet->ttl); batman_ogm_packet->seqno = htonl(batman_ogm_packet->seqno); @@ -607,7 +607,7 @@ static void bat_ogm_orig_update(struct bat_priv *bat_priv, spin_lock_bh(&tmp_neigh_node->tq_lock); ring_buffer_set(tmp_neigh_node->tq_recv, &tmp_neigh_node->tq_index, 0); - tmp_neigh_node->tq_avg = + tmp_neigh_node->tq = ring_buffer_avg(tmp_neigh_node->tq_recv); spin_unlock_bh(&tmp_neigh_node->tq_lock); } @@ -638,7 +638,7 @@ static void bat_ogm_orig_update(struct bat_priv *bat_priv, ring_buffer_set(neigh_node->tq_recv, &neigh_node->tq_index, batman_ogm_packet->tq); - neigh_node->tq_avg = ring_buffer_avg(neigh_node->tq_recv); + neigh_node->tq = ring_buffer_avg(neigh_node->tq_recv); spin_unlock_bh(&neigh_node->tq_lock); if (!is_duplicate) { @@ -655,12 +655,12 @@ static void bat_ogm_orig_update(struct bat_priv *bat_priv, goto update_tt; /* if this neighbor does not offer a better TQ we won't consider it */ - if (router && (router->tq_avg > neigh_node->tq_avg)) + if (router && (router->tq > neigh_node->tq)) goto update_tt; /* if the TQ is the same and the link not more symmetric we * won't consider it either */ - if (router && (neigh_node->tq_avg == router->tq_avg)) { + if (router && (neigh_node->tq == router->tq)) { orig_node_tmp = router->orig_node; spin_lock_bh(&orig_node_tmp->ogm_cnt_lock); bcast_own_sum_orig = diff --git a/gateway_client.c b/gateway_client.c index 9373a14..f84fc2d 100644 --- a/gateway_client.c +++ b/gateway_client.c @@ -134,14 +134,14 @@ static struct gw_node *gw_get_best_gw_node(struct bat_priv *bat_priv) gw_bandwidth_to_kbit(gw_node->orig_node->gw_flags, &down, &up); - tmp_gw_factor = (router->tq_avg * router->tq_avg * + tmp_gw_factor = (router->tq * router->tq * down * 100 * 100) / (TQ_LOCAL_WINDOW_SIZE * TQ_LOCAL_WINDOW_SIZE * 64); if ((tmp_gw_factor > max_gw_factor) || ((tmp_gw_factor == max_gw_factor) && - (router->tq_avg > max_tq))) { + (router->tq > max_tq))) { if (curr_gw) gw_node_free_ref(curr_gw); curr_gw = gw_node; @@ -157,7 +157,7 @@ static struct gw_node *gw_get_best_gw_node(struct bat_priv *bat_priv) * soon as a better gateway appears which has * $routing_class more tq points) **/ - if (router->tq_avg > max_tq) { + if (router->tq > max_tq) { if (curr_gw) gw_node_free_ref(curr_gw); curr_gw = gw_node; @@ -166,8 +166,8 @@ static struct gw_node *gw_get_best_gw_node(struct bat_priv *bat_priv) break; } - if (router->tq_avg > max_tq) - max_tq = router->tq_avg; + if (router->tq > max_tq) + max_tq = router->tq; if (tmp_gw_factor > max_gw_factor) max_gw_factor = tmp_gw_factor; @@ -226,7 +226,7 @@ void gw_election(struct bat_priv *bat_priv) "Adding route to gateway %pM (gw_flags: %i, tq: %i)\n", next_gw->orig_node->orig, next_gw->orig_node->gw_flags, - router->tq_avg); + router->tq); throw_uevent(bat_priv, UEV_GW, UEV_ADD, gw_addr); } else { bat_dbg(DBG_BATMAN, bat_priv, @@ -234,7 +234,7 @@ void gw_election(struct bat_priv *bat_priv) "(gw_flags: %i, tq: %i)\n", next_gw->orig_node->orig, next_gw->orig_node->gw_flags, - router->tq_avg); + router->tq); throw_uevent(bat_priv, UEV_GW, UEV_CHANGE, gw_addr); } @@ -253,7 +253,7 @@ void gw_check_election(struct bat_priv *bat_priv, struct orig_node *orig_node) { struct orig_node *curr_gw_orig; struct neigh_node *router_gw = NULL, *router_orig = NULL; - uint8_t gw_tq_avg, orig_tq_avg; + uint8_t gw_tq, orig_tq; curr_gw_orig = gw_get_selected_orig(bat_priv); if (!curr_gw_orig) @@ -271,11 +271,11 @@ void gw_check_election(struct bat_priv *bat_priv, struct orig_node *orig_node) if (!router_orig) goto out; - gw_tq_avg = router_gw->tq_avg; - orig_tq_avg = router_orig->tq_avg; + gw_tq = router_gw->tq; + orig_tq = router_orig->tq; /* the TQ value has to be better */ - if (orig_tq_avg < gw_tq_avg) + if (orig_tq < gw_tq) goto out; /** @@ -283,13 +283,13 @@ void gw_check_election(struct bat_priv *bat_priv, struct orig_node *orig_node) * greater the TQ value of the new gateway must be **/ if ((atomic_read(&bat_priv->gw_sel_class) > 3) && - (orig_tq_avg - gw_tq_avg < atomic_read(&bat_priv->gw_sel_class))) + (orig_tq - gw_tq < atomic_read(&bat_priv->gw_sel_class))) goto out; bat_dbg(DBG_BATMAN, bat_priv, "Restarting gateway selection: better gateway found (tq curr: " "%i, tq new: %i)\n", - gw_tq_avg, orig_tq_avg); + gw_tq, orig_tq); deselect: gw_deselect(bat_priv); @@ -448,7 +448,7 @@ static int _write_buffer_text(struct bat_priv *bat_priv, struct seq_file *seq, ret = seq_printf(seq, "%s %pM (%3i) %pM [%10s]: %3i - %i%s/%i%s\n", (curr_gw == gw_node ? "=>" : " "), gw_node->orig_node->orig, - router->tq_avg, router->addr, + router->tq, router->addr, router->if_incoming->net_dev->name, gw_node->orig_node->gw_flags, (down > 2048 ? down / 1024 : down), @@ -647,7 +647,7 @@ bool gw_out_of_range(struct bat_priv *bat_priv, struct gw_node *curr_gw = NULL; bool ret, out_of_range = false; unsigned int header_len = 0; - uint8_t curr_tq_avg; + uint8_t curr_tq; ret = gw_is_dhcp_target(skb, &header_len); if (!ret) @@ -669,7 +669,7 @@ bool gw_out_of_range(struct bat_priv *bat_priv, case GW_MODE_SERVER: /* If we are a GW then we are our best GW. We can artificially * set the tq towards ourself as the maximum value */ - curr_tq_avg = TQ_MAX_VALUE; + curr_tq = TQ_MAX_VALUE; break; case GW_MODE_CLIENT: curr_gw = gw_get_selected_gw_node(bat_priv); @@ -687,7 +687,7 @@ bool gw_out_of_range(struct bat_priv *bat_priv, if (!neigh_curr) goto out; - curr_tq_avg = neigh_curr->tq_avg; + curr_tq = neigh_curr->tq; break; case GW_MODE_OFF: default: @@ -698,7 +698,7 @@ bool gw_out_of_range(struct bat_priv *bat_priv, if (!!neigh_old) goto out; - if (curr_tq_avg - neigh_old->tq_avg > GW_THRESHOLD) + if (curr_tq - neigh_old->tq > GW_THRESHOLD) out_of_range = true; out: diff --git a/originator.c b/originator.c index 0bc2045..99ede46 100644 --- a/originator.c +++ b/originator.c @@ -312,7 +312,7 @@ static bool purge_orig_neighbors(struct bat_priv *bat_priv, neigh_node_free_ref(neigh_node); } else { if ((!*best_neigh_node) || - (neigh_node->tq_avg > (*best_neigh_node)->tq_avg)) + (neigh_node->tq > (*best_neigh_node)->tq)) *best_neigh_node = neigh_node; } } @@ -448,7 +448,7 @@ int orig_seq_print_text(struct seq_file *seq, void *offset) if (!neigh_node) continue; - if (neigh_node->tq_avg == 0) + if (neigh_node->tq == 0) goto next; last_seen_secs = jiffies_to_msecs(jiffies - @@ -458,7 +458,7 @@ int orig_seq_print_text(struct seq_file *seq, void *offset) seq_printf(seq, "%pM %4i.%03is (%3i) %pM [%10s]:", orig_node->orig, last_seen_secs, - last_seen_msecs, neigh_node->tq_avg, + last_seen_msecs, neigh_node->tq, neigh_node->addr, neigh_node->if_incoming->net_dev->name); @@ -466,7 +466,7 @@ int orig_seq_print_text(struct seq_file *seq, void *offset) &orig_node->neigh_list, list) { seq_printf(seq, " %pM (%3i)", neigh_node_tmp->addr, - neigh_node_tmp->tq_avg); + neigh_node_tmp->tq); } seq_printf(seq, "\n"); diff --git a/routing.c b/routing.c index ef24a72..d76867e 100644 --- a/routing.c +++ b/routing.c @@ -160,7 +160,7 @@ void bonding_candidate_add(struct orig_node *orig_node, goto candidate_del; /* ... and is good enough to be considered */ - if (neigh_node->tq_avg < router->tq_avg - BONDING_TQ_THRESHOLD) + if (neigh_node->tq < router->tq - BONDING_TQ_THRESHOLD) goto candidate_del; /** @@ -552,7 +552,7 @@ static struct neigh_node *find_ifalter_router(struct orig_node *primary_orig, /* if we don't have a router yet * or this one is better, choose it. */ if ((!router) || - (tmp_neigh_node->tq_avg > router->tq_avg)) { + (tmp_neigh_node->tq > router->tq)) { /* decrement refcount of * previously selected router */ if (router) diff --git a/types.h b/types.h index e9eb043..84b9c59 100644 --- a/types.h +++ b/types.h @@ -127,7 +127,7 @@ struct neigh_node { uint8_t real_packet_count; uint8_t tq_recv[TQ_GLOBAL_WINDOW_SIZE]; uint8_t tq_index; - uint8_t tq_avg; + uint8_t tq; uint8_t last_ttl; struct list_head bonding_list; unsigned long last_valid; diff --git a/vis.c b/vis.c index cc3b9f2..6e155a4 100644 --- a/vis.c +++ b/vis.c @@ -572,8 +572,8 @@ static int find_best_vis_server(struct bat_priv *bat_priv, continue; if ((orig_node->flags & VIS_SERVER) && - (router->tq_avg > best_tq)) { - best_tq = router->tq_avg; + (router->tq > best_tq)) { + best_tq = router->tq; memcpy(packet->target_orig, orig_node->orig, ETH_ALEN); } @@ -644,7 +644,7 @@ static int generate_vis_packet(struct bat_priv *bat_priv) if (router->if_incoming->if_status != IF_ACTIVE) goto next; - if (router->tq_avg < 1) + if (router->tq < 1) goto next; /* fill one entry into buffer. */ @@ -654,7 +654,7 @@ static int generate_vis_packet(struct bat_priv *bat_priv) router->if_incoming->net_dev->dev_addr, ETH_ALEN); memcpy(entry->dest, orig_node->orig, ETH_ALEN); - entry->quality = router->tq_avg; + entry->quality = router->tq; packet->entries++; next: -- 1.7.1

1 4

Re: [B.A.T.M.A.N.] Problem to find better Route
by gtolon＠inti.gob.ar 16 Nov '11

16 Nov '11

Thank you for your answers. I copy the Originator's tables for the three nodes: A) (MAC: b2:48:7a:c8:a2:65) root@OpenWrt:/# batctl o [B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: wlan1/b2:48:7a:c8:a2:65 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 16:d6:4d:3a:3c:3c 0.790s (213) 16:d6:4d:3a:3c:3c [ wlan1]: 16:d6:4d:3a:3d:d8 (193) 16:d6:4d:3a:3c:3c (213) 16:d6:4d:3a:3d:d8 0.810s (255) 16:d6:4d:3a:3d:d8 [ wlan1]: 16:d6:4d:3a:3c:3c (190) 16:d6:4d:3a:3d:d8 (255) B) (MAC: 16:d6:4d:3a:3c:3c) root@OpenWrt:/# batctl o [B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: wlan1/16:d6:4d:3a:3c:3c (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... b2:48:7a:c8:a2:65 0.840s (235) b2:48:7a:c8:a2:65 [ wlan1]: 16:d6:4d:3a:3d:d8 (236) b2:48:7a:c8:a2:65 (235) 16:d6:4d:3a:3d:d8 0.640s (253) 16:d6:4d:3a:3d:d8 [ wlan1]: b2:48:7a:c8:a2:65 (205) 16:d6:4d:3a:3d:d8 (253) C) (MAC: 16:d6:4d:3a:3d:d8) root@OpenWrt:/# batctl o [B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: wlan1/16:d6:4d:3a:3d:d8 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 16:d6:4d:3a:3c:3c 0.060s (208) 16:d6:4d:3a:3c:3c [ wlan1]: b2:48:7a:c8:a2:65 (182) 16:d6:4d:3a:3c:3c (208) b2:48:7a:c8:a2:65 0.090s (234) b2:48:7a:c8:a2:65 [ wlan1]: 16:d6:4d:3a:3c:3c (182) b2:48:7a:c8:a2:65 (234) This is a typical state of the tables. We tryed setting the hop pennalty parameter to 1, but the behaviour hasn't changed. > ------------------------------ > > Message: 4 > Date: Tue, 15 Nov 2011 00:43:13 +0100 > From: Antonio Quartulli<ordex(a)autistici.org> > To: The list for a Better Approach To Mobile Ad-hoc Networking > <b.a.t.m.a.n(a)lists.open-mesh.org> > Subject: Re: [B.A.T.M.A.N.] Problem to find better Route > Message-ID:<20111114234312.GA28724(a)ritirata.org> > Content-Type: text/plain; charset=utf-8 > > Hello Gabriel, > > On Mon, Nov 14, 2011 at 04:53:22 -0300,gtolon(a)inti.gob.ar wrote: >> > Hi. We are using batman-adv 2011.2.0 with Openwrt Backfire-rc6 on D-Link >> > routers, and we're making some tests with iperf to measure bitrate >> > capabilities between nodes. When we put three nodes aligned we notice >> > that the obtained bitrate between the extreme nodes strongly depends on >> > the batman path between them. To make it clear, we have: >> > >> > A ---------- B ---------- C >> > >> > With a dinstance of about 20 meters between A and B, and the same >> > distance between B and C. The problem is that sometimes, A and C get >> > connected directly in terms of batman-adv protocol (checked with batctl >> > o), and when that happens, the bitrates are very poor (less than 1Mbps), >> > like if B wasn't there. In fact we disconnected B and obtained very >> > similar results. >> > >> > Then we reduced tx power settings on A and C, forcing the B hop between >> > them, and we got much better speeds (~20Mbps). We've read about ELP and >> > think that maybe simple OGM messages are not good to measure link >> > quility between A and C in this example, could that be the problem? In >> > that case is there a way to fix this with actual batman-adv algorithms? >> > Thanks in advance! >> > >> > Gabriel >> > > I think other people will give you better answer than this one, but just as > start: OGM are sent in broadcast, which by definition uses a low rate that > implies "better transmission than higher rates". > Therefore a link having an high TQ doesn't necessarily has a good quality at > "high rates" (as you are experiencing). > > In my opinion the problem resides in the fact that batman-adv uses broadcast > packets to measure link qualities which leads to the aforementioned problem. > > I don't know if ELP would help in this sense because as far as I know it still > uses broadcast packets. > > Please guys correct me if I am wrong. > > > Cheers, > > > > -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto > "Che" Guevara ------------------------------ Message: 5 Date: Tue, 15 > Nov 2011 09:40:36 +0800 From: Marek Lindner <lindner_marek(a)yahoo.de> > To: "The list for a Better Approach To Mobile Ad-hoc Networking" > <b.a.t.m.a.n(a)lists.open-mesh.org> Subject: Re: [B.A.T.M.A.N.] Problem > to find better Route Message-ID: > <201111150940.36605.lindner_marek(a)yahoo.de> Content-Type: Text/Plain; > charset="iso-8859-1" Hi, >> > With a dinstance of about 20 meters between A and B, and the same >> > distance between B and C. The problem is that sometimes, A and C get >> > connected directly in terms of batman-adv protocol (checked with batctl >> > o), and when that happens, the bitrates are very poor (less than 1Mbps), >> > like if B wasn't there. In fact we disconnected B and obtained very >> > similar results. > would you mind sharing the orignator tables of the involved nodes ? > > >> > Then we reduced tx power settings on A and C, forcing the B hop between >> > them, and we got much better speeds (~20Mbps). We've read about ELP and >> > think that maybe simple OGM messages are not good to measure link >> > quility between A and C in this example, could that be the problem? In >> > that case is there a way to fix this with actual batman-adv algorithms? > You can play with the hop penalty parameter to encourage batman to use fewer > or more hops (depending on your needs). > > Regards, > Marek > > > ------------------------------

3 3

[B.A.T.M.A.N.] Problem to find better Route
by gtolon＠inti.gob.ar 15 Nov '11

15 Nov '11

Hi. We are using batman-adv 2011.2.0 with Openwrt Backfire-rc6 on D-Link routers, and we're making some tests with iperf to measure bitrate capabilities between nodes. When we put three nodes aligned we notice that the obtained bitrate between the extreme nodes strongly depends on the batman path between them. To make it clear, we have: A ---------- B ---------- C With a dinstance of about 20 meters between A and B, and the same distance between B and C. The problem is that sometimes, A and C get connected directly in terms of batman-adv protocol (checked with batctl o), and when that happens, the bitrates are very poor (less than 1Mbps), like if B wasn't there. In fact we disconnected B and obtained very similar results. Then we reduced tx power settings on A and C, forcing the B hop between them, and we got much better speeds (~20Mbps). We've read about ELP and think that maybe simple OGM messages are not good to measure link quility between A and C in this example, could that be the problem? In that case is there a way to fix this with actual batman-adv algorithms? Thanks in advance! Gabriel El 14/11/2011 08:00 a.m., b.a.t.m.a.n-request(a)lists.open-mesh.org escribió: > Send B.A.T.M.A.N mailing list submissions to > b.a.t.m.a.n(a)lists.open-mesh.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n > or, via email, send a message with subject or body 'help' to > b.a.t.m.a.n-request(a)lists.open-mesh.org > > You can reach the person managing the list at > b.a.t.m.a.n-owner(a)lists.open-mesh.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of B.A.T.M.A.N digest..." > > > Today's Topics: > > 1. Re: [PATCH] add make install (Sven Eckelmann) > 2. Re: [PATCH] add make install (Sven Eckelmann) > 3. Re: [PATCH] add make install (Alexey Fisher) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 14 Nov 2011 11:21:12 +0100 > From: Sven Eckelmann<sven(a)narfation.org> > To: b.a.t.m.a.n(a)lists.open-mesh.org > Cc: lindner_marek(a)yahoo.de > Subject: Re: [B.A.T.M.A.N.] [PATCH] add make install > Message-ID:<1428522.agqKBYpyMC(a)sven-laptop.home.narfation.org> > Content-Type: text/plain; charset="iso-8859-1" > > On Monday 14 November 2011 10:38:07 Sven Eckelmann wrote: >> On Monday 14 November 2011 10:11:32 Alexey Fisher wrote: >>> Signed-off-by: Alexey Fisher<bug-track(a)fisher-privat.net> >>> --- >>> >>> Makefile | 3 +++ >>> 1 files changed, 3 insertions(+), 0 deletions(-) > [...] >> NAck: Sven Eckelmann<sven(a)narfation.org> > And also "Nack" for not updating the README [1] > > Kind regards, > Sven > > [1] http://www.open-mesh.org/wiki/open-mesh/Contribute#Submitting-patches >

3 2

[B.A.T.M.A.N.] batman-adv 2011.4.0 released
by Marek Lindner 14 Nov '11

14 Nov '11

The B.A.T.M.A.N. team is proud to announce its final milestone in 2011, 2011.4.0, concentrating on the stabilization & bug fixing of the recent protocol changes and adding 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.4.0/ as well as prepackaged binaries in your distribution. Thanks ------ Thanks to all people sending in patches: * Antonio Quartulli <ordex(a)autistici.org> * Joe Perches <joe(a)perches.com> * Jonathan Neuschäfer <j.neuschaefer(a)gmx.net> * Marek Lindner <lindner_marek(a)yahoo.de> * Martin Hundebøll <martin(a)hundeboll.net> * Simon Wunderlich <siwu(a)hrz.tu-chemnitz.de> batman-adv ---------- Above all, the 2011.4.0 milestone centers around polishing the protocol changes introduced with the previous release. Non-mesh clients connected via a wireless interface are marked as such. This information is then propagated in the mesh on top of the new non-mesh client infrastructure and can be used to prevent mesh wide wireless client to wireless client communication (on standard WiFi AccessPoints this feature is known as 'AP isolation'). The non- mesh client status flags (new/delete/purge/roaming/wireless) are exported to user space as part of the translation table output to allow following a client's status closely. The coming releases will be escorted by a stepwise inclusion of an improved version of our routing algorithm. It will be possible to switch between the current protocol and the new protocol at runtime in order to make testing as easy as possible. This first stage prepared the existing routing algorithm code for the upcoming feature for switching routing protocols. No changes to the routing code behavior have been included. A couple of translation table bugs have been squashed: memory leaks in the translation table, wrong initialization of ethernet addresses of translation table entries and a kernel crash on module unload. Numerous spelling mistakes in the source code comments were corrected. batctl ------ batctl received an option to turn on/off the aforementioned mesh wide AP isolation. When called with '-v' batctl will not only print its own version but also the batman-adv kernel module version (requires the module to be loaded). The log level section was rewritten, so that it now expects human readable log level definitions instead of digits and bitmasks. Also fixed was the mangled tcpdump output of the CRC value in translation table exchange packets. Happy routing, The B.A.T.M.A.N. team

1 0

[B.A.T.M.A.N.] [PATCH] batctl: update the tcpdump section in the README
by Marek Lindner 13 Nov '11

13 Nov '11

Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de> --- README | 23 ++++++++++++++--------- 1 files changed, 14 insertions(+), 9 deletions(-) diff --git a/README b/README index 442f8b6..cdeb2ed 100644 --- a/README +++ b/README @@ -84,21 +84,26 @@ traceroute to fe:fe:00:00:09:01 (fe:fe:00:00:09:01), 50 hops max, 19 byte packet batctl tcpdump =============== -tcpdump layer 2 traffic on the given interface +tcpdump layer 2 and/or layer 3 traffic on the given interface Usage: batctl tcpdump [options] interface [interface] options: -h print this help -n don't convert addresses to bat-host names -p dump specific packet type - 1 - batman ogm packets - 2 - batman icmp packets - 4 - batman unicast packets - 8 - batman broadcast packets - 16 - batman vis packets - 32 - batman fragmented packets - 64 - non batman packets - 65 - batman ogm & non batman packets + -x dump all packet types except specified +packet types: + 1 - batman ogm packets + 2 - batman icmp packets + 4 - batman unicast packets + 8 - batman broadcast packets + 16 - batman vis packets + 32 - batman fragmented packets + 64 - batman tt / roaming packets + 128 - non batman packets + 129 - batman ogm & non batman packets + +tcpdump supports standard interfaces as well as raw wifi interfaces running in monitor mode. Example output for tcpdump: -- 1.7.5.4

1 1

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