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
---------- Forwarded message ----------
From: hlabishi kobo <hlabishik(a)gmail.com>
Date: Sun, 28 Nov 2010 22:06:01 +0200
Subject: Fwd: BATMAN routing
To: lindner_marek(a)yahoo.de
Hi
Thank you very much for your reply. The reason why i sent this to you and
your colleague is that i have tried the mail list before and all my post
kept on being returned, i used this address
b.a.t.m.a.n-owner(a)lists.open-mesh.org. I would really appreciate it if this
can reach the mailing list public (i will keep on trying). i will send you a
follow up on the full explanation of the concept like you requested.
Regards
Hlabishi
---------- Forwarded message ----------
From: <b.a.t.m.a.n-owner(a)lists.open-mesh.org>
Date: Sat, Nov 27, 2010 at 12:58 AM
Subject: Fwd: BATMAN routing
To: hlabishik(a)gmail.com
Message rejected by filter rule match
---------- Forwarded message ----------
From: hlabishi kobo <hlabishik(a)gmail.com>
To: b.a.t.m.a.n(a)lists.open-mesh.org
Date: Sat, 27 Nov 2010 00:58:09 +0200
Subject: Fwd: BATMAN routing
---------- Forwarded message ----------
From: Marek Lindner <lindner_marek(a)yahoo.de>
Date: Fri, Nov 26, 2010 at 5:23 PM
Subject: Re: BATMAN routing
To: hlabishi kobo <hlabishik(a)gmail.com>, Linus Lüssing <
linus.luessing(a)web.de>
Cc: siwu(a)hrz.tu-chemnitz.de
Hi,
welcome to the project! :-)
> Firstly my apologies for sending this email to your personal email. My
name
> is Hlabishi Isaac Kobo at the, an Msc computer science student at the
> University of the Western Cape in South Africa, I am doing a research on
> routing in a hybrid (combination of static and mobile dynamic routers)
> mesh.
I don't see a good reason to apologize, just wondering why you are not
sending
this mail to the public list ?
> I want to use the mesh potatoes as well as the batphone (android
> version of batman) to create a mesh model.
What is the "batphone" ? A project name or a nick name you invented ? :-)
Note: Various tests have shown that running a mobile device
(smartphone/tablet/etc) in adhoc mode plus running a mesh protocol on top is
a
battery killer, hence not practical in real world scenarios (in addition of
the hassle to install and configure the mesh software on each and every
device). This was one of the main reasons to start developing batman-adv as
it
allows mobile devices to take advantage of the mesh (e.g. roaming) without
having to run the mesh on the device itself.
You might be aware of this - I am just mentioning it because many people are
not.
> First we say the recently received OGMs will give a clear indication on
the
> reliability on the link, so we give the recently received OGMs from the
> sliding window a priority in deciding the best next hop link towards a
> destination. We want to count and add the indexes were an OGM was recorded
> in an interval (seconds), (hence the recently received OGM will have more
> weight). At the end the link with more recent OGMs will have more weight
> and hence become the current best link.
This is a good idea. We are in the process of redesigning the current
protocol
and welcome any input. Giving older OGMs less "weight" was also one of the
ideas we had. Would you mind explaining your concept in greater detail ?
> I went through the source code so many times and I got few questions about
> this:
Are we talking about the batman daemon source code or the batman-adv kernel
module ? All my answers will refer to the kernel module as this is the place
where most of the development is going on at the moment.
> 1. What structure is used to keep track of the sliding window? If its the
> has how does it get updated based on the sliding packet range?
Each "struct orig_node" has a bitarray to keep track of its own seqnos
repeated by its neighbors (bcast_own) and each "struct neigh_node" having a
bitarray for its own OGMs (real_bits).
> 2. How are the OGM's recorded, is in a form of binary where 1 will
> represent the received OGM and 0 otherwise?
Correct.
> 3. I looked in the source and still not sure of where the ranking
decisions
> are made, can you enlighten me on that?
You mean which function changes the route when a better neighbor was found ?
That would be update_orig() in routing.c.
> On the second approach we want to use mac layer stats to estimate the
> signal strength and probably the congestion rate of the top N ranked
links.
> We acknowledge the fact that usually links with lower signal strength will
> loose more OGM's which results in an automatic low rank, however in a
> frequently changing topology, current signal strength is crucial. We plan
> to use SNR or RSSI in this case.
The concept is known since a while but nobody has implemented it so far
because its implementation is fairly complex. Do you have an idea how it
should work in the end ?
> 1. How can i get the RSSI/LQI of th neighbor links?
I don't get this question. You intend to use RSSI but you don't know how ?
> I would really appreciate your opinions and advices in this regard more
> specially how to go about implementing changes in BATMAN protocol.
This is a little abstract. Usually, we discuss specific concepts / ideas in
our
IRC channel or on the mailing list long before starting to implement them.
The
past has shown it is often better to let other people dive into your ideas
and
comment because routing is a rather complex subject.
As I mentioned above: We are in a redesign phase right now and welcome
anyone
interested to join. As the next step we envisioned a collection of routing
scenarios in which the current implementation behaves poorly. All routing
protocol changes have to go through this collection of scenarios to estimate
its impact. What do you think about this idea ?
Regards,
Marek
Wireless Battle Mesh v4 - Call for papers
=========================
Wireless Battle Mesh v4 is at hand and it is time to bring together the
agenda. To avoid last year's dynamic process which gave us a true talk
marathon on the very last day of WBMv3 all talks / workshops / panel
discussions shall be announced beforehand.
Tracks
====
In order to broaden the horizon of the event we are going to split the event
into different tracks:
* The technical track is taking place throughout the week (monday till friday)
which mainly focuses on rather technical topics like:
=> routing protocol internals
=> implementations / development of "cool" algorithms
=> hands-on routing / multicast / roaming / convergence speed / etc
=> secuity aspects in mesh networks
=> your idea here
* The weekend (saturday & sunday) is reserved for the applications track which
aims to showcase applications that run on top of the mesh. It is not important
whether protocol X or Y is deployed and how it is implemented, the question
is: What can we do with the mesh once it is there ?
=> VoIP in the mesh ?
=> fast desaster recovery ?
=> artistic projects ?
=> your idea here
The idea of these tracks is to provide a ground for the different developers /
projects to exchange ideas on technical aspects of algorithms /
implementations / optimizations as well as organizing an exchange with mesh
network users who care less about how the mesh itself works as long as their
application can do its job. On the other hand the weekend serves as an entry
point for people to learn about what you can actually do with mesh networks.
Submission
=======
To allow an efficient handling of your submission, please provide the following
information and send them to me directly in form of an email:
* your name
* the track you are interested in
* the type of your slot (talk/workshop/panel discussion)
* your topic headline
* your topic description which can brief (does not need to exceed a couple of
lines) but should provide a reasonable summary of your talk
* the dates of your stay at the event + (optional) preferred day for your slot
* length of the slot if you wish to do a workshop (all other slots will be
limited to one hour - notify me in advance if you think that is not enough for
you)
Deadlines
======
Submissions are accepted until and including the 28th of February. Everyone
missing this deadline still has the opportunity to apply for a lightening talk
slot. These slots can be acquired by simply contacting me during the event.
The list of registered lightening talks will be published in the battlemesh
wiki.
The final program will be made available in the aforementioned wiki during the
first week of March.
If you have any question or suggestion, please let me know.
Regards,
Marek
Hello to everyone,
This is the second version of the HNAs announcement mechanism/Roaming
management paper. Please, consider it still a draft.
A lot of things have changed since the previous version of this paper.
As usual, feel free to comment it. I'll wait for your feedback :)
Link:
http://www.open-mesh.org/attachment/wiki/hna-improvements/handover.pdf
Ragards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
Hi,
I told Linus and Marek that the implementation of some datastructures using
reference counting and RCUs must be redesigned. The problem is that call_rcu
should only be used when the reference count is zero because multiple call_rcu
cannot be initiated at the same time. The next problem is that we may try to
access an element with the refcount 0 when we try to traverse a rcu protected
list. This problem cannot be solved by kref - thus we have to use atomic_t
again to _not_ increase the reference count when it was already zero.
Marek asked me what we must change - I try to summarize those things in the
following patches. They aren't tested and should only be seen as suggestions
what must be done to finish the "remove orig_hash lock"-patches.
If you try these patches then please keep in mind that they will sell your soul
to the next confectioner (for some cookies or a pie).
More information can be found inside Documentation/RCU/rcuref.txt
Btw, maybe I've found a bug inside the find_router with enabled bonding (see
"BUG" in patch 4).
Best regards,
Sven
Hi,
I have a special question on confgurating our batman advanced setup.
We have a Tinc VPN on tap0, and behind this VPN is a dhcp server and an
internet gateway which is reachable trough the ip 10.18.0.1.
On the router I have ath1, an adhoc wlan device, on which batman advanced is
sending packagets. Now bat0 and tap0 are brindged to br-mesh. Like you can see
in the configuration:
root@Floh:~# cat /etc/config/network
[...]
config 'interface' 'mesh'
option 'type' 'bridge'
option 'ifname' 'bat0 tap0'
option 'stp' '1'
[...]
root@Floh:~# cat /etc/config/batman-adv
config 'mesh' 'bat0'
option 'interfaces' 'ath1'
option 'orig_interval'
option 'log_level'
[batman]
[client]-->[adhoc ath1]-->[bat0][br-mesh][tap0]-->internet-->[gateway/dhcp]
Other nodes running the same configuration but not connecting trought vpn can
connect to the dhcp server through batman advanced and the adhoc device.
If a client (laptop) without batman advanced tries to connect, it has no
success because it does not get an I address.
What can I do?
I can not open a second wifi device in ap mode and add it to mesh. I know that
this would be the best way but I´m trying this on an wrt54g and the b43 driver
does not support multi essid.
Regards
Clemens
Hi there,
I found an interesting paper today that covers mobility of some nodes in
a batman-adv network:
> Stefano Annese, Claudio Casetti, Carla F. Chiasserini, Paolo
> Cipollone, Andrea Ghittino, and Massimo Reineri. 2009. Assessing
> mobility support in mesh networks. In Proceedings of the 4th ACM
> international workshop on Experimental evaluation and
> characterization (WINTECH '09).
http://portal.acm.org/citation.cfm?id=1614297
Unfortunately, the paper is not freely available on the web. If you're
blessed with access to the ACM digital library by your school or
employer, you can download it free of charge; in other cases you'll have
to buy it for USD 15.
In the following, I will summarize relevant parts:
I) Weighting the local packet count
The authors found that when each entry in the sliding window is weighed
with the same weight as it is done in the current version of batman-adv,
routing loops can occur when mobility is present. They greatly improve
their results by weighting with the following function (i = 0..S-1 where
S is the window size; 0 means freshest packet):
weight(i) := max(1, floor(i * S / e^i))
This function seems to be suboptimal as it weights entry 0 with 1 while
the following few entries are boosted with a weight of up to 20 (see
attachment). Adding 1 to i should deal with this flaw.
However, this weighting function lead to big improvements in the
authors' simulations, so I think you are on the right track when
thinking about introducing some kind of weighting or moving average to
boost the weight of current packets.
Here's the Octave/Matlab code I used to create the plot (if you want to
do plots for other weighting functions that are discussed, just replace
the definition of w and don't forget to use .* and ./ instead of * and /
to enforce elementwise operations):
> x = 0:63
> w = max(1, x.*64./exp(x))
> stem(x,w)
> xlabel('age')
> ylabel('weight')
II) Optimizations for multi-interface nodes
The authors used nodes with 2 radios. They did roughly the following on
the mobile nodes (not on the fixed ones):
1) In regular intervals, scan the forwarding tables for each interface
to check if any neighbors are known. If an interface has no contact to
any neighbor, go to 2)
2) Use the interface without known neighbors to scan all channels except
the channel that the other interface is listening to. Don't send OGMs
but simply listen for OGMs from other stations. If a channel is found
that has a neighbor sending, stay on this channel and start to behave
like a normal batman-adv node (send OGMs etc.).
I'm not sure if this will be benefitial in other scenarios than in the
vehicular network scenario of the paper, but I wanted to share my
findings with you.
- Daniel
Hi,
I would like to propose following changes for net-2.6.git/2.6.38 which fixes
some bugs in the fragmentation and vis code. There are also some minor cleanup
patches available. If you don't want to merge those cleanup patches then please
look bellow the first diffstat for an alternative way to get only the bugfixes.
thanks,
Sven
The following changes since commit aa0adb1a85e159cf57f0e11282bc6c9e3606a5f3:
batman-adv: Use "__attribute__" shortcut macros (2011-01-16 03:25:19 +0100)
are available in the git repository at:
git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/merge
Linus Lüssing (1):
batman-adv: Fix kernel panic when fetching vis data on a vis server
Simon Wunderlich (1):
batman-adv: remove unused parameters
Sven Eckelmann (11):
batman-adv: Create roughly equal sized fragments
batman-adv: Calculate correct size for merged packets
batman-adv: Remove vis info on hashing errors
batman-adv: Remove vis info element in free_info
batman-adv: Make vis info stack traversal threadsafe
batman-adv: Remove dangling declaration of hash_remove_element
batman-adv: Remove unused definitions
batman-adv: Remove declaration of batman_skb_recv
batman-adv: Remove unused variables
batman-adv: Update copyright years
batman-adv: Merge README of v2011.0.0 release
Documentation/networking/batman-adv.txt | 16 ++++++++--------
net/batman-adv/Makefile | 2 +-
net/batman-adv/aggregation.c | 2 +-
net/batman-adv/aggregation.h | 2 +-
net/batman-adv/bat_debugfs.c | 6 ++----
net/batman-adv/bat_debugfs.h | 2 +-
net/batman-adv/bat_sysfs.c | 2 +-
net/batman-adv/bat_sysfs.h | 2 +-
net/batman-adv/bitarray.c | 2 +-
net/batman-adv/bitarray.h | 2 +-
net/batman-adv/gateway_client.c | 2 +-
net/batman-adv/gateway_client.h | 2 +-
net/batman-adv/gateway_common.c | 2 +-
net/batman-adv/gateway_common.h | 2 +-
net/batman-adv/hard-interface.c | 13 ++++++++++---
net/batman-adv/hard-interface.h | 6 +-----
net/batman-adv/hash.c | 2 +-
net/batman-adv/hash.h | 7 +------
net/batman-adv/icmp_socket.c | 2 +-
net/batman-adv/icmp_socket.h | 2 +-
net/batman-adv/main.c | 2 +-
net/batman-adv/main.h | 17 +----------------
net/batman-adv/originator.c | 4 ++--
net/batman-adv/originator.h | 2 +-
net/batman-adv/packet.h | 3 ++-
net/batman-adv/ring_buffer.c | 2 +-
net/batman-adv/ring_buffer.h | 2 +-
net/batman-adv/routing.c | 26 ++++++++------------------
net/batman-adv/routing.h | 5 ++---
net/batman-adv/send.c | 6 +++---
net/batman-adv/send.h | 2 +-
net/batman-adv/soft-interface.c | 2 +-
net/batman-adv/soft-interface.h | 2 +-
net/batman-adv/translation-table.c | 2 +-
net/batman-adv/translation-table.h | 2 +-
net/batman-adv/types.h | 2 +-
net/batman-adv/unicast.c | 15 ++++++++++-----
net/batman-adv/unicast.h | 25 ++++++++++++++++++++++++-
net/batman-adv/vis.c | 16 +++++++++-------
net/batman-adv/vis.h | 2 +-
40 files changed, 109 insertions(+), 108 deletions(-)
If you don't want to merge those cleanup patches, please merge only the
bugfixes. They can be found in the branch batman-adv/merge-bugfixonly.
The following changes since commit aa0adb1a85e159cf57f0e11282bc6c9e3606a5f3:
batman-adv: Use "__attribute__" shortcut macros (2011-01-16 03:25:19 +0100)
are available in the git repository at:
git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/merge-bugfixonly
Linus Lüssing (1):
batman-adv: Fix kernel panic when fetching vis data on a vis server
Sven Eckelmann (5):
batman-adv: Create roughly equal sized fragments
batman-adv: Calculate correct size for merged packets
batman-adv: Remove vis info on hashing errors
batman-adv: Remove vis info element in free_info
batman-adv: Make vis info stack traversal threadsafe
net/batman-adv/packet.h | 1 +
net/batman-adv/routing.c | 2 +-
net/batman-adv/unicast.c | 13 +++++++++----
net/batman-adv/unicast.h | 23 +++++++++++++++++++++++
net/batman-adv/vis.c | 14 ++++++++------
5 files changed, 42 insertions(+), 11 deletions(-)
Hi everyone,
Here's the next series of patches which should address the comments I got for the
first one. Thanks for all the feedback!
Changelog:
* rebasing to commit [65e0869478bce153a799c0e774a117ba5fc78025],
using new orig_hash methods
* putting seqno before ttl, 4 byte aligning mcast_packet [01/20]
* adapted compat.h to not use custom lock macros, instead only one macro for
netif_addr_lock_bh() in case of older kernel versions
* merged spinlock-irqsave-to-bh commit into previous commits [20/20]
* moved mcast_may_optimize() to soft-interface.c [18/20], removed inlining
(won't optimize much anyway...)
* purge_mcast_forw_table, splitted list operations into separate functions
[12/20]
* use batman_if refcounting to reduce the time of rcu-locking [13/20]
* do not create nexthop entry if according batman_if is NULL [13/20]
* route_mcast_packet, split into separat functions [13/20]
* fix typo "seperate" [13/20]
* fix typo "i.g." [08/20]
* COMPAT_VERSION to 14 [01/20]
* use rcu-locking+refcounting for orig_node, remove orig_hash_lock [07/20],
[17/20]
* made checkpatch-clean
* use __packed instead of __attribute_((packed)) [01/20]
* change tracker_packet_for_each_dest macro [07/20]:
make a "break" in this macro to behave like usual, export parts from macro
into own functions
TODO:
* directly prepare mcast-tracker-packet in sk_buff
* only create methods / variables in patches that need them
* update mcast-doc
* upload updated mcast-doc to wiki
maybe TODO?
* use hlist instead of list for mcast-table?
* use rcu-locking / refcounting for mcast_forw_table?
Cheers, Linus