B.A.T.M.A.N April 2008

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

21 participants
13 discussions

[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

[B.A.T.M.A.N.] Node keeps switching back and forth
by Philippe April 18 Apr '08

18 Apr '08

Hi! I setup 3 nodes on OpenWRT Kamikaze and B.A.T.M.A.N 0.3, using atheros chipset. My gateway is started this way: batmand -g 5Mbit/1Mbit -a some_subnet... ath0 My nodes: batmand -r 2 -a other_subnets... ath0 Let's call them "gateway", "node1", "node2". "gateway" is in my basement. "node1" is upstairs. "node2" is in the shed. node1's connection to gateway is strong. node2's connection to gateway is very weak, about 50% packet loss. node2's connection to node1 is strong. Knowing this: does anybody have a clue to why my node2 keeps switching from node1 to gateway? I connect to node2 and ping on the internet constantly, I see the node switching back and forth from node1 to gateway, sending some of my packets to one, or the other... basically the user experience is horrible. I was missing FW masquerading rules until yesterday, things were not working at all when I was not going through the gateway directly, but that "seems" to be resolved, now packets go by "sometimes". If node2 could stick to using node1, it would be easier to troubleshoot. I'm trying to move my nodes as far as I can so it can't connect to the gateway directly at all from node2 but the shed does not seem to be far enough :) Thanks for any enlightenment... Philippe April

6 19

Re: [B.A.T.M.A.N.] Batgat on kamikaze 7.09
by Marek Lindner 15 Apr '08

15 Apr '08

Hi, > I am getting the message "Unable to resolve ip_hdr" while trying to load > batgat(r 963) on openwrt kamikaze 7.09 > Batman however runs with tun module loaded. > Any suggestions on what i am missing . which kernel version are you using ? Greetings, Marek

2 2

[B.A.T.M.A.N.] Batgat on kamikaze 7.09
by Vinay Menon 14 Apr '08

14 Apr '08

Hello, I am getting the message "Unable to resolve ip_hdr" while trying to load batgat(r 963) on openwrt kamikaze 7.09 Batman however runs with tun module loaded. Any suggestions on what i am missing . -- Vinay Menon

2 2

[B.A.T.M.A.N.] Suitability of B.A.T.M.A.N. protocol to my disaster relief network project
by Tim LePes 14 Apr '08

14 Apr '08

Greetings! If this list is the wrong place to be asking about this, please let me apologize up front. :) I am working on a project based around the Genesi EFIKA 5200B SoC development board. You can find more details about the board by visiting "http://www.genesi-usa.com/efika.php". The basic idea for my project is that of an ad-hoc long-range wireless mesh network infrastructure that can be easily set up by disaster relief workers. The inspiration came from stories out of the hurricane Katrina disaster in Louisiana and Alabama. Please let me tell you about the project a little, and hopefully you may be able to give me some advice - both general and specific to the suitability of using the B.A.T.M.A.N. protocol. I understand that you have far more experience with real-world applications of wireless mesh networking than I, so any feedback will be greatly appreciated! In the scenarios I imagine, a relief effort could quickly erect a series of towers (telescoping poles?) with a wireless mesh node at the top, in a weatherproof case. The mesh node can be powered by a generator or whatever other means available. The purpose of the mesh is to provide a network infrastructure out to areas that may have lost all traditional connectivity and infrastructure. Generally, the idea is to bring connectivity from one or more internet-connected points out to the areas where you would have shelters set up, such as a Red Cross tent or other similar congregation point for disaster victims. The mesh node would connect them to each other (other sites in the field) and, ideally, back to the internet. However in the event that it is not easy to get internet connectivity to the mesh, it will still be useful for sites in the field to communicate and coordinate with each other. At the shelter, then, would be a mesh node up on a pole. The device would act as a gateway, offering network connectivity to anything attached to it's 10/100 ethernet port. It would be a DHCP server and could provide connectivity to one or more computers (with the help of a hub). The computer(s) would be used to access web-based services for things such as logistics, people-finding service, access to government and/or NGO relief agency web sites and services, etc. There is another project I found that I hope to tie into my project, and that is SAHANA. From their web site, "Sahana is a Free and Open Source Disaster Management system. It is a web based collaboration tool that addresses the common coordination problems during a disaster from finding missing people, managing aid, managing volunteers, tracking camps effectively between Government groups, the civil society (NGOs) and the victims themselves." Their web site is "http://www.sahana.lk/". The main consideration is that it be as easy as possible for emergency response and other disaster relief workers to physically set up this network. So my hope is that the network can be largely self-configuring, self-monitoring, and self-healing. Thus an ad-hoc mesh design. I would imagine that in some situations, the network would be a simple mesh cloud connecting people on the ground to each other. In other situations, and ideally, connectivity to the internet would be established through one or more nodes in the mesh. I could see that sometimes certain nodes may not really play the role of a mesh node so much as a repeater, to get the connectivity strung out over some distance. I am thinking of putting WiMAX radios in the mesh nodes, for the purported range. There are several things that I am unsure of, so any suggestions or comments on any points are more than welcome. Forgive me if I just ramble out some of my thoughts/questions here... Is WiMAX a good choice for this? I have not really seen a lot of WiMAX hardware. The SoC board will be running Linux and is a PowerPC architecture, so drivers will of course be important with whatever radios go in the device. Would it be best to have two radios in the mesh nodes? If only one is needed, then perhaps I can put one WiMAX for the backhaul and one regular WiFi 802.11a/b/g and provide a WAP for the downlink sites. Or simply save on the BoM by only using single radios. Or maybe single radios would work for the nodes comfortably "meshed" with others, but dual-radios could be used in a directional repeater node specifically made to extend the mesh connectivity over distances? Or do I have that backwards? Maybe multiple radios would be better for the chatty meshed-up nodes versus the far-flung nodes making a chain back to the internet connectivity points at the periphery of a disaster area. I am certainly open to any suggestions on other technologies to consider, too. How well do BATMAN or other meshes scale? What is the ideal density for nodes in the mesh, and how much better does it get with more node density before you have a diminishing return? How bad is the latency? Is VoIP do-able? Is it do-able for a few hops (like between field sites) but simply not do-able for longer trips out to the periphery of the mesh, where the internet connectivity is likely to be? Is this even the right approach to this sort of connectivity problem? I can see a mesh being useful for field-sites communicating with each other. But often I have seen that the ideal with a mesh is to have the internet-connected nodes be in the center of the mesh whereas in this scenario, typically, the internet connection is only to be had at the periphery. Would it be better to have a split role system where long-range internet connectivity is brought out over distance using some long-range repeater set-up, and the mesh spawned off from the end-point of this line? (Or multiple such lines)? How much does the actual routing of traffic tax the processor in a mesh node? These boxes have 128Mb and can have a hard drive or SSD in them. They run a fairly complete Linux on them. I am already imagining they can be managed via http with a web interface fairly easily. But I am curious to find out how much more room I have to run other softwares. I have thought of them having the ability to boot found/donated PCs over PXE and bootstrapping Linux on the computers, served by the mesh node (now a pxe/bootp server in addition to dhcp), to make quick and easy internet terminals/kiosks. Other possibilities include running squid caches on the nodes to reduce back-haul traffic when many folks are visiting the same sites, or even having them optionally be able to block traffic based on either white or black lists, and since the SoC boards have audio in/out, they could be used as a VoIP phone over the network. Besides having a data network for email and web access, simply being able to simply talk to each other between sites using the device could be very valuable. Especially when traditional communications such as cell phone and land-line networks are down. And being built into the mesh node, there would be at least voice communications available immediately that way, even before other devices are networked to the mesh nodes. There is a serial port, so keypads are a possibility. I would like to make the network as dead-simple to set up as possible. Emergency workers have enough to worry about without having to become network experts. At most I would expect that they could connect a laptop to the Ethernet port and configure the devices with a web interface. But ideally I would like there to be zero configuration on-site, if possible. Plug and go, so long as you're in range. Of course there would have to be some management console (probably web based) to get an idea of signal strengths, network performance, etc. for troubleshooting and fine tuning the network. Well anyway I have several ideas running around for this project, including other devices that would network in and serve different roles. But it all depends on the feasibility of constructing a wireless networking infrastructure. I don't want to take up too much of your time rambling on, so as I said, any feedback is welcome. As are any questions you may have. Genesi have been gracious enough to give me the development board for my project, so I am anxious to make some headway. Thanks so much! Tim LePes (a.k.a. Mojo)

3 2

Re: [B.A.T.M.A.N.] AHdemo mode
by Marek Lindner 11 Apr '08

11 Apr '08

> still that can be better than no security at all... I think before you start throwing crypto, keys, certificates, etc on something you/we should evaluate whether there are others ways. Also, it is important to realize that encryption itself does not make things secure (encryption != security). If we start talking about "no security at all" I'd rather ask first what we are securing and against whom ... > i basically agree, but some people might like to set up a more controlled > environment. even in a community network this might be useful at times, for > example if you want to set up a backbone network. So, we are starting to talk about these rare cases, right ? > one way to solve this without a static key which has to be known to all > nodes is using a public key infrastructure (PKI) with a certificate > authority (CA). the clients can generate their own private and public keys > and send the public key to be signed by the CA. that could go hand in hand > with adding their nodes to a map and accepting some basic agreement (pico > peering). after it has been signed they could start using encryption for an > extra level of mesh security. I think many things would be _possible_ but I don't see that happen. But why everything has to be so complicated ? Do you read that: static key, PKI, CA, private and public keys, signed by the CA, .... Only a few people master this kind of security properly. The only end user PKI that "works" out there are web certificates and their level of security is more ashaming. > that's true, but it doesn't help if the underlying mesh protocol can be > disturbed easily by un-authenticated nodes and your traffic never reaches > the other endpoint. > > there are two different layers of adding authentication and encryption. one > is the mesh protocol itself the other one is end-to-end user encryption. > both are necessary if you want to make your network secure. I can't agree here. I believe a well designed mesh protocol which is more resistant out of the box is mucher better than this encryption bloat. If you *really* need the encryption, please use one of the established and widely tested security protocols for the lower layers. Encryption is incredible hard to do right and we are definitely no experts in this area. We want to develop a slick, fast routing protocol. If you want this level of security I *strongly* vote against a home made "security plugin". Keep in mind that security is a concept and not something you can simply enable. Greetings, Marek

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N April 2008