Hi all,
cleanups - and more... ;-)
!!!Important!!!
For those of you, who have installed any previous versions - 1st:
#>ipkg remove freifunk-batman-de
For others:
freifunk-batman-de is a WebUI-Plugin for the freifunk-firmware (->[1])
It allows to easily configure and manage all aspects of the batman-daemon in a side-by-side environment with olsr (even for unskilled users).
The main target have been users in the berlin-freifunk community (104/8 net). The main goal is to raise the amount of batman-nodes in 'a mesh' of heterogeneous skilled node owners over 'the critical-mass' in the phase of development and testing... and of course, to make it easy for myself to manage testing with 10++ batman-nodes.
If the interface-config of your hardware differ from those of the Linksys wrt54g v2++/wrt54gl/...(->[2])
you have to use freifunk-batman-*std*-de...
Find it at: http://freifunk.schmudde.com/ipkg
Regards
Lui
[1] - http://ff-firmware.sourceforge.net/
[2] - http://wiki.openwrt.org/OpenWrtDocs/Configuration#head-b62c144b9886b221e0c4…
Hi,
we are happy to announce the first test release of the upcoming batmand. A lot
of work has been done under the hood:
- many cpu and memory usage optimizations
- Big Endian / Little Endian support added
- 64 Bit compability added
- ability to give access to the various debug levels without restarting the
daemon
Since a while the *BSD and MacOS X support is unmaintained. Therefore the
systems are not supported any longer until a maintainer is found.
The 0.2 release will be fully backward compatible to 0.1.1 and above. That
enables you to use the stable branch for most of your network and try 0.2
alpha on test machines. Any feedback is highly appreciated.
Short explanation how to use the debug levels now:
At first start batman normally:
batmand <your_options> <interface(s)>
Use another shell and type this:
batmand -c -d <your_desired_debug_level>
The option "c" tells batman to connect to a running batman instead of behaving
like a normal batman. You even can connect more than once or different debug
level. For debug level 1 and 2 a batch mode was included which prevents
redrawing the screen and is ideal for script integration:
batmand -c -b -d 1
You can get the sources and precompiled mips / arm binaries from
open-mesh.net.
Regards,
Marek
Hi,
today we release a bugfix and stability release for the 0.1.x branch.
We fixed the following problems:
- routing table manipulation bug fixed (some routes towards HNA were not
properly set)
- crash while using "-p" fixed
- several race conditions removed (regarding UDP tunnel setup)
As the *BSD and MacOS X is stopped for now the Big Endian / Little Endian
support was backported from the 0.2 branch.
Special thanks to Lui for providing access to his hostile testing environment
and endless patience with us. ;-)
You can get the sources and precompiled mips / arm binaries from
open-mesh.net.
Regards,
Marek
Hi,
For those of you who are coming to Fosdem, I am planning a BATMAN test
in order to see if the routing protocol chooses the fastest route.
Here are the details:
Saturday 24 feb @ 12H30 in front of the Chavanne room.
I will put more instructions here:
http://www.reseaucitoyen.be/wiki/index.php/Batman2chans
Best,
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
Hi,
We met with several people in Brussels active on the reseaucitoyen
project to test Batman.
Our configuration was 4 laptops like this:
laptop1 <----ethernet----> laptop2
+ +
+ +
+ +
wlan1 wlan11
+ +
+ +
+ +
laptop3 <----ethernet----> laptop4
With 8 different IPs for the 8 interfaces.
We launched batman-0.10 on all the nodes, but it appeared that one of
the interfaces was not reachable via ping. And the experience was
reproductible when we restarted the dameon, sometimes with a different
IP unreachable.
We are going to test the same configuration soon to see if batman
chooses the fastest route in terms of throughput.
Best,
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
Hallo,
ich wollte mal BATMAN ausprobieren und habe hierzu folgendes Netz
aufgebaut:
A --- B ---- C (stehen alle drei direkt nebeneinander)
(IP: 192.168.0. A:3
B:1
C:2)
So, bei einer direkten Kommunikation klapp alles ganz toll (und
schnell!). Sobald ich aber in A via iptables sage, dass er nichts
mehr von der MAC-Adr. von C annehmen soll (und andersherum) - spich
so tue als ob die Nodes A und C keine Funkverbindung mehr haben,
Klappt das Routing über B nicht. B sagt zwar, dass es A und C kennt/
hört, A kennt aber nur B und C auch nur B (nicht aber den Weg dahinter)
Der Debug auf Node A (192.168.0.3) auf Level 3 gab mir folgendes aus:
[ 39552] Received BATMAN packet from 192.168.0.1 (originator
192.168.0.2, seqno 162, TTL 49)
[ 39552] update_last_hop(): Searching originator entry of last-
hop neighbour of received packet
[ 39552] new packet - orig: 192.168.0.2, sender: 192.168.0.1
[ 39552] Packet with unidirectional flag
[ 39552] purge()
[ 39552] ------------------ DEBUG ------------------
[ 39552] Forward list
[ 39552] 192.168.0.3 at 40000
[ 39552] Originator list
[ 39552] 192.168.0.1, last_aware:39552, last_reply:36003,
last_seen:1153 via:
[ 39552] ---------------------------------------------- END DEBUG
[ 39552]
Er bekommt also über B (192.168.0.1) von C (192.168.0.2) eine
Message, kann damit aber nichts anfangen.
Ich benutze batman-III-0.1-rc1auf einem Debian Sarge System ohne tun.
Danke für eure Hilfe
Hendrik
