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?
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
other nodes are recognized.
Is there a way that the inactive interfaces are reactivated and used
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.
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
Get this and go ahead deploying your network. You'll love it.
Particularly if you use Freifunk firmware. This is one key to success
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
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).
> 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.
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
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 ;-)
I setup 3 nodes on OpenWRT Kamikaze and B.A.T.M.A.N 0.3, using atheros
My gateway is started this way: batmand -g 5Mbit/1Mbit -a
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...
> 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 ?
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 .
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
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
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
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)
> 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
> 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