hi list,
i wanted to ask, if it would be possible to have a little CHANGELOG file
in side the batman-sources?
i think it is very informative for the users, which are not active
developer to know whet is changed from one version to the other.
cheers,
doc
HeyHo!
if you ever had the feeling that rc1 is somehow unstable and many obvious
routes were simply ignored, relax, you were totally right. Our optimism
drove us to introduce just *minor* changes to the code just five
minutes to 12 and which eventually turned out to be buggy. So happened with
rc1. We are trying hard to improve.
So what has changed since then?
- Fixed relevant bugs in the debug-system and an incredible bug in the
neighbor-detection algorithm causing one of two neighbors to simply
ignore the other (what a mess).
- Now batman is sending originator-messages with TTL of 50 on
every interface.
(results in: no more dead back-routes to nodes with multiple
interfaces but also larger routing-tables, more processing and
traffic overhead)
- Reduced bidirectional-link-check-range to 2
and increased sequence-range to 128
(as some experiments in the berlin freifunk mesh indicated that these
parameters worked best for our purpose)
- AND, in order to resolve existing bugs instead of introducing new ones,
we took some time to test all changes in our local setup which includes
freifunk-based WRTs, buffalos, and foneras as well as 4G-MeshCubes and
i386 based machines
... hoping that you can confirm the good results
Please update your nodes to batmand-0.2.0-rc2 by visiting our new
SUPA-DOWNLOAD-STORE at http://open-mesh.net/batman/downloads offering
precompiled binaries and packages for quite a number of linux-based systems.
Also we are willing to include other targets in the auto-compilation
toolchain which currently allows compilations for openWrt (
http://wiki.openwrt.org/TableOfHardware ) and openembedded
( http://www.openembedded.org/filebrowser/org.openembedded.dev/conf/machine )
based systems. So if you find your HW supported by one of the mentioned
projects (and are willing to test next autogenerated results) please give us
a hint.
very best wishes from
the B.A.T.M.A.N. development team
Marek Lindner wrote:
> Hi,
>
>
>
>> since i got the core dump created now, i suppose that the patches are in
>> rev352?
>>
>> pleas tell me what to do with the core file, but for now i will attach it.
>>
>
> to fully debug your problem I need the binary you created the core dump with.
> Do not create a new binary - I have to have the binary which was running
> during the segmentation fault.
>
> Regards,
> Marek
>
>
where can i upload the binary?
cheers,
doc
hi list,
i am new here and just trying to use batman rev350 compiled on
2.6.21.1-rt3 kernel on ibm-thinkpad-R50e. the rt-patch (for low-latency
audio work) comes from:
http://people.redhat.com/mingo/realtime-preempt/
i am using a atmel-wlan adapter and the atmel driver from:
git-clone http://honk.sigxcpu.org/git/at76c503a.git/
the driver runs pretty stable, if i use olsrd to join the network here, i use following script to start the protocol:
#!/bin/sh
iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ap 02:CA:FF:EE
ifconfig eth2 104.130.30.9
ifconfig eth2 up
olsrd
.........
except of some timeouts, which are pretty rarely, that runs good.
i am starting batman with:
#!/bin/bash
iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10
ifconfig eth2 105.130.30.9
ifconfig eth2 up
sleep 1
batmand -d 1 -p 105.131.41.5 -r 1 eth2
and
#!/bin/bash
batmand -c -d 2
in another terminal.
when batman starts, the 'batmand -c' script shows, that i am connected
to another gateway, but not to preferred one:
Gateway Router (#/128)
=> 105.192.99.62 105.130.30.1 ( 3), gw_class 10 - 6 MBit,
reliability: 0
105.192.99.61 105.130.30.1 ( 1), gw_class 7 - 2 MBit,
reliability: 0
105.131.83.5 105.130.30.1 ( 1), gw_class 11 - >6 MBit,
reliability: 0
105.131.41.5 105.130.30.1 ( 2), gw_class 11 - >6 MBit,
reliability: 0
105.192.99.103 105.130.30.1 ( 3), gw_class 7 - 2 MBit,
reliability: 0
105.192.99.192 105.130.30.1 ( 2), gw_class 10 - 6 MBit,
reliability: 0
...........
this always is a number 105.192.99.....(.62, .103, .192).
this condition than stays for 2 or 3 up to 10 minutes, and in that time
i cannot even ping the 105.130.30.1 which is the next point here.
after some minutes, the connection changes, so that 'batmand -c' shows
that i am connected to 105.131.41.5 and i am able to ping 141.1.1.1.
unfortunately, after some minutes (or even shorter), the batman script
stops and the terminal is at the prompt again. there is no segfault,
using 'ulimit -c unlimited' will not produce a core-dump. i suppose that
this is not a driver bug, cause looking at this moment at 'dmesg', i can
see that the driver is loaded using the 02:ca:ff:ee:ba:by - if i stop
batmand and start olsrd, i will be connected to the internet as expected.
i am really not aware of what else information i could provide to you,
in order to make batmand running stable here, but if you have any idea,
please let me know!
cheers,
doc
BATMAN folks: Sorry I joined this list a bit late. I fully agree with
ELEKTRA's email dated March 10, 2007 in his reply to Status of BATMAN in
IETF. I attached ELEKTRA's comments again below: >>In my opinion the
development cycle of many organizations
>>is slow because they are too bureaucratic and too occupied with
>>paperwork and their own hierarchical structure instead of developing
>>useful things. I like the informal character of our development. Our
>>research is a non-profit driven by fun and the will to empower people
>>around the world to improve their communication on a grass root level.
>>"On-line for all" is the agenda.
>>Of course hoity-toity people with ties, suits and long academic titles
>>tend to ignore a work of freaky people that don't bother about writing
>>texts in the style of codes of law. That's alright with me. In their
>>fancy-looking presentations about mesh-networks you see soldiers, tanks
>>and robots building a mesh on the battlefield or bugging devices for
>>their paranoid big-brother fantasies. I don't want to be supportive for
>>that kind of development. We can't avoid it because of the open nature
>>of open-source development. We are not doing things for our drawers or
>>to keep it as a secret. >>Take the development of OLSR as an example.
INRIA is still submitting
>>new drafts about ideas that we have found not feasible in real life in
>>the year 2004 when we did our first tests with 20 nodes on a conference
>>(Wizard of OS III) in Berlin
Hey again,
...sorry I forgot to mention:
you need tun support loaded into your kernel
and the libpthread library (but the latter should be default on most i386
based machines).
---------- Forwarded Message ----------
Subject: Re: [B.A.T.M.A.N.] problems running batman rev350
Date: Saturday 19 May 2007 17:49
From: Axel Neumann <axel(a)open-mesh.net>
To: b.a.t.m.a.n(a)open-mesh.net
Hey Dragan,
> #!/bin/sh
> iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ap
> 02:CA:FF:EE ifconfig eth2 104.130.30.9
(just to be shure) this should be 02:CA:FF:EE:BA:BE
..
> i am starting batman with:
>
> #!/bin/bash
> iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10
> ifconfig eth2 105.130.30.9
> ifconfig eth2 up
> sleep 1
> batmand -d 1 -p 105.131.41.5 -r 1 eth2
can you start batmand in background with:
batmand -r 1 -p 105.131.41.5 eth2
instead and tell if the problem continues. This command instantly returns
your prompt but a:
ps -aux | grep batmand
should show the running main-daemon in the background.
Also please check that there are no predefined host routes for the
105.0.0.0/8 network before you start batmand and after it stopped. Meaning
a:
route -n | grep ^105
berfore and after the daemon is running should only show:
105.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth2
While batmand is running it should of course show routing entries for all
other known batman nodes but if such host routes are still there after the
daemon stopped it is a definitive sign for an uncorect termination of teh
daemon.
> #!/bin/bash
> batmand -c -d 2
>
> in another terminal.
It should of course always be possible to access the debug output from the
running batmand main-daemon by launching a batmand-client with
batmand -c -d <1-4>
or in batch mode (providing just a single outputpage and returns to the
prompt) with:
batmand -c -d <1-4> -b
However, it would be interesting to know if the crash is related to existence
of a batmand-client connecting to the main daemon. For example for
batmand-0.2.0-rc2-rv350 (and before) debug level 4:
batmand -c -d 4
is known to cause the batmand to crash after a short time and it might be
possible that this problems also occur with other debug-levels.
Try
batmand -c -d 1
and
batmand -c -d 2
instead.
ciao,
axel
> when batman starts, the 'batmand -c' script shows, that i am connected
> to another gateway, but not to preferred one:
>
> Gateway Router (#/128)
> => 105.192.99.62 105.130.30.1 ( 3), gw_class 10 - 6 MBit,
> reliability: 0
> 105.192.99.61 105.130.30.1 ( 1), gw_class 7 - 2 MBit,
> reliability: 0
> 105.131.83.5 105.130.30.1 ( 1), gw_class 11 - >6 MBit,
> reliability: 0
> 105.131.41.5 105.130.30.1 ( 2), gw_class 11 - >6 MBit,
> reliability: 0
> 105.192.99.103 105.130.30.1 ( 3), gw_class 7 - 2 MBit,
> reliability: 0
> 105.192.99.192 105.130.30.1 ( 2), gw_class 10 - 6 MBit,
> reliability: 0
>
> ...........
>
> this always is a number 105.192.99.....(.62, .103, .192).
> this condition than stays for 2 or 3 up to 10 minutes, and in that time
> i cannot even ping the 105.130.30.1 which is the next point here.
>
> after some minutes, the connection changes, so that 'batmand -c' shows
> that i am connected to 105.131.41.5 and i am able to ping 141.1.1.1.
> unfortunately, after some minutes (or even shorter), the batman script
> stops and the terminal is at the prompt again. there is no segfault,
> using 'ulimit -c unlimited' will not produce a core-dump. i suppose that
> this is not a driver bug, cause looking at this moment at 'dmesg', i can
> see that the driver is loaded using the 02:ca:ff:ee:ba:by - if i stop
> batmand and start olsrd, i will be connected to the internet as expected.
>
> i am really not aware of what else information i could provide to you,
> in order to make batmand running stable here, but if you have any idea,
> please let me know!
>
> cheers,
> doc
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N(a)open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
-------------------------------------------------------
Hi,
I have seen a testbed made with UML instances here to test OLSR:
https://wiki.funkfeuer.at/index.php/OLSR-NG
I was wondering if it would be possible to setup such system to test BATMAN.
Best,
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
Dear All
Iam new to BATMAN routing protocol. So forgive me if
my question is naive.
Does BATMAN protocol support IPv6 addressing. In other
words, does the protocol only support IP version 4 or
supports v6 as well
Kind regards
Magesh
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all
I looked into trunk/batman/bsd.c on WCW07 and began to work on it
this weekend. I believe that i've fixed the routing code and that the
tun stuff is working but i'm somehow to stupid to actually test the
stuff. My setup is like this:
== Mac OSX Intel/10.4 ==
internal network interface en3 (-> Virtual Machine): 192.168.129.130/25
$ ps auxwww | grep batmand
root 2308 0.1 -0.0 28600 436 p2 S+ 8:21PM
0:00.83 ./batmand -d 2 -g 7 en3
$ ifconfig tun0
tun0: flags=8850<POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
open (pid 2308)
Batman says:
No gateways in range ...
== Virtualized Debian Linux ==
eth0: 192.168.129.131/25
batmand -r 3 -d 2 eth0
$ ps auxwww | grep batman
root 6784 0.2 0.1 34472 692 pts/1 Sl+ 20:22 0:01 ./
batmand -r 3 -d 2 eth0
Batman says:
192.168.129.130 via: 192.168.129.130(64), gw_class 7 - 2 MBit,
reliability: 3
BUT: ifconfig -a does not show any tun device. Is this normal
behavior? In my opinion the linux box should create a tun and point
the default route to it. Am i wrong?
LG
Lorenz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFGPiHSlNX+1hvKqPsRArYmAJwIJbf068yN+KKgGl/57cz1B+J9GgCbBFWx
fswy4zNXXSzFLs0UZIJcXZc=
=4w8Y
-----END PGP SIGNATURE-----
Hello!
Despite our optimistic presentation of the almost-stable b.a.t.m.a.n.-III-0.2b
release, we could not refrain from applying a number of further changes.
Besides some more bugfixes in the outputsystem, resolved crashes due to the
hash code and lost unix-sockets, more comments in the code,
vis-port-adaption, enhanced BDNB (bidirectional neighbor) check and finally
the full implementation of the BNTOG (rebroadcast only packets from best
neighbor) check, the most obvious enhancement comes with the new beautifull
debug output.
Unfortunately the reduction of the frame size in the bidirectional link check
from three to two did not cause the improovement (in finding better routes in
the mesh) as we expected. Still we want to give it another try with the
changes we implemented (for the BDNB check) in this new release.
batman-III-0.2.0rc1 is waiting on http://open-mesh.net/batman/downloads for
your download. We appreciate your administration ;-)
happy testing,
the B.A.T.M.A.N. development team
