B.A.T.M.A.N November 2011

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

17 participants
45 discussions

[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

[B.A.T.M.A.N.] [PATCH] batctl: modify tt sections in the README
by Antonio Quartull 13 Nov '11

13 Nov '11

translocal and transglobal section updated in the README file Signed-off-by: Antonio Quartull <ordex(a)autistici.org> --- README | 45 +++++++++++++++++++++++++++++++++++---------- 1 files changed, 35 insertions(+), 10 deletions(-) diff --git a/README b/README index 442f8b6..fc0a85e 100644 --- a/README +++ b/README @@ -313,7 +313,21 @@ Example: $ batctl translocal Locally retrieved addresses (from bat0) announced via TT: - * d6:e0:fd:d9:00:00 + * d6:e0:fd:d9:00:00 [RPNXW] + +In particular, RPNXW are flags which have the following meanings: + +- R/Roaming: this client moved to another node but it is still kept for + consistency purposes up to the next OGM sending. +- P/noPurge: this client represents the local soft interface and has to never be + deleted. +- N/New: this client has recently been added but it has to not be advertised up + to the next OGM sending (for consistency purposes). +- X/delete: this client has to be removed for some reason, but it is still kept + for consistency purposes up to the next OGM sending. +- W/Wireless: this client is connected to the node through a Wireless device. + +If any of the flags is not enabled, a '.' will substitute its symbol. batctl transglobal ================== @@ -324,15 +338,26 @@ Usage: batctl transglobal|tg Example: -Globally announced TT entries received via the mesh (translation table): - * 16:aa:c4:a2:00:00 via fe:fe:00:00:09:01 - * 5a:32:f9:df:00:00 via fe:fe:00:00:03:01 - * 32:ae:5a:00:00:00 via fe:fe:00:00:04:01 - * 86:88:80:29:00:00 via fe:fe:00:00:08:01 - * 9e:d8:72:f2:00:00 via fe:fe:00:00:02:01 - * 76:84:68:49:00:00 via fe:fe:00:00:05:01 - * 86:4b:b2:d2:00:00 via fe:fe:00:00:07:01 - * ca:a1:5b:e5:00:00 via fe:fe:00:00:06:01 +Globally announced TT entries received via the mesh bat0 + Client (TTVN) Originator (Curr TTVN) Flags + * 16:aa:c4:a2:00:00 ( 12) via fe:fe:00:00:09:01 ( 50) [RXW] + +where: +- TTVN: is the translation-table-version-number which introduced this + client +- Curr TTVN: is the translation-table-version-number currently advertised by + the originator serving this client (different clients + advertised by the same originator have the same Curr TTVN) +- Flags that mean: + - R/Roaming: this client moved to another node but it is still kept for + consistency purposes up to the next OGM received from its + originator + - X/delete: this client has to be removed for some reason, but it is + still kept for consistency purposes. + - W/Wireless: this client is connected to the node through a Wireless + device. + +If any of the flags is not enabled, a '.' will substitute its symbol. batctl vis_mode ================= -- 1.7.3.4

2 1

[B.A.T.M.A.N.] [PATCH] batctl: correct batctl ll output
by Antonio Quartull 13 Nov '11

13 Nov '11

Since batctl has moved to a human-readable loglevel name, either 'batctl ll' output should be coherent to this change. This patch correct it by substituting the old numbers with the human-readable strings Signed-off-by: Antonio Quartull <ordex(a)autistici.org> --- sys.c | 17 +++++++++-------- 1 files changed, 9 insertions(+), 8 deletions(-) diff --git a/sys.c b/sys.c index bddaaa3..e510bee 100644 --- a/sys.c +++ b/sys.c @@ -237,14 +237,15 @@ int handle_loglevel(char *mesh_iface, int argc, char **argv) log_level = strtol(line_ptr, (char **) NULL, 10); - printf("[%c] %s (%d)\n", (!log_level) ? 'x' : ' ', - "all debug output disabled", 0); - printf("[%c] %s (%d)\n", (log_level & 1) ? 'x' : ' ', - "messages related to routing / flooding / broadcasting", 1); - printf("[%c] %s (%d)\n", (log_level & 2) ? 'x' : ' ', - "messages related to route added / changed / deleted", 2); - printf("[%c] %s (%d)\n", (log_level & 4) ? 'x' : ' ', - "messages related to translation table operations", 4); + printf("[%c] %s (%s)\n", (!log_level) ? 'x' : ' ', + "all debug output disabled", "none"); + printf("[%c] %s (%s)\n", (log_level & 1) ? 'x' : ' ', + "messages related to routing / flooding / broadcasting", + "batman"); + printf("[%c] %s (%s)\n", (log_level & 2) ? 'x' : ' ', + "messages related to route added / changed / deleted", "routes"); + printf("[%c] %s (%s)\n", (log_level & 4) ? 'x' : ' ', + "messages related to translation table operations", "tt"); out: if (errno == ENOENT) -- 1.7.3.4

2 1

[B.A.T.M.A.N.] [PATCH] batman-adv: readme update (mention ap isolation and new log level)
by Marek Lindner 09 Nov '11

09 Nov '11

Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de> --- README | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/README b/README index a9ae038..7bcc9f4 100644 --- a/README +++ b/README @@ -83,9 +83,9 @@ All mesh wide settings can be found in batman's own interface folder: # ls /sys/class/net/bat0/mesh/ -# aggregated_ogms gw_bandwidth hop_penalty -# bonding gw_mode orig_interval -# fragmentation gw_sel_class vis_mode +# aggregated_ogms fragmentation gw_sel_class vis_mode +# ap_isolation gw_bandwidth hop_penalty +# bonding gw_mode orig_interval There is a special folder for debugging information: @@ -219,15 +219,16 @@ abled during run time. Following log_levels are defined: 0 - All debug output disabled 1 - Enable messages related to routing / flooding / broadcasting -2 - Enable route or tt entry added / changed / deleted -3 - Enable all messages +2 - Enable messages related to route added / changed / deleted +4 - Enable messages related to translation table operations +7 - Enable all messages The debug output can be changed at runtime using the file /sys/class/net/bat0/mesh/log_level. e.g. # echo 2 > /sys/class/net/bat0/mesh/log_level -will enable debug messages for when routes or TTs change. +will enable debug messages for when routes change. BATCTL -- 1.7.5.3

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N November 2011