I am using batman 1256 on a very recent openwrt (linux version
2.6.28.10) as well as a bit older one (linux version 2.6.26.8).
With batgat installed, I have problems with the kernel crashing when
turning the gateway on and off. I start batman with -r 2. If I
detect an uplink, I issue -c -g 11000. If I lose the link, I issue -c
-r 2. It is this final -c -r 2 that causes the kernel to either crash
with a bad page on the next process that is created, have a null
pointer error, or have a recursion error.
If I run batman without batgat, I don't get any crashes.
Everything works fine otherwise. Except one thing that just came to
mind, I had to remove -DDEBUG_MALLOC -DMEMORY_USAGE because batman
wouldn't do anything without crashing because of magic number
problems. Could this be because I am on Big Endian hardware?
Could anyone else see if they have the same problem? All you have to
do is have batman running with batgat installed, start issuing batmand
-c -g 11000 ; batmand -c -r 2 multiple times and see if their system
stays stable.
Thanks.
> Let's say a packet comes from node A interface ath0 of node B, and
> there is a route on node B for the packet to go to node C, route which
> use the same interface ath0. In this case, you might want to add a
> cost to hop over the same wireless interface.
>Ok, good idea. I quickly made a patch:
>http://www.open-mesh.net/changeset/1276
>Feel free to test it. :-)
>Regards,
>Marek
But how would batman choose the next hop if at every node there are two
interfaces available. The ideal ofcourse would be
11a->11b->11a->11b->11a on each hop.
Regards
Kartik
>Right, that is still on open point on my ToDo. I'd like to automate
that if
>possible but did not have a good idea how to do that.
>Kartik: Any idea how roofnet is doing it ? Config ?
@Marek
Roofnet does not consider multiple interfaces. It was meant to work over
only a single radio. The work around is to consider WCETT metric rather
than ETT that is currently used in roofnet.
Yesterday, we (Marek, Julian, Linus) had some thoughts about the
advantages of having a multicast-aware BATMAN-Adv. Also some first
ideas about the actual implementation in BATMAN-Adv, which is not
a trivial task, have been discussed. The results so far and the
irc-log can be found in our wiki from the Lübeck-Freifunk
(http://luebeck.freifunk.net) in the section
Network->BATMAN-Adv-Multicast-Development. We definetly want to
push this feature further as it is especially very useful in
Mesh-networks and would like to hear from any other ideas of how
to implement this in the most efficient way and if there are any
concerns about the ideas for implementation yet. Also a
trac-enhancement-ticket can be found here:
http://www.open-mesh.net/ticket/128
Sincerely,
Julian, Linus - MetaMeute
Hello,
We have finally deployed a WMN testbed on our campus , currently running
roofnet. However I would like to run BATMAN as the underlying routing
protocol. Could you help me out with deploying and testing BATMAN on the
nodes.
Further since our nodes have two radio we are looking at taking
advantage of the same. Any pointers from a coding perspective to tackle
this would be great as I am hoping to publish the same.
Also does Batman advanced operate in Monitor mode?
Thanks
Kartik
Sorry, looks like I didn't reply all on this one:
On Fri, May 22, 2009 at 11:31 PM, Marek Lindner <lindner_marek(a)yahoo.de> wrote:
>> I am getting set up to do remote debugging. I'll see what I can find
>> doing that.
>
> Yeah, that would be another option.
ok, here is what I found on the debug malloc problem I am having:
In the function debugMalloc:
=================================
chunkHeader = (struct chunkHeader *)memory;
chunk = memory + sizeof(struct chunkHeader);
chunkTrailer = (struct chunkTrailer *)(memory + sizeof(struct
chunkHeader) + length);
chunkHeader->length = length;
chunkHeader->tag = tag;
chunkHeader->magicNumber = MAGIC_NUMBER;
chunkTrailer->magicNumber = MAGIC_NUMBER;
=> pthread_mutex_lock(&chunk_mutex);
=================================
I get the following results:
(gdb) p chunkHeader
$26 = (struct chunkHeader *) 0x308c8
(gdb) p chunk
$27 = (unsigned char *) 0x308d8 "\020\322\n"
(gdb) p chunkTrailer
$28 = (struct chunkTrailer *) 0x308dd
(gdb) p *chunkHeader
$29 = {next = 0x40096c34, length = 5, tag = 15, magicNumber = 305419896}
(gdb) p *chunkTrailer
$30 = {magicNumber = 878082050}
(gdb) p length
$31 = 5
I think the magic number is not getting into the chunk trailer
correctly because it is not aligned.
chunkHeader is aligned because it was returned by malloc
chunk is aligned because the size of the header is 16
chunkTrailer is not aligned because it is chunk + 5
Hope this helps. If not, and that shouldn't be a problem, I'll see
what else I can find.
Hi folks,
my goal is to visualize batman-adv-kernelland network topology. 'echo
"server" > /proc/net/batman-adv/vis' activates vis server on the mesh
node directly, right? Do the other nodes find the vis server
autmagically? What happens, if I wanna use more than one vis server? And
the last and most important question: is it possible to run a vis server
outside the mesh running layer 2 batman-adv? The layer 3 vis runs fine
but I have no clue how to get the visualization running on batman-adv
nodes. How to tell the vis server on the mesh nodes to output their data
to a dot-draw server (s3d) ? Lot of questions ;-)
For the German readers: I am documenting all the stuff on
http://debian.asconix.com/batman-advanced-openwrt-howto but I think, the
way I'm describing in the vis chapter is the way to get vis running in
layer3 batman, isn't it?
Greets,
Chris
--
"Privacy in residential applications is a desirable marketing
option." (ETSI EN 300 175-7 Ch. A6)
After some great input from Marek I took a swing at rewriting my vis
patch to allow serving of mesh topology simultaneously in dot_draw &
json.
* -j enables JSON server on port 2005
* dot_draw continues to be served on port 2004 irrespective of whether
-j is specified or not.
Some thoughts:
* It is not the prettiest of patches but it works. Thinking about
cleaner approaches makes my imagination drift in the direction of a
simple plugin API such as OLSRd has, anyone else having any similar
thoughts ? :)
* I'm serving json on port 2005 - any alternative suggestions ?
Patch attached for review, looking forward to feedback!
- a
--
http://7degrees.co.za
"Libré software for human education."
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
In the handling of netlink sockets is are two small and (probably
always) non fatal glitches. Only together they could lead to page
faults. It is quite unlikely that it happens, but you cannot say
that it is impossible.
Best regards,
Sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
iQIcBAEBCgAGBQJKE+oyAAoJEF2HCgfBJntGsv4P/ih/7xcrweNox8Kv8+OhoWBV
sZ8DcgRI3REqFtZMCNte/P/6ZGSx1hE95NytTo2R767PJF1ZjKX4B45NGf52rtAp
y+5++SGZ6vRPXPDhEF/1yg4i0ce29pgwZJVYj0qXZk5uLyJz2j4RtkPDGuCm4MCd
V7B1V+tVTLOGKLGnJAMEi49F61dRsYNt5tobQKwNxGt6tZVC7CCD7Ze2jA3c2b8r
dGixm+4vQGrV0EEmUS4JoJloOlz9tUI8+ld65urwj5Ep8IpSYBfrjQRbd9oaVtQe
6vRXnuAdZz9nam9MZRm4IqGa5DfNBkd0vXQryy85sxPSuIFti0FtiQI3bGYX8QnV
7ShajIU4JRo4k6jqZX6H+Z65DBahUFrbrfGqip7eOSLUANwtHy4S/0MD4Aw4FU2X
FF6AfsrdiBdT68eVBsxJdXInrAu5UwXBtIwNQm90l8JzT3TOo5pnDGiA7z0fVRGb
IJbTQKqkpZNvf0esyF7PhcEnjwefsP9gdXzuTcqlAday/mX3m73TmMismlM22Id+
eSLLU03Qi+fM3HfmMCk7OlMYXPw47qI+vMX8NGNqh/3MSqXZv8z9BXts89DXjMxs
jDOFX/qZCx0Z5c31DjCH7sxi3/R8rQTSE/AUMLVUrttuGwS/WzE4m/8W/Yu13gMi
ERz3CKiMqSEDin8EyL6a
=ECeu
-----END PGP SIGNATURE-----