B.A.T.M.A.N March 2011

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

19 participants
29 discussions

Re: [B.A.T.M.A.N.] TTL yes, TTL no
by Antonio Quartulli 26 Mar '11

26 Mar '11

On Sat, Mar 26, 2011 at 06:45:48PM +0100, Andrew Lunn wrote: > > I think it is wrong: TQ is not decremented by hop_penalty each time, but it is > > multiplied by (TQ_MAX-hop_penalty/TQ_MAX), then the number of hops is > > bigger than what you said. With hop_penalty = 10 we can probably reach > > ~135 hops (raw calculus 255*(TQ_MAX-hop_penalty/TQ_MAX)^135) =~ 0) > > I agree with the principle. However, you need to take rounding into > effect. The kernel does integer arithmetic and TQ is always an integer > value. I also got it wrong in my last post. I used the wrong round > function when calculating the values. Using rounddown() i get: > [cut] > > After 73 hops, TQ will be zero. You are right, my raw calculus was too raw :p > > > Looking at the calculus above, I'm proposing to use TTL = ~135 > > TTL of 73 would be more accurate i think. Yes. > > Which leads me to a new question. At WBM we talked about moving the > HNAs out of the OGMs. If we had a really big mesh, with more than 73 > hops from side to side, do we get into a situation where we have HNAs > from more than 73 hops away, but no idea how to route to them since > OGMs got dropped when TQ reached 0? > Mh..The HNA request is triggered by the TTVN carried into the OGM. Then a node far more than 73 hops should never ask for HNAs it cannot reach.. Moreover, a route toward a client is never allocated if we don't have its orig_node in our DB. Bye -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara

1 0

[B.A.T.M.A.N.] TTL yes, TTL no
by Antonio Quartulli 26 Mar '11

26 Mar '11

Hello folks! In these days I was wondering whether the TTL field in the OGM packet is really useful or not...Due to hop_penalty an OGM will be discarded as soon as the TQ will reach 0 (which is a sort of TTL mechanism itself). At this point why is the TTL field needed? Someone could probably say that a node far at least TTL hops will never be reached by a unicast packet, then it is meaningless to let it know about me. But then it could be possible to recalibrate the TTL such that it has to be equal to the maximum length in number of hops of the longest path the OGM can traverse. Bye! :) -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara

3 2

[B.A.T.M.A.N.] help
by Jose Armando 23 Mar '11

23 Mar '11

sorry im new to mesh n i would like to learn more about mesh can any one help me to build mesh software to install ubiquiti nano loco -- Armando Dieguez Phone 714.292.0156

2 1

[B.A.T.M.A.N.] Software editing of /etc/network/interfaces ?
by Kevin Steen 19 Mar '11

19 Mar '11

Anyone know if there are existing script functions to allow a Debian package to edit/add entries to /etc/network/interfaces ? I'm trying to create a package which someone can install to get them on the mesh, rather than a list of instructions on what to edit, etc. The key thing (AFAIK) is making sure everyone is on the same BSSID and channel. Anyone created this package for a batman_adv network already? On a related note, is the on-air format for batman_adv reasonably stable at the moment? If thousands of FreedomBoxen[1] were to start using it, what's the likelihood they would all have to upgrade to a new wire format in the near future? 1. http://wiki.debian.org/FreedomBox Thanks -Kevin

2 2

Re: [B.A.T.M.A.N.] New BMX website at www.bmx6.net
by Sven Eckelmann 15 Mar '11

15 Mar '11

Axel Neumann wrote: > > Does that mean that your svn directories and git repositories at > > open-mesh.org can be dropped > > In the long term yes! But please not right now. I want to update links in > other repositories like openWrt first and give users some time to update > their checkout as well so that the build process does not fail. Lets say > in February. Ok, sounds good. > > (at least it seems that no branch has common > > ancestors with your branches)? > > For branches/bmx-0.3.x/ I used git-svn to create the git repository which > I expected to create common ancestors. Some confusion leaked in when I > moved the directory from trunk/batman-experimental to branches/bmx-0.3.x > (some deleted files like LIESMICH,.. were not deleted which I fixed with > the last git commit). The problem is that you (sry, no offence meant) did a quite bad job to convert it. bmxd.git has these weird git-svn-id lines in the commit messages, "random" commiter names+mails, missing parts of the history, dangling symlinks, ... Please take a look at git://git.open-mesh.org/ecsv/test/bmx.git I don't say that it is the holy grail of svn-to-git conversation, but I think it could be a better conversation than your bmxd.git Best regards, Sven

2 3

[B.A.T.M.A.N.] Wireless Bridge
by A. AlBoori 15 Mar '11

15 Mar '11

Good Day all, I have Wireless DSL router and Open Mesh Router. Is it possible to bridge the Open Mesh Router with Wireless DSL router wirelessly to get the internet? Thank You

4 5

[B.A.T.M.A.N.] Batman-adv gateways vs IPv6
by Jan Lühr 15 Mar '11

15 Mar '11

Hello @all, I'm new to batman - so, sorry if this was discussed already... We're up to deploy batman-adv in an wireless mesh network with multiple routers / gateways providing access to the outside world. Furthermore deploying an IPv4 / v6 dual stack networking is one goals we're trying to archive. We stumbled up on batman-adv and its gateway feature, which looks quite promising. (http://www.open-mesh.org/wiki/batman-adv-gateways) However, since dhcp is used for implementing batman-adv gateways, this feature doesn't affect IPv6 ND / icmp6 - am I right? Having this in mind, what do you think is a suitable deployment strategy for IPv6 in batman-adv networks? Of course, assigning a single /64 to the mesh-cloud is a simple option, but icmp6 flooding might occur ... Thanks, Jan

2 3

[B.A.T.M.A.N.] Various fixes and clean-ups
by Linus Lüssing 14 Mar '11

14 Mar '11

Hi everyone, For one thing, I've changed the orig_node->router dereference as discussed on IRC, now using an extra getter method for that to reduce the lines of code for rcu-dereferencing, rcu-locking and refcounting for the router pointer and to make it easier to keep track of the right refcounting (Patch 4/5). Note, that the previous version was pretty simple, by just using rcu_dereference() everywhere. However, this current version is a little more invasive, so would be great if someone could double check that I didn't introduce any new mem-leaks or null-pointer-dereferences due to wrong refcounting. It already took me quite some time to find and squash two bugs I had introduced with this, so there might be even more in there. I double checked it myself and also tested it in a 4 node chain toplogy vm setup, though. For Patch 5/5, I've removed the "TQ value" from the patch subject. For the TQ window locking is definitely needed, whether tq_avg needs locking as well still needs to be checked. If so, that could be done with a separate patch though. Patches 1,2,3 are just some smaller changes. Let me know what you think about them. Cheers, Linus

2 6

[B.A.T.M.A.N.] Maintainer of vis and batmand
by elektra 10 Mar '11

10 Mar '11

Hi Sven - AFAIK *vis* has no maintainer at the moment. I am currently working on the routing loop issue in batmand and link-local OGM aggregation, in order to improve scalability. Will do some testing at the Battlemesh. Cheers, Elektra

3 5

[B.A.T.M.A.N.] [Patch] vis: Modified format of JSON output.
by elektra 10 Mar '11

10 Mar '11

The current vis server JSON output format is breaking the json_decode() function for PHP. This patch mainly: - Removes all spaces - Removes all the \t TABS - Double quotes the string-variables Reported-by: "Alberto Escudero-Pascual" <aep(a)it46.se> Signed-off-by: "elektra" <onelektra(a)gmx.net> --- vis.c 2011-03-09 17:19:59.000000000 +0100 +++ new/vis.c 2011-03-09 17:15:26.000000000 +0100 @@ -88,19 +88,21 @@ if ( fork() ) exit(EXIT_SUCCESS); - chdir( "/" ); + if (chdir( "/" )==0) { - if ( ( fd = open(_PATH_DEVNULL, O_RDWR, 0) ) != -1 ) { + if ( ( fd = open(_PATH_DEVNULL, O_RDWR, 0) ) != -1 ) { - dup2(fd, STDIN_FILENO); - dup2(fd, STDOUT_FILENO); - dup2(fd, STDERR_FILENO); + dup2(fd, STDIN_FILENO); + dup2(fd, STDOUT_FILENO); + dup2(fd, STDERR_FILENO); - if ( fd > 2 ) - close(fd); + if ( fd > 2 ) + close(fd); + } + } else { + exit_error( "Error - can't chdir\n"); } - return 0; } @@ -395,7 +397,7 @@ fillme->dot_buffer = (char *)debugRealloc( fillme->dot_buffer, strlen( tmp ) + strlen( fillme->dot_buffer ) + 1, 408 ); strncat( fillme->dot_buffer, tmp, strlen( tmp ) ); - snprintf( tmp, sizeof( tmp ), "%s\t{ router : \"%s\", neighbour : \"%s\", label : %.2f }", + snprintf( tmp, sizeof( tmp ), "%s{\"router\":\"%s\",\"neighbour\":\"%s\",\"label\":%.2f}", (first_line ? "" : ", \n"), from_str, to_str, (float)( orig_node->tq_max / (float)neigh->tq_avg ) ); first_line = 0; fillme->json_buffer = (char *)debugRealloc( fillme->json_buffer, strlen( tmp ) + strlen( fillme->json_buffer ) + 1, 408 ); @@ -416,7 +418,7 @@ fillme->dot_buffer = (char *)debugRealloc( fillme->dot_buffer, strlen( tmp ) + strlen( fillme->dot_buffer ) + 1, 409 ); strncat( fillme->dot_buffer, tmp, strlen( tmp ) ); - snprintf( tmp, sizeof( tmp ), "%s\t{ router : \"%s\", gateway : \"%s/%s\", label : \"HNA\" }", + snprintf( tmp, sizeof( tmp ), "%s{\"router\":\"%s\",\"gateway\":\"%s/%s\",\"label\":\"HNA\"}", (first_line ? "" : ",\n"), from_str, to_str, hna_str ); first_line = 0; fillme->json_buffer = (char *)debugRealloc( fillme->json_buffer, strlen( tmp ) + strlen( fillme->json_buffer ) + 1, 409 ); @@ -432,7 +434,7 @@ strncat( fillme->dot_buffer, tmp, strlen( tmp ) );

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N March 2011