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
@@ -83,9 +83,9 @@ All mesh wide settings can be found in batman's own interface
# 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
# 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.
i thought it was a good idea to move the functions "start_mesh" and
"stop_mesh" from /etc/init.d/batman-adv script to a new file in
openwrt style "/lib/batman-adv/config.sh".
With this improvment it possible to recycle this two function to
operate with an hotplug script so when network restart, all batman
interface will be reconfigured automatically and I just work to do
In this mail you can find batman-adv initscript updated to work in
this way and the batman-adv library file that must be located in
Any comment are apprecciated
i have setup a mesh-network with batman-adv running on about 10 Foneras
and 4 TP-Link on OpenWRT.
At first everything seemed to work. A node on the one end could ping a
node on the other end over the mesh-network. The ping was hopping from
node to node as expected.
But sometimes some paths do not work anymore.
Some nodes can only reach their direct neighbors via a "normal ping". A
ping to a node via one hop does not work. A "batctl ping" does work!
This only happens to parts of the network and is not permanent. If i
wait it will recover, but then the problem appears at another node.
dmesg or the syslog does not report any errors.
Can anyone give me a hint where to look?
I don't known if this is a old argument but exsist the possibility to
implement a secure mesh network?
For example a tecnique that crypt batman-adv traffic with a preshare
key or similar or
using ebtables to block all INPUT and OUTPUT traffic and allow only
the specified nodes mac?
On Friday 26 August 2011 15:32:37 Hrushi Mehendale wrote:
> Hi Sven,
> Thank you very much for your frank comments about the code.
Another comment about your mail: Don't send html to the mailing list... it
will be dropped.
> Hopefully, with help from experienced programmers such as you and many
> others whom we may not even know, we would be able to improve the code
> quality. The prototype is just out of our research lab and as you pointed
> out, the code needs to be fine tuned now. Apart from building the prototype,
> majority of our efforts have been spent on porting LifeNet across different
> hardware and OS platforms, in order to validate our baseline claims of
> hardware and OS interoperability.
I doubt that it has something to do with fine tuning. There are just simple
things which you should not do: For example accessing memory after you free'd
the memory region.
> Do you have any suggestions for us to facilitate better interaction with the
> community, particularly to make sure LifeNet adhers to best programming
> practices / standards?
A nasty comment would be: learn coding
But honestly, you should get in contact with good kernel programmer which can
work for you. It is not a "community" thing, but understanding what you are
actually doing. I think those papers are a good example. You seem to
understand your problem and try to find a solution. But the problem is that
you are not the persons which understand the actual implementation stuff. So
maybe there is a operating system department at your university which has
experienced people and can help to implement your ideas.
Not that I have a problem with research code... but selling it to
organisations and knowing that it has ugly bugs seems not to be a good idea
(at least from my point of view).
I have batman-adv 2011.1.0 on two machines connected via wifi in adhoc
mode. As expected the bat0 virtual interface can be configured to set
an ipv4 address.
I used ifconfig bat0 10.42.43.1 and ifcondif bat0 10.42.43.2 on two machines.
However, the documentation says that bat0 can be assigned Avahi/zeroconf.
Could anyone give me an idea how to assign via Avahi/zeroconf.
Hi batman developers,
Clara Gnos suggested that I write to the list to make a case for
batman + 802.11s integration. As you probably know, 802.11s is the
upcoming wireless mesh standard from IEEE. The current version of the
draft was approved by the IEEE 802 Executive Committee in July and
will be ratified next month. open80211s (http://o11s.org) is an open
implementation of 802.11s that's in the kernel mainline since 2.6.26.
802.11s uses HWMP as its default routing (path selection, in
11s-speak) protocol. All 11s implementations must support this
default, and this is what's implemented in open80211s. The 11s spec
also defines an extensible framework to support other path selection
protocols and custom metrics. open80211s supports these by providing
userspace hooks for custom path selection daemons.
Which brings me to the main point of my e-mail: is anyone out there
interested in porting batman's path selection algorithm into
1. By being based on a standard, you'll know you won't be colliding
with other layer 2 technologies (for instance, no need to define your
2. You can leverage most of open80211s, from test tools to wireshark patches.
3. By being integrated in the kernel's 802.11 stack, you can take
advantage of the development that's taking place there, from encrypted
management frames to HT support.
4. You can reach out to a larger development community and raise
awareness about batman.
5. A big problem in mesh adoption on Linux is not the mesh protocol
itself but the absence of simple to use configuration tools (e.g. no
mesh support in ConnMan, NetworkManager, etc.). By providing a
unified wireless mesh framework we increase the likelihood of having
some support at the distro level.
and last, but not least...
6. You'll be able to say authoritatively that batman is X times more
efficient than HWMP (pick any X greater than 1 :)
Anyway, that was just a thought. If anyone is interested let me know.
On Thu, Aug 25, 2011 at 09:36:14AM +0800, Yeoh Chun-Yeow wrote:
> Hi, all,
> Although batman-adv is a layer 2 routing that works across multiple access
> technologies (not so sure about other technologies, because it mainly use
> for WiFi), but it only make senses if we configure the wireless interface
> operating in adhoc or adhocdemo mode. If we configure the wireless interface
> as Infrastructure mode, all the traffic will go to the AP first, even if we
> can direct communicate between the two STAs.
> Correct me if I am wrong.
Ideally, you have BATMAN on the AP as well as the STA. So you never do
STA->AP->STA hops between BATMAN nodes, you only do a STA->AP BATMAN
hop followed by a AP->STA BATMAN hop. Performing two BATMAN hops means
BATMAN knows the transmit quality of each of the two wireless hop, not
the combined transmit quality of the STA->AP->STA path. So BATMAN
running on the AP can then decide if it makes sense to take a
There is code to enforce this, i.e. blocking STA->AP->STA transfers,
in the development tree and it has been push upstream to be included
in the mainline kernel.
the following 8 patches constitute the first batch I'd like to get the pulled
into net-next-2.6/3.2. They bring a new feature (AP isolation on the mesh
layer), some minor cleanups, spelling fixes and some additional debugfs
The following changes since commit 322a8b034003c0d46d39af85bf24fee27b902f48:
Linux 3.1-rc1 (2011-08-07 18:23:30 -0700)
are available in the git repository at:
Antonio Quartulli (6):
batman-adv: hash_add() has to discriminate on the return value
batman-adv: correct several typ0s in the comments
batman-adv: detect clients connected through a 802.11 device
batman-adv: implement AP-isolation on the receiver side
batman-adv: implement AP-isolation on the sender side
batman-adv: print client flags in the local/global transtables output
Marek Lindner (2):
batman-adv: reuse tt_len() to calculate tt buffer length
batman-adv: merge update_transtable() into tt related code
Documentation/ABI/testing/sysfs-class-net-mesh | 8 +
net/batman-adv/aggregation.h | 3 +-
net/batman-adv/bat_sysfs.c | 2 +
net/batman-adv/bitarray.c | 6 +-
net/batman-adv/gateway_client.c | 10 +-
net/batman-adv/hard-interface.c | 34 ++++-
net/batman-adv/hard-interface.h | 1 +
net/batman-adv/hash.h | 25 +++-
net/batman-adv/main.c | 2 +-
net/batman-adv/main.h | 6 +-
net/batman-adv/originator.c | 2 +-
net/batman-adv/packet.h | 1 +
net/batman-adv/routing.c | 77 +--------
net/batman-adv/send.c | 10 +-
net/batman-adv/soft-interface.c | 13 +-
net/batman-adv/translation-table.c | 199 ++++++++++++++++++++----
net/batman-adv/translation-table.h | 21 ++--
net/batman-adv/types.h | 5 +-
net/batman-adv/unicast.c | 6 +-
net/batman-adv/unicast.h | 2 +-
net/batman-adv/vis.c | 6 +-
21 files changed, 291 insertions(+), 148 deletions(-)