B.A.T.M.A.N August 2011

b.a.t.m.a.n@lists.open-mesh.org

30 participants
27 discussions

[B.A.T.M.A.N.] batman-adv 2011.3.0 released

by Marek Lindner

The B.A.T.M.A.N. team is delighted to announce its latest release, 2011.3.0, introducing major protocol changes for better roaming of non-mesh clients, gateway convenience features and a pile of bug fixes & code stability changes. As the kernel module always depends on the Linux kernel it was compiled against, it does not make sense to provide binaries on our website. As usual, you will find the signed tarballs in our download section: http://downloads.open-mesh.org/batman/releases/batman-adv-2011.3.0/ as well as prepackaged binaries in your distribution. Important changes ----------------- The extensive work on roaming improvements for non-mesh clients led to a protocol change which breaks backward compatibility. Be sure to update all your mesh network participants to the latest version to avoid orphan nodes. Furthermore, a change in the networking infrastructure of the Linux kernel made us drop the support of Linux kernels older than 2.6.29. Maintaining compatibility would be an uphill battle while not being worthwhile for us as a Linux kernel project. Thanks ------ Thanks to all people sending in patches: * Antonio Quartulli <ordex(a)autistici.org> * Daniele Furlan <daniele.furlan(a)gmail.com> * David Howells <dhowells(a)redhat.com> * David S. Miller <davem(a)davemloft.net> * Joe Perches <joe(a)perches.com> * Jonathan Neuschäfer <j.neuschaefer(a)gmx.net> * Marek Lindner <lindner_marek(a)yahoo.de> * Sven Eckelmann <sven(a)narfation.org> batman-adv ---------- This release comes with a redesign of one of the oldest code segments / concepts in batman-adv: the non-mesh client announcement mechanism. When batman-adv detects a non-mesh client it automatically starts announcing the client's mac address in the mesh network to make the mesh aware of the client's location. The new protocol extension mainly deals with the optimal handling and propagation of these client position packets. Major benefits include: Only changes (client arriving or leaving) are propagated in the mesh, thereby reducing the protocol overhead; traffic redirection when a client roams from one mesh node to the next until the mesh network has converged to reduce the packet loss while roaming; extensible packet format to construct more features on top of it. In addition, batman-adv gained support for informing the user space about events via uevent (a long-standing feature request). The gateway subsystem is the first to make use of it by sending signals when a new gateway has been selected / selected gateway has been changed / the selected gateway has been removed. Also, when enabled the gateway subsystem will filter out incoming DHCP renewal requests if they are not targeted at a high quality gateway to force the client to switch to the best available gateway. The routing algorithm received a minor tweaking which make it accept delayed OGM rebroadcasts to avoid bogus routing under heavy load. A bug hindering the correct broadcast of OGM packets if interfaces were added & removed in a particular order was fixed. A similar problem affecting the OGM aggregation was eliminated too. The many smaller bug fixes and code stability improvements make this release a well-rounded package. batctl ------ The Makefile received major attention and various cleanups to make packaging of batctl easier. tcpdump was updated, so that it can analyze the new tt & roaming packets and was extended by a new option to filter all packets except the specified types. An additional debug level for all client announcement related information was added too. A pair of small bugs was squashed along the way: bisect did not properly initialize a variable which led to a compile time warning and a potential memory leak in the bat-hosts parser fixed. Happy routing, The B.A.T.M.A.N. team

11 years, 7 months

[B.A.T.M.A.N.] Fake batctl gwl results

by Filippo Sallemi

Hi all, I don't understand why when an node gateway switch its channel to another however it is visible in the by batctl gwl or batctl o command but with very low link quality and obviously the node is ununreacheable. This is normal? Rgds -- Filippo Sallemi

11 years, 7 months

[B.A.T.M.A.N.] routing code re-organization / the road ahead

by Marek Lindner

Hi folks, as some of you already know we are actively working towards the new routing algorithm. Since it is our fifth incarnation we named it "B.A.T.M.A.N. V". The major improvements focus on areas like mobility support, less overhead and faster network convergence. We still are in the early stages of developing the code and finalizing the concept. Interested parties / early birds may contact us to get involved. All others should wait until we issue the call for public testing & feedback. In order to ensure a smooth transition and efficient testing later, we decided to offer a choice of routing algorithm at compile time. Those who wish to test the new code (once available) can choose it whereas the others can stick with the mature routing code base while enjoying new features / bug fixes outside of the routing algorithm. As a first step into that direction I worked on a set of patches to assemble all B.A.T.M.A.N. IV related routing code in a single file, accessible via a routing algo API which will also be used by the new code. Note: Although we have a new file (bat_iv_ogm.c) I kept the previous copyright information because all I did was shuffling the code around. During the process I renamed a few functions here and there but no code was changed. Regards, Marek

11 years, 7 months

[B.A.T.M.A.N.] batman(d|-vis) deprecated by upstream

by Sven Eckelmann

Hi, I just wanted to inform both of you about the upstream state of the batmand [1] and batman-vis [2]. Marek Lindner stopped to actively maintain batmand a long time ago (my guess was 2009/2010... after the release of v0.3.2). The maintainer role was vacant and Elektra Wagenrad tried to be the replacement. Unfortunately, after the first hype, nothing seemed to be changed from the time were nobody maintained batmand. No patches were processed and no changes were committed. So parts of it doesn't build right now and other things don't seem to work as expected. There are still people which try to create new mesh networks using this software, but nearly no one from open-mesh has the energy to support them as most developers switched to batman-adv and batctl. The decision was made to really say "batmand is deprecated" [3,4] instead of waiting for some fairies to take over the project. I've already closed the upstream bugtracker and moved the git repositories [5] in our "obsolete" folder. The best option for end users is to use a recent kernel with the included batman-adv (or olsrd [6], babeld, ...). I am personally thinking about removing the Debian batmand package [7] from all future stable releases, but have to discuss this with Holger Levsen. Kind regards, Sven PS: Michael Weber, version 2011.2.0 of batman-adv [8] and batctl [9] were released [10] some time ago. You may want to update your ebuilds [11,12]. batctl/batman-adv 2011.3.0 will also be released in the coming weeks. batman-adv 2011.3.0 will be part of linux v3.1 and is "incompatible" with batctl <=2011.2.0. batctl 2011.3.0 will also include some fixes which make your sed hacks in src_prepare unnecessary. The compat code in batman-adv for kernels < 2.6.29 will also be removed. [1] http://packages.gentoo.org/package/net-misc/batmand [2] http://packages.gentoo.org/package/net-misc/batman-vis [3] http://www.open- mesh.org/wiki/1/BranchesExplained/diff?version=22&version_from=21&commit=Vi… [4] http://www.open-mesh.org/wiki/open- mesh/Download/diff?version=55&version_from=54&commit=View+differences [5] http://git.open-mesh.org/ [6] http://packages.gentoo.org/package/net-misc/olsrd [7] http://packages.qa.debian.org/b/batmand.html [8] http://downloads.open-mesh.org/batman/stable/sources/batman-adv/ [9] http://downloads.open-mesh.org/batman/stable/sources/batctl/ [10] http://www.open-mesh.org/wiki/open-mesh/2011-06-19-batman-adv-2011-2-0-rele… [11] http://packages.gentoo.org/package/net-misc/batman-adv [12] http://packages.gentoo.org/package/net-misc/batctl

11 years, 7 months

[B.A.T.M.A.N.] Configuring batman

by John Tobias

Hi Guys, I have two devices, both of them have eth0, wlan0. I followed the BATMAN quick start guide (http://www.open-mesh.org/wiki/batman-adv/Quick-start-guide) mixing non-BATMAN. The bat0, eth0, wlan0 on both devices were set to 0.0.0.0 and the mesh-bridge on dev1 was set to 192.168.10.1 and on dev2 was set to 192.168.10.2. Both devices can ping to each other. When I execute "batctl gwl", I was getting "No gateways in range ...". My question is, do you have a sample step-by-step procedures to bring up the batman correctly?. Regards, john

11 years, 7 months

Re: [B.A.T.M.A.N.] Configuring batman

by Ray Gibson

John, Gateway mode is something different (read about it in the wiki) -- what you want to look at with batctl is "originators" which show you surrounding nodes with link quality. If you want to do routing you'll have to do something different; batman-adv as you set it up is like plugging your computers into the same switch. Good luck, RG John Tobias <john.tobias.ph(a)gmail.com> wrote: >Hi Guys, > >I have two devices, both of them have eth0, wlan0. I followed the >BATMAN quick start guide >(http://www.open-mesh.org/wiki/batman-adv/Quick-start-guide) mixing >non-BATMAN. >The bat0, eth0, wlan0 on both devices were set to 0.0.0.0 and the >mesh-bridge on dev1 was set to 192.168.10.1 and on dev2 was set to >192.168.10.2. Both devices can ping to each other. > >When I execute "batctl gwl", I was getting "No gateways in range ...". > >My question is, do you have a sample step-by-step procedures to bring >up the batman correctly?. > >Regards, > >john N�r��x�jب��'�ح�׬jw�y�k�x�r��x�jب��)��jx��%y�k�x� ��x�jب��-��nuѩ݊��%�˫z+,��\��h�y�h��yȩ��{^�םo+azǧu��~�b�g��N�zf��j|��W��h��p��b��ަ�)�'�j��ا��y��^��^�Ǩ~�^�wb�'njZ+z{b�+h�&��j��u�޲ǝN�j��hm��{��y�(�'��u�kz�vW��0��h��ay�i��,y�^�h��*'��n�� z�l!"'p��Z��q�y�a�Ǧj)b��뢺ey��b+azǧu�ڝئ��bjץ�ץzע��*.�̬�铅��ʋ

11 years, 7 months

[B.A.T.M.A.N.] AP - STA

by Filippo Sallemi

Hi, It's possible to use batman-adv in ap sta mode? Rgds -- Filippo Sallemi

11 years, 7 months

[B.A.T.M.A.N.] "Distributed" DHCP vs gateway

by Ryan Hughes

So, I had a crazy idea the other day: Normally, when I talk to people about mesh networks, they assume that there is some central authority assigning IP addresses to nodes intelligently. I was thinking, though, that I'd rather have it so that every node could have the same firmware, and you'd just throw the node up and it'd negotiate everything for itself, including its IP address. So I was thinking: What if each node in the network was using batman-adv, and ran a DHCP client and a DHCP server? It'd try to get an address thru DHCP. If it failed, it'd choose an address at random from the network range. Then, any time someone threw up a new node in range, the new node would try to get an address, and it would succeed in getting an address from the first node. Multiple DHCP servers can serve the same, overlapping IP ranges. However, this depends on the DHCPOFFER and DHCPREQUEST being broadcast to the network. This is how we avoid having the same IP address assigned to multiple nodes -- DHCP servers overhear what was assigned to whom by other DHCP servers, and make a note to themselves not to assign that address themselves. So it seems that a "distributed" DHCP system could work. The problem is, doesn't Batman-adv munge the DHCP that flows though it, for its gateway logic? So that the DHCPREQUESTs are unicast? That's great for gateway logic. But I also want nodes to have IP addresses for internal communication. I was thinking of running it like this: Each node has two virtual interfaces - the mesh interface, running in adhoc mode. Routers use this interface, and this is where the distributed DHCP runs. Another wifi interface runs in host mode. This is what laptops and so forth will connect to. Once a router gets an ip address from this distributed DHCP nonsense, then it determines a longer network prefix for its clients on the host-mode interface. It sets up its HNAs and starts serving DHCP with this longer prefix to its clients. The machines on the inside run webservers and so forth that should be available to the inside of the mesh. Now, what if the network is fractured and the same IP address gets assigned to a router (and thus is used as a prefix for that router's clients) on each side of the split? When the segments join up, we'll have multiple nodes with the same IP address and this will cause problems. Yes. The lease times will be very short, so this type of problem should resolve itself quickly. But, what do I do about how the gateway business interferes with DHCP? Could I somehow have two DHCP servers serving the same interface? One that serves out IP addresses and one that deals only with gateways? Is this idea just too crazy? Why? --Ryan Spam detection software, running on the system "dedicated37.virtbiz.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: So, I had a crazy idea the other day: Normally, when I talk to people about mesh networks, they assume that there is some central authority assigning IP addresses to nodes intelligently. I was thinking, though, that I'd rather have it so that every node could have the same firmware, and you'd just throw the node up and it'd negotiate everything for itself, including its IP address. [...] Content analysis details: (10.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.5 HELO_LH_HOME HELO_LH_HOME 3.1 AXB_HELO_HOME_UN HELO from home - untrusted -1.5 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.2 RDNS_NONE Delivered to internal network by a host with no rDNS 4.3 TO_NO_BRKTS_DIRECT To: misformatted and direct-to-MX 2.6 TO_NO_BRKTS_NOTLIST To: misformatted and not a mailing list

11 years, 7 months

Re: [B.A.T.M.A.N.] Multiple DHCP Gateways

by gtolon＠inti.gob.ar

Thank you for your answers. I understood clearly how the system should work, but i´m not using the git repository but the 2011.1.0 version. I'll try with the repo to see what happens. Best regards Gabriel > Message: 2 > Date: Fri, 12 Aug 2011 18:02:20 +0200 > From: Antonio Quartulli<ordex(a)autistici.org> > To: The list for a Better Approach To Mobile Ad-hoc Networking > <b.a.t.m.a.n(a)lists.open-mesh.org> > Subject: Re: [B.A.T.M.A.N.] Multiple DHCP Gateways > Message-ID:<20110812160217.GB22361(a)ritirata.org.org> > Content-Type: text/plain; charset=utf-8 > > Hello and thank you for sharing your gw experience with us, > > On Wed, Aug 10, 2011 at 02:52:06PM -0300, gtolon(a)inti.gob.ar wrote: >> Hi > [CUT] >> However, when the original gateway becomes >> worse than the alternative, and the client chooses the new one as >> preferred (observed with batctl gwl) i noticed that the subsequent >> request DHCP messages are sent to the original server, even if it >> doesn?t have the best link. >> >> I guess that?s because these subsequent DHCP requests are made as >> Unicast to the original server and so Batman doesn?t redirect them, > > Unicast renewal requests are "dropped" only if the TQ towards the destination is > smaller than the "current_GW_TQ - GW_THRESHOLD" (GW_THRESHOLD = 50). > To clarify: > > > In your topology you have three nodes: A, B and C. A and C are GWs. A is the > current best GW for B and B got an IP from the DHCP server running on A. Then > the link A<--> B becomes worse than B<--> C. At this point Batman-adv will > drop a DHCP unicast renewal request directed to A > > if and only if TQ(C) - TQ(A)> 50 > > Is this condition verified in your topology when your are observing the renewal > DHCP packets? > > I hope I've been clear. :-) > >> but >> i wonder how this behavior affects the network balance, because the >> computers would get tied always to the original DHCP and IP default >> gateway even if they moved, right? > > As above. Clients will keep the same GW as long as the link is still "usable" > (difference on TQs greater than 50) > >> >> Thank you very much > > Thank you too, > Antonio > > > ------------------------------ > > Message: 3 > Date: Fri, 12 Aug 2011 19:22:28 +0200 > From: Marek Lindner<lindner_marek(a)yahoo.de> > To: "The list for a Better Approach To Mobile Ad-hoc Networking" > <b.a.t.m.a.n(a)lists.open-mesh.org> > Subject: Re: [B.A.T.M.A.N.] Multiple DHCP Gateways > Message-ID:<201108121922.28786.lindner_marek(a)yahoo.de> > Content-Type: Text/Plain; charset="utf-8" > > On Friday, August 12, 2011 18:02:20 Antonio Quartulli wrote: >> In your topology you have three nodes: A, B and C. A and C are GWs. A is >> the current best GW for B and B got an IP from the DHCP server running on >> A. Then the link A<--> B becomes worse than B<--> C. At this point >> Batman-adv will drop a DHCP unicast renewal request directed to A >> >> if and only if TQ(C) - TQ(A)> 50 > > Be aware that only happens if you use the git repository. The "DHCP request > drop" feature was not released yet. > > What version are you using ? > > Cheers, > Marek > > > ------------------------------ > > _______________________________________________ > B.A.T.M.A.N mailing list > B.A.T.M.A.N(a)lists.open-mesh.org > https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n > > > End of B.A.T.M.A.N Digest, Vol 56, Issue 15 > ******************************************* >

11 years, 7 months

[B.A.T.M.A.N.] Batman CPU usage

by Max Ip

Hi folks, I am checking the efficiency of my batman-adv network in terms of CPU usage. My system consists of batman-adv 2011.1.0 enabled 3 laptops. A-----B------C There is no direct contact between A and C. So, node B is the relaying node. The systems cpu configuration in all nodes are: In A : cpu MHz = 2000 In B : cpu MHz = 1000 In C : cpu MHz = 800 When I checked the CPU usage at different nodes (using netperf), I found the following results. TCP CPU utilization send local from C to B = 5.84% TCP CPU utilzation send local from B to A = 2.37% TCP CPU utilization from C to A (2-hop environment) = 9.19% UDP CPU utilization send local from C to B = 0.75% UDP CPU utilization send local from B to A = 3.85% UDP CPU utilization send local from C to A (2-hop environment) = 4.31% My questions are why is the CPU utilization so less for UDP case? In case of TCP cpu utilization, isn't 9.19% a very high value for a system consisting of just 3 nodes? Since, B is acting as a relaying node to relay the network from C to A, what is its impact on total CPU usage? Thanks Max

11 years, 7 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N August 2011