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
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
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
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
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
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
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
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
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
