Hi Folks
A while back i suggested we re-work the /proc/net/batman/vis format.
Attached are two patches to achieve this. One patch is for the kernel
model sources and the second extends batctl so that it can read from
the /proc file and output dot or json format as before. The patch
includes documentation for the new new batctl command in the man page.
I've tested the dot output using graphviz dot. However i don't have
any tools which use the json output. So that format is not tested.
Andrew
Thought it might be a good idea to continue the discussion about
MTU handling to a new thread on the mailinglist for sharing some
experiences we had with this here in Lübeck already. Hope this is
fine with you guys :).
In our setup we first started with the default settings of using
wifi and ethernet links with the default MTU of 1500, ending up at
a MTU of 1476 on bat0. After discovering, that we could actually
increase the MTU on both the wifi and ethernet interfaces on our
Dlink DIR-300 routers running OpenWRT, we decided to give an MTU
of 1524 a try. In the beginning this was absolutely fine for our
test setups, as we had a quite homogeneous network. But as soon as
we were trying to connect some x86 desktop pcs running BATMAN-Adv
to the same network, things got quite complicated. Our experiences
were, that we are having 1GBit ethernet card in a laptop, that is
able to increase the MTU to 1524 on a recent 2.6.30 kernel. We
were trying about 5 random network cards we had available here in
our cellar and they all were not able to increase the MTU
(including my laptop's BCM5787M GB-ethernet card). So at the
moment I'm truely considering to also switch those Dlink routers
back to an MTU of 1500 for the sake of compatibility at least on
local area networks.
The motivation of using a higher MTU of 1524 at the beginning was
the rumour, that there might be some client devices (which we
would get into the network by bridging bat0 wifi wlan0 for
instance) not able to handle any MTU smaller than 1500. But in
fact it turned out, that in our days basically all devices are
able to do both IPv4 and IPv6 PMTU discovery on layer 3. So tests
showed, that if all BATMAN nodes are using an MTU of 1476 on bat0
(or the overlaying bridge) everything seems to work fine.
So now the question remains of what to do with links, where you
are only able to have links with an MTU of smaller than 1500?
Well, this usually is just the case when you are tunneling (over
the internet) where the standard MTU is mostly lower than 1500
because of the VPN overhead (+ pppoe). Luckily there might be a
nice workaround already: Since version 1.0.10 of the tinc VPN
daemon, which was released 3 weeks ago, it is handling packets
being too large for the PMTU (which tinc discovers on its own)
differently in switch mode (which is needed to transport
BATMAN-Adv ethernet frames). Usually you are choosing UDP mode
in tinc, any ethernet frame inside of this will then be
encapsulated in this. But if tinc discovers, that the packet will
be too big to fit through this link and the PMTU tinc discovered
for it, it will do TCP encapsulation instead to let the kernel
fragment the packet automatically.
As in a mesh network usually not an internet uplink but the wifi
is very likely being the bottleneck, the extra overhead on the
internet uplinks created by fragmentation might not be "harmful"
for the network average bandwidth. And as also the packet loss on
an internet uplink not running on its bandwidth limit is very,
very low, latencies shouldn't increase too much.
I'm going to test the usability of the current tinc version for
tranporting BATMAN-Adv packets soon, don't know if this "feature"
is working yet at all. But anyone else, please feel free to do
the same :).
Yes, and it would probably be nice to have "emergency"
fragmentation in BATMAN-Adv already, but as it had been mentioned
before, this is not trivial to implement. I also don't see a way
of how PMTU discovery might be done instead of fragmentation...
probably even tougher to do because of the dynamically changing
topology :).
Cheers, Linus
Hey folks,
I have given the new interface (designed in Brussels - specs are at the bottom
of this page: http://www.open-mesh.net/wiki/2009-10-23-batman-goes-mainline) a
little bit of thought. The main idea is to have batman list all available
interfaces inside of /proc/sys/net/batman-adv/interfaces to let the user
enable/disable/configure each interface individually via sysctl or batctl.
Back then we decided to create a "mesh" folder that should contain all
relevant meshing data such as the originator table, translation tables, vis
data, etc. We did not consider that the sysctl interface is not made for such
data. It easily allows to set small variables but other (read-only)
information should be placed elsewhere.
Now, we have to rethink the location. The creator of the new interface (Linus)
suggested to create 2 folders inside of /proc: The first folder should be part
of sysctl and contain all files that are writeable. The other should be
/proc/net/batman-adv and contains all read-only information.
Alternatively, we could keep everything in one folder but outside of the
sysctl interface.
Other ideas ? Opinions ?
Regards,
Marek
Dear List,
sorry if that is not the right place for my question. But the approach
of B.A.T.M.A.N in how to choise the next hop is phantastic. Protocols
how BGPv4 and OSPF only take the shortest path to the destination.
B.A.T.M.A.N looks for the fastest way where the Hello-Message arrives first.
So long. I need a Routing-Protocol for static mash. My Wireless-Network
besides on fixed Wireless Stations they become never to be dynamic. The
complete Wireless Network is in Infrastructure-Mode. All members in the
Network have just one role (AP / Client).
Currently OLSR does the routing job. But there lots of problems. OLSR
also take the shortest path, also in case, a better link is available.
B.A.T.M.A.N is not suitable for my situation. The Client should not be
able to select a desired gateway. A gateway should inject a default
gateway to the clients, how OLSR does it.
Is there any other routing protocol on the market, that combine all that
features, that i need?
* Routing descission on fastest HelloMessage
* Inject Default-Gateway via 0.0.0.0/0
* Without tunneling data
I know. B.A.T.M.A.N is opensource. But i'm not familiar with C/C++ and
so, i'm not able to do some modifications to the source.
Or is anyone out there, that can do the modification for me? Tell me,
how long the work takes, and what you interested to earn for.
Requirements:
* Disable the bat0 Interface
* Enable announcing 0.0.0.0/0
Liebe Grüße aus Freilassing,
Michael Rack
RSM Freilassing
--
RSM Freilassing Tel.: +49 8654 607110
Nocksteinstr. 13 Fax.: +49 8654 670438
D-83395 Freilassing www.rsm-freilassing.de
Hi all
I am experimenting some path hopping in my tests using batman-adv.
Was wondering if and where metric information are shared among batman nodes
(again, with batman-adv) as I did not find any useful infos sniffing packets
with wireshark patched.
The command batctl l shows (with log level 8)
$ batctl l
[ 9462] Changing route towards: 00:0b:6b:2f:53:09 (now via
00:0b:6b:34:88:94 - was via 00:0c:42:2c:d8:fc)
[ 9525] Changing route towards: 00:0b:6b:2f:53:09 (now via
00:0c:42:2c:d8:fc - was via 00:0b:6b:34:88:94)
[ 9560] Changing route towards: 00:0b:6b:2f:53:09 (now via
00:0b:6b:34:88:94 - was via 00:0c:42:2c:d8:fc)
But no info about actual metric when a route is changed.
Thanks.
--
Francesco Cappuccio
Hi
Is there a B.A.T.M.A.N implementation on any of the simulators NS2 or
Omnet++ available?
Regards
Abhishek K
National Institute of Technology Karnataka India
FYI:
We just made a big towards getting batman-adv in mainline. We are now
in GregKH patch tree.
What i don't know is if this will be merged for the next 2.6.32-rc or
if we need to wait for the opening of the 2.6.33 window.
Andrew
----- Forwarded message from gregkh(a)suse.de -----
Date: Thu, 19 Nov 2009 15:01:09 -0800
From: gregkh(a)suse.de
To: andrew(a)lunn.ch, gregkh(a)suse.de, lindner_marek(a)yahoo.de,
siwu(a)hrz.tu-chemnitz.de
Subject: patch staging-batman-adv-meshing-protocol.patch added to gregkh-2.6
tree
X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham
version=3.2.5
This is a note to let you know that I've just added the patch titled
Subject: staging: batman-adv meshing protocol
to my gregkh-2.6 tree. Its filename is
staging-batman-adv-meshing-protocol.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
----- End forwarded message -----
The B.A.T.M.A.N. team is pleased to announce the availability of the second
batman-adv release which brings major improvements, new features, changes
along the way and a series of bugfixes.
As the kernel module always depends on the kernel it was compiled against it
does not make sense to provide binaries. However, you will find binaries for
batctl at the usual location:
http://downloads.open-mesh.net/batman/stable/binaries/
as well as signed source tarballs for the module and batctl:
http://downloads.open-mesh.net/batman/stable/sources/
Important changes
-----------------
With this release we believe that the kernel module is fully capable to
replace a routing daemon feature wise as well stability wise. Therefore the
batman-adv user space daemon (which was marked deprecated since the last
release) as well as the vis-adv daemon have been removed from our repositories
as they are no longer supported. We urge all remaining users to consider a
migration towards the the kernel module.
Thanks
------
Special thanks go to:
* Sven Eckelmann who continuously provides us with patches and advice
whenever problems show up
* Andrew Lunn & Yang Su for their analysis of the routing protocol which
helped us to identify temporary routing loops in the code
* Linus Luessing & Freifunk Luebeck for the rigorous testing & bug
reporting of all (im)possible race conditions they encountered
* Jacob Marble who tried to find a new home for our extravagant mailing list
requirements and gave birth to the batctl idea
Thanks to all people sending in patches (in no particular order):
- Andrea Ghittino <a.mailevent(a)gmail.com>
- Sven Eckelmann <sven.eckelmann(a)gmx.de>
- Andrew Lunn <andrew.lunn(a)ascom.ch>
- Yang Su <Yang.Su(a)ascom.ch>
- Linus Luessing <linus.luessing(a)web.de>
- Antoine van Gelder <antoine(a)7degrees.co.za> (JSON patch was ported)
batman-adv
----------
The module has undergone some major changes to better fit into the event based
nature of the kernel. We removed a number of timers (e.g the new interface
detection) which also greatly reduces the risk of race conditions. Also new is
the packet queue that allowed implementing the aggregation (already known from
the user space implementation) as well as transmission retry (ARQ) for payload
broadcasts because we noticed most broadcasts vanish in transit. This feature
merits some extra attention as it is the first in which the routing module
influences the payload traffic directly to enhance the mesh experience.
We also spent quite some energy to fix bugs in the routing algorithm that
triggered temporary routing loops, squashed a TTL code bug and removed the
ghost entries from the originator table. The whole code received linux coding
style adjustments, refactoring & cleanups. Furthermore all kernel version
compatibility code has been unified in compat.h. The internal vis server
received another output format (JSON) plus secondary interface export
functionality in the dot draw format. Numerous small bugs were fixed such as
using the random ethernet generator from the kernel for better randomness,
exporting the version via /sys/module/batman_adv/version, fixing alignment
issues, race conditions and deadlocks.
batctl
------
Although this is the first release of batctl it carries the same release
version as the kernel module (for the sake of simplicity). It is based on the
work of Andreas Langer who created the battools which were never officially
released. Since then it has been extended to the point that it serves as
configuration utility, monitoring and debugging application. It allows to
modify the module parameters, reading the logfiles & tables, decapsulate
embedded packets on the fly, traceroute to & ping mac addresses, generate
sequence number graphs and more. Check the README to get an impression:
http://www.open-mesh.net/browser/trunk/batctl/README?rev=1466
road ahead
----------
The batman-adv development lying ahead can be separated into 2 big chunks: The
linux kernel integration already started and we began working on batman's move
into the linux land (more information can be found on www.open-mesh.net) -
expect follow up news in the coming weeks. In the meantime a large number of
ideas are flying around how to further improve the B.A.T.M.A.N. algorithm to
increase its convergence speed, reduce traffic overhead and much more. A first
idea collection will be published soon.
Happy routing,
The B.A.T.M.A.N. team