B.A.T.M.A.N

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

15 participants
4308 discussions

[B.A.T.M.A.N.] using gateway of other node, instead local gateway
by Freifunk Dresden 17 May '08

17 May '08

Hi, I have a node that uses its own internet connection to establish a vpn connection to another node. Therefore the node has a local default route. I have setup my policy routing in that way that all public wifi packets should be routed through the vpn connection. These packets should not go through the local gateway. The wifi interface and vpn interface are under control of batmand. (batmand -r 1 vpn eth1) When I call batmand -cd2 I see the gateway that is offered by the other node behind the vpn connection. But no default route (bat0) is present and I also can not use the parameter "-p" to select the gateway. How can I tell batmand to use the best gateway when the current node has a local gateway that should not be used by batmand or the batman-network? I'm running batman-exp rev1066. Regards /Stephan

2 1

[B.A.T.M.A.N.] deactivated/reenabled interfaces needs batmand restart
by Freifunk Dresden 15 May '08

15 May '08

Hello again, I'm running batman-experimental rev1023. Batman is running with two interfaces, one for wifi and one for backbone. The backbone interface is created by tincd a vpn deamon. If I have an active vpn connection batman recognizes the nodes at the other end of this connection. When the connection dead because the client has closed the vpn connection, batman is still working correctly. The problem occurres when the client re-creates the vpn connection. Batman ignores the interface. the log does not show incomming packages from the vpn-client. If I just restart batmand with the two interfaces, batman shows the packets within seconds and the node is reachable. Is there a way that the inactive interfaces are reactivated and used automatically? /Stephan

2 3

[B.A.T.M.A.N.] query regarding BAMAN for Mac OS X
by TARUN CHAPLOT 15 May '08

15 May '08

Hello I have two queries: Is the BATMAN available for Mac OS X and windows ? Is the BATMAN compatible with OLSR. Thanks Tarun

3 2

[B.A.T.M.A.N.] 0.3 final released
by Marek Lindner 15 May '08

15 May '08

Hello everybody, after a long release cycle (almost one year) the B.A.T.M.A.N. team is proud to announce the release of: - batman 0.3 stable - vis server 0.3 stable - batman advanced kernelland 0.1 beta We used the Wireless Community Weekend 2008 in the c-Base to release our newest version. Here are the main features in brief: batman 0.3: - TQ based routing algorith to overcome BATMAN III limitations - policy routing (see: http://open-mesh.net/batman/doc/RoutingVodoo) - policy routing script to fully control the routing table (see: http://downloads.open-mesh.net/batman/useful-scripts-and-tools/policy_routi…) - tunneling rewritten (only UDP based, blackhole detection and kernel module batgat for performance boosting) - parameters can be changed at runtime (routing_class, gateway_class, hna, preferred gateway) - routing_class support 4 different settings (see: http://open-mesh.net/batman/doc/InternetTuning) - interface watchdog (interfaces can be (de)activated dynamically) - packet aggregation (experimental) - official IANA port 4035 is used - RFC draft published batman advanced kernelland: - layer 2 meshing based on BATMAN TQ algorithm in kernelland - operates on any ethernet like interface - supports IPv4, IPv6, DHCP, etc - is controlled via /proc/net/bvatman-adv/ - bridging via brctl is supported - interface watchdog (interfaces can be (de)activated dynamically) - offers integrated vis server which meshes/syncs with other vis servers in range The latest version of batman layer 3 obsoletes batman 0.2 which is not supported anymore. The current version (batman 0.3) is the stable version from now on. Even though a version 0.4 might emerge we will continue supporting 0.3 for a long time period with security fixes and stability patches. Download our code and have fun ! :-) Greetings, Marek

7 16

[B.A.T.M.A.N.] Multiple radios to improve throughput
by Shane Chao 14 May '08

14 May '08

Hello, I have a 3 node mesh network with layout as follows: node #1 node #2 node #3 192.168.2.1 192.168.2.5 192.168.2.9 Each node has only one radio and #1 talks to #3 via #2 and vice versa. If I want to improve the throughput between #1 and #3, logically I would add another radio to #2 so it can communicate to both #1 and #3 simultaneously w/o having the single radio switching back and forth between #1 and #3. However, I ran IPERF between #1 and #3 before and after adding the second radio to node #2 and the bandwidth didn't really improve. In my node #2 configuration, I did not bridge the two wifi interfaces so I have ath0 and ath1 with their own IP addresses. All three nodes are configured with the same channel. My batmand command line for node #2 is: batmand ath0 ath1. Can anyone advise me on what I did wrong? Thanks, Shane

3 2

[B.A.T.M.A.N.] Node with two wireless interfaces - to bridge them or not?
by Predrag Balorda 02 May '08

02 May '08

I have one node that has two wireless interfaces. I was thinking to increase somewhat the multi-hop bandwidth loss and what is the best way of doing that. Currently I have ath0 with two nodes on there and ath1 with another two nodes but I'm not bridging those two interfaces. The thing is, they are on the same subnet so is there any point in keeping them "separate", any performance advantage, or should I just make a bridge and add the two ath's to it and just have a single IP and run batman on that one bridge or leave it as it is, with two IPs from the same subnet and run batman ath0 /w ath1 /w as I do currently? Pele

7 18

[B.A.T.M.A.N.] batmand-ex: inactive interfaces
by Freifunk Dresden 28 Apr '08

28 Apr '08

HI, I'm running batman-experimental rev1023. If I have an working interface which is deactivated (vpn restart) and activated later, then batmand first detects and ignores this interface but does not try to use the inteface again. I have to restart batmand with same interfaces and parameter. Within seconds the other nodes are recognized. Is there a way that the inactive interfaces are reactivated and used automatically? /Stephan

1 0

[B.A.T.M.A.N.] two radio nodes and alternative next hop
by Jan Hetges 24 Apr '08

24 Apr '08

Hi i'm running bmxd_rv972 for almost three months now, without any mayor problems :-)... thanks. what i recognized lately, on two nodes (the ones with more than one bmx interface), show alternativeNextHops, which are *NO* alternative. It seems there gets some 'information' lost between the two IFs. I suppose that's a known issue ;-), any ideas how to fix/workaround ? iirc, i saw once or twice a node "on the other interface" even listed as the bestNextHop. cheers --Jan

3 10

Re: [B.A.T.M.A.N.] Who can help with BATMAN-ADV integration into ROBIN-FW?
by elektra 23 Apr '08

23 Apr '08

Hi Phillipe - well, Freifunk and others around the globe are successfully using mesh as network infrastructure for their daily communication needs. (I'm using multihop mesh as internet uplink since 4 years). Here is how it works: Rather than using a zoo of different hardware use one that works, and that is the proprietary (I hate to support this!!!) Broadcom driver for the embedded Broadcom designs used in many 802.11b/g routers. Get this and go ahead deploying your network. You'll love it. Particularly if you use Freifunk firmware. This is one key to success nowadays. It is a pitty that Linksys USA is not selling WRT54GL's in the US (correct me if I'm wrong). So most people there are using Atheros SoC - Fonera, Meraki - which are all made by Accton/Taiwan. (Again, correct me if I'm wrong). While people in Europe, Africa and Asia are predominantly using WRT54GL. As far as I understood Antonio Anselmi, recent RO.B.I.N. firmware works stable in ad-hoc with Atheros SoC. I was working on a system for the Meraka institute in SA, for their 'Massive Mesh' grid, which was build to practically develop/test/verify mesh routing protocols and drivers. (I was running tests of OLSRD and all B.A.T.M.A.N. versions there.) I have patched an older Madwifi which works rock-solid in the Meraka mesh. There is only one issue: Fragmentation does not work. To be precise: If you enable it, the cards won't send data packets greater than the fragmentation value anymore :-( AFAIK this issue is still not solved. Running different Madwifi VAPs in ad-hoc and master mode is something I didn't test. Last time that I have tested it (quite a while ago) it was a hack. And I was happy if my machine didn't lock up after a while. Since I performed those tests several months ago I can't say much about it. I see it that way: Keep infrastructure clients separated from your mesh infrastructure - particularly keep clients away from your mesh channel. Otherwise you will degrade performance by using and re-using the same channel all the time. Even if Madwifi VAPs work stable-ish this doesn't perform well. A stupid but working access point is cheap, use the mesh as an uplink. Well, if all that you want is a very cheap mesh with a couple of nodes and want to accept performance issues, you may be fine with VAPs if the driver works. The new ath5k driver in the most recent Linux kernel works in ad-hoc, but has range issues. As could be read recently in the news, Atheros is actively sponsoring development of their hardware for the kernel now (they are paying a guy to develop drivers). cu elektra > Hi Elektra, > > I haven't replied on the list about my problems with mesh networks but > I think I narrowed my issues to exactly this: I have hardware at home > that just doesn't like to see an access point with an ADHOC interface > AND an AP interface. > > The weird hardware: my macbook pro (atheros based?), and a dell > truemobile 1400. > > The same setup works flawlessly with a D-Link G-630 PCMCIA. > > I don't know what to do to resolve these issues, but I will certainly > not deploy a mesh network in these conditions where maybe 30%+ of the > hardware doesn't work with adhoc mesh! > > Tonight I'll try to switch my access points to 802.11b only and see if > it's more compatible for adhoc+ap... > > If you have any clue as to what to tweak in Madwifi to help with these > compatibility issues, let me know :) > > On 22-Apr-08, at 3:00 PM, elektra wrote: >> >> In general the ad-hoc mode has been widely neglected by manufacturers >> and developers. From the first day I started to work on mesh networks >> I have been battling with firmware/driver issues. But as more and >> more people start using mesh networks the demand for working drivers >> is increasing. So we can expect that - finally, after many years - >> the situation will improve quickly. >

3 3

Re: [B.A.T.M.A.N.] Who can help with BATMAN-ADV integration into ROBIN-FW?
by elektra 22 Apr '08

22 Apr '08

Hi Philippe - > The WRT54GL's are available here (I'm in Canada), I'm sure it is also > available down in the US. > That's good to know. > We like the Atheros hardware (fonera, meraki) because it's so small in > comparison (unless your WRT54GL's are the ones with smaller footprint > than the old big blue model?) and because it's less proprietary than > broadcom hardware/drivers... It is small - ok. Things I like about WRT54GL: JTAG (even if you hose the system completely including bootloader you can restore it), serial interface, wide range DC-input (5-20 Volts), doesn't die if you reverse polarity, low power consumption (3.6 Watts under full load). Up to 250mW transmit power. Makes it ideal for my solar-powered home and developing countries, outdoor nodes, disaster areas and so on. Open up the housing and have a look at those *three* individual DC-DC converters for every internal voltage. Disclaimer: I am not working or getting paid by Linksys. I'm willing to utilize everything good that comes the way... Of course I don't like using proprietary code, this is sad. You know Linksys/Cisco had to be forced to their own good. They must be selling those devices like crazy. We have WRTs running on churches in a noisy area with many competing networks, each one linked to 15-20 other single hop mesh nodes. Somewhere around 30 single hop neighbors there is a limit for the driver/chipset, I suppose. The driver works rock solid. As soon as Madwifi or ath5k (with OpenHAL) can compete with that I'll be much more than happy. If I could utter a wish to a fairy coming my way I would also ask to have at least one good performing usb chipset for 802.11abgn that works with Linux as well. I'd start assembling omnis and directionals with usb-connector immediately ;-) Cheers, cu elektra

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N