First public release of the Nightwing Firmware source code

[Julio Cesar Puigpinos]

The LUGRo-Mesh [0] development team announces that it's already
avalaible the first public release of the Nightwing [1] firmware
version 0.5beta1 for the creation of 0-config wireless mesh networks
[2] for devices based on the Atheros wireless chip and that only needs
a minimun of 4MB of Flash memory and 16Mb of RAM memory to work, wich
differentiates it from other projects of its kind.

A forum [3], a mailing list [4] and the repositoy [5] are already
avalaibles. You can write in english and/or spanish.

[0] http://www.lugro.org.ar/lugro-mesh/en
[1] http://www.lugro.org.ar/nightwing/en
[2] http://en.wikipedia.org/wiki/Mesh_network
[3] http://lugromesh.smfforfree2.com/index.php?action=forum
[4] http://www.lugro.org.ar/mailman/listinfo/nightwing
[5] http://trac2.assembla.com/nightwing/browser

Saludos, Julio

--
www.lugro.org.ar/lugro-mesh Wireless Mesh Networks Group
www.lugro.org.ar GNU/Linux User Group Rosario, Argentina
NO A LA MATRICULA!!!: http://noalamatricula.wordpress.com/
Registered GNU/Linux User #358886

[Robbt]

Hey, there has been no traffic in here but SPAM and vacation responses
for a little while so I wanted to post something relavent to the group
and see if others are out there working on similar projects and have any
advice.

We are working to deploy a volunteer ran wifi mesh project in a
low-income neighborhood adjacent to the university here in Columbus,
Ohio. We purchased the open-mesh routers which I think are flashed acton
routers, and I just wanted to see if anyone had any advice about
antennas to connect to these and what the connectors are. I should just
research it over the web, but I was hoping someone could provide links
who is already using these. We are looking at setting up a free open
network primarily orientated towards residents and the batman/r.o.b.i.n
protocl and openmesh web interface seem pretty rad so far. We did a test
deployment during a community music festival and it worked to a degree
but we figured we needed larger antennas to extend the range and
overcome some of the interference.

Anyways, just thought I'd see if there was anyone else out there working
on similar projects.

Robbt

[ge...@w3websites.com]

Yes,

We're working with the Open-mesh.com products and they have definitely
improved a lot over the last 30 days. Range has been a real problem because
of the Atheros driver. Open-Mesh.com has been working with Atheros on
implementing a new Atheros driver for the Acctons and is now testing it - I
expect some great results on range within weeks. One little tidbit I heard
is that the Acctons are actually able to run at much higher transmit output
than they are presently doing so that on its own could take care of the
range issues but I expect the new driver will clean things up even more.

I wouldn't mess with antennas - the stock 2dB antenna is a very good
omni-directional antenna. Higher gain antennas focus the energy in a much
thinner plane which makes positioning very critical. My advice is to just
add more repeaters instead of bigger antennas. The Acctons are so low cost
that the cost difference of higher density installations is minimal.

Go to the http://robin.forumup.it/ to keep up on the latest in the
Open-mesh.com world.

Gerry

[Ian]

Yes... still at it!! Sorry about the spam! Have now erased what i
could find!! My biggest pain recently has been to try and reflash our
"merakis" after the open-mesh hiccup! Anyone else managed to get them
all back up? So far at SnS we have only 2 of the original back up! Its
only a test mesh... but its a pain. Obviously our compaq Robix were un
affected and they reliably are still plodding on! But it takes
time... Havent bought any accton units ourselves yet.... most of our
existing networks are long range stuff currently using Locustworld
MeshAP boxes and am concerned over the low power of the Accton
units... but as Gerry posted... range is improving....

[ge...@w3websites.com]

Hi guys,

Open-mesh.com have finally determined that all the range problems were
Batman specific and are about to roll out an update to move to "OLSR" away
from batman which addressed all the problems regarding range and sensitivity
and routing. The Robin part stays so it will be a Robin/OLSR setup.

I also found out that the existing Acctons can crank out up to 300mw and
soon there will be a power setting parameter in the open-mesh dashboard - on
a per node basis.

Right now - testing the OLSR - the range is fantastic with the 2dB antennas
so there won't be much of a need for trying bigger antennas. I would reserve
larger antennas for point to point directional antennas to shoot your
wireless signal to remote points up to a few miles away.

Gerry Bakker

-----Original Message-----
From: opensou...@googlegroups.com
[mailto:opensou...@googlegroups.com] On Behalf Of Ian
Sent: Saturday, September 27, 2008 2:01 PM
To: OpenSourceMesh
Subject: [opensourcemesh] Re: Working to deploy a community wireless network
with OpenMesh

[Julio Cesar Puigpinos]

2008/9/27 :
>
> Hi guys,

Hi

> Open-mesh.com have finally determined that all the range problems were
> Batman specific and are about to roll out an update to move to "OLSR" away
> from batman which addressed all the problems regarding range and sensitivity
> and routing. The Robin part stays so it will be a Robin/OLSR setup.

I'm curious about how did you arrive to that conclusion.

What problems where you having with the range, sensitivity and
routing? And why you conclud that B.A.T.M.A.N. was the problem?

> [...]
>
>
> Gerry Bakker

Saludos, Julio

--
www.lugro.org.ar/lugro-mesh Wireless Mesh Networks Group
www.lugro.org.ar GNU/Linux User Group Rosario, Argentina

Slackware rulez :P www.slackware.org

[ge...@w3websites.com]

Julio,

After lots of hard work and experimentation amongst a lot of people it was
determined that Batman was the problem. Substituting other routing protocols
like OLSR or Roofnet fixed the problems we were experiencing.

Gerry

-----Original Message-----
From: opensou...@googlegroups.com
[mailto:opensou...@googlegroups.com] On Behalf Of Julio Cesar Puigpinos
Sent: Saturday, September 27, 2008 4:01 PM
To: opensou...@googlegroups.com
Subject: [opensourcemesh] Re: Working to deploy a community wireless network
with OpenMesh

[Julio Cesar Puigpinos]

2008/9/27 :

>
> Julio,
>
> After lots of hard work and experimentation amongst a lot of people it was
> determined that Batman was the problem. Substituting other routing protocols
> like OLSR or Roofnet fixed the problems we were experiencing.

Could you be more explicit, please?

You say problems about range. Do you mean problems in routing thru
distant nodes or the WiFi coverage of every node?

Thanks in advance.

> Gerry

[ge...@w3websites.com]

Both were symptoms because the routing created so much data noise with
constantly changing routing messages that it would eventually bog down with
the routing data with no room left for the actual data you wanted to
transfer. The net result is that the switch to a new protocol resulted in
data throughput more than doubling and range between repeaters meeting or
exceeding what Meraki could accomplish with their roofnet.

Apparently batman would reduce effective bandwidth with a lot of lost
packets and data collisions to the point where one hop out was worse than
6-8 hops out with Roofnet or OLSR. I heard reports of 90% lost packets with
batman and now zero loss with OLSR. Now you can go a number of hops out
without and packet loss.

Gerry

-----Original Message-----
From: opensou...@googlegroups.com
[mailto:opensou...@googlegroups.com] On Behalf Of Julio Cesar Puigpinos
Sent: Saturday, September 27, 2008 4:56 PM
To: opensou...@googlegroups.com
Subject: [opensourcemesh] Re: Working to deploy a community wireless network
with OpenMesh

[Stephen Ronan]

That's very interesting and helpful to know. I'd be grateful for any
additional detail as those experiments continue.
The tests reported here:
http://wirelessafrica.meraka.org.za/wiki/images/9/98/Batman_ifip.pdf
wouldn't lead one to expect those results.
I wonder what are the key differences in the test conditions that create
such contrasting results.
- Stephen Ronan

[ge...@w3websites.com]

Stephan,
I am not the source of any of this information - I am just passing on
anecdotal information I am hearing from different sources.

I understand that Batman was created in response to OLSR not performing as
it should. Batman efforts were very busy for a year and died down to the
point where you can't get any help from anyone so for more than a year it
has not improved at all. While Batman sat on the side with no improvements -
OLSR efforts kicked into high gear to find and fix the problems it had. The
net result is that Batman never really worked as advertised and although
OLSR didn't work well at first it now seems to work very well.

I am certain you'll hear much more about this from the open-mesh.com people
in the next week or so.

Gerry Bakker

-----Original Message-----
From: opensou...@googlegroups.com
[mailto:opensou...@googlegroups.com] On Behalf Of Stephen Ronan
Sent: Saturday, September 27, 2008 5:53 PM
To: opensou...@googlegroups.com
Subject: [opensourcemesh] Re: Working to deploy a community wireless network
with OpenMesh

[Stephen Ronan]

I think that the research reflected in that paper I referenced used a
quite recent ("OLSR-NG") version of OLSR, version 0.5.5 (the current is
0.5.6).
And it has been my sense that the BATMAN developers have continued this
year to feel confident that BATMAN outperforms OLSR in organically,
growing meshes such as in Berlin, where OLSR didn't perfom as well as it
did in more carefully structured environments such as in Vienna.
But I have great faith in the ability of the open-mesh team to
effectively assess what will work best with RO.B.IN on the Acctons and
thank you for conveying the exciting news that OLSR seems to deliver
substantially improved performance.
- Stephen

[Stephen Ronan]

I've asked a principal BATMAN developer, Marek Lindner, if he has any
thoughts about what the open-mesh folks are seeing as reflected in your
comments, Gerry, and he just responded as follows:
--------------------------------------------------------------------------
I heard they had problems with instability and I helped debugging. I was
not
aware of the fact that the many packages are the problem. Batman has an
aggregation feature since March this year to deal with this issue
(https://dev.open-mesh.net/batman/changeset/987). You can use --aggregation
to enable it. Obviously you would need a batman version higher than 987. I
think Robin still uses a version from January this year.

Is this an assumption or a fact that the number of packages is the
problem ?
Usually, the CPU load goes up long before it is a problem on the wifi layer
(especially on the small CPUs).

Greetings,
Marek
---------------------------------------------------------------------------

It's beyond my techie grade level to be able to analyze this issue
effectively and helpfully respond to Marek. But it does seem that we
should be sure that the tests with Acctons are taking advantage of the
most advanced available versions of each protocol. Who are the main
folks involved in the recent testing?

- Stephen

[Stephen Ronan]

In regard to keeping track of BATMAN development. Marek suggests:

"If you want to follow the commits have a look here:
https://dev.open-mesh.net/batman/timeline

"If you want to follow the discussions subscribe to our mailing list:
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n or read the archives.
It is not a high traffic list but the best point to get in touch with us or
get info regarding releases."

- Stephen

[Julio Cesar Puigpinos]

2008/9/27 :

>
> Both were symptoms because the routing created so much data noise with
> constantly changing routing messages that it would eventually bog down with
> the routing data with no room left for the actual data you wanted to
> transfer. The net result is that the switch to a new protocol resulted in
> data throughput more than doubling and range between repeaters meeting or
> exceeding what Meraki could accomplish with their roofnet.
>
> Apparently batman would reduce effective bandwidth with a lot of lost
> packets and data collisions to the point where one hop out was worse than
> 6-8 hops out with Roofnet or OLSR. I heard reports of 90% lost packets with
> batman and now zero loss with OLSR. Now you can go a number of hops out
> without and packet loss.

Thanks for the info, altough my tests with latest B.A.T.M.A.N. are
pretty good :)

I have to say that OLSR-NG was discarded, to be used by our project,
because of known problems in OLSR, like routing loops and protocol
overhead (among other things). Also the results of several reports
(like the one mentioned by Stephen Ronan, made by the Meraka
Institute) pointed out those and more issues. And the no less
important, but personal point of view :), about the "philosophy" of
the project.

[Julio Cesar Puigpinos]

2008/9/28 :

>
> Stephan,
> I am not the source of any of this information - I am just passing on
> anecdotal information I am hearing from different sources.
>
> I understand that Batman was created in response to OLSR not performing as
> it should. Batman efforts were very busy for a year and died down to the
> point where you can't get any help from anyone so for more than a year it
> has not improved at all. While Batman sat on the side with no improvements -
> OLSR efforts kicked into high gear to find and fix the problems it had. The
> net result is that Batman never really worked as advertised and although
> OLSR didn't work well at first it now seems to work very well.

I have to say that I have seen, and looks like it will continue this
way, a lot of improvements in B.A.T.M.A.N. (in all flavors) in the
last months and days.

> I am certain you'll hear much more about this from the open-mesh.com people
> in the next week or so.

That would be very helpfull (something like a detailed report about
the problems, the tests made and more), otherwise is like shooting in
the dark :P

Thanks for your replies.

> Gerry Bakker

[Julio Cesar Puigpinos]

2008/9/28 Stephen Ronan :

Knowing wich version was used in the tests, is important. If Ro.B.In.
is using and old B.A.T.M.A.N., all the improvements made, like the one
mentioned by Marek (packet aggregation), will be missed :(

Like I said in another email, a detailed report would be very helpfull.

> - Stephen

[Stephen Ronan]

Looking a bit through archives of the BATMAN email list this year, I
found these messages to be especially helpful::
https://list.open-mesh.net/pipermail/b.a.t.m.a.n/2008-April/000692.html
https://list.open-mesh.net/pipermail/b.a.t.m.a.n/2008-April/000697.html
https://list.open-mesh.net/pipermail/b.a.t.m.a.n/2008-April/000693.html
Makes it sound as if it's not problems necessarily inherent to use of
the BATMAN protocol, but in substantial part problems with
BATMAN/RO.B.IN working with the Atheros SoC and available drivers and
limited RAM.
I'd be interested to see further speculation on why OLSR may work better
in that context while BATMAN may work better than OLSR using Linksys WRT54GL
And keeping in mind that the research I had referred to here:
http://wirelessafrica.meraka.org.za/wiki/images/9/98/Batman_ifip.pdf
where BATMAN apparently somewhat outperformed OLSR, had used an Atheros
card, but with a relatively powerful processor and lots of RAM
"Each node in the mesh consists of a VIA 800 C3 800MHz
motherboard with 128MB of RAM and a Wistron CM9 mini
PCI Atheros 5213 based Wi-Fi card with 802.11 a/b/g capability."
- Stephen Ronan

[Antonio]

Hi all


to be clear: ROBIN has not moved away from BATMAN *but* it now
supports also OLSR.
People can chose between OLSR and BATMAN according their preferemces,
according to the performances related to location of the network,
according to some other issue.
I'll continue to maintain full support to both the routing protocols.

thanks

Antonio

[Stephen Ronan]

Antonio

Marek had wondered whether reported problems with ROBIN + BATMAN might
be related to the fact that ROBIN includes many packages and said that:

"Batman has an aggregation feature since March this year to deal with
this issue
(https://dev.open-mesh.net/batman/changeset/987). You can use --aggregation
to enable it. Obviously you would need a batman version higher than 987. I
think Robin still uses a version from January this year."

Have you had a chance to see whether the aggregation feature helps? What
version of BATMAN is currently being used?

Thanks for all your great work!

- Stephen Ronan

[Antonio]

BATMAN used in robin is revision 964 BUT it's patched and not the
plain version you can get by SVN: so simply changing revision would
mean hard backward in porting with the risk of losing some features
specially written for robin.

I assure that the project will continue to support BATMAN but I have
to find the best way to do it and perhaps choose between the two
branches BATMAN ADV and BATMAN EXP the most interesting and most
suitable for the project itself.
To be clear, we need something that could be simply switchable by
dashboard without ever having to add new options and new parameters
that make it difficult configuration to not so skilled people.

Moreover, I feel that a clarification is necessary.

Do not forget that usually both BATMAN and OLSR are used as "routes
makers": to say that the routing protocol runs in its own box in order
to offers routes to the box itself (the daemon runs inside a laptop or
a PC) or to wired-connected clients while in our project the daemon
offers routes to wirelessy connected clients.

Why this makes the difference? It's simple.

Assume a classic environment:

- a wireless router running BATMAN or OLSR
- a client laptop plugged to the router

in this scenario the wireless router (usually a Linksys) runs wifi in
ad-hoc mode .

now let's see at robin environment:

- a wireless router running BATMAN or OLSR
- more clients wirelessy associated with the router

in this scenario the wireless router (our fons, merakis, acctons,...)
CANNOT use ad-hoc mode but it is forced to use the less performant
ahdemo mode ('cos ad-hoc mode is not compatible with the needed
simultaneous AP mode).

This is the question and the main difference that we have to know and
fully understand : ad-hoc vs ahdemo.

I do not want to bore you here with the analysis of the two modes (it
can be easily recovered browsing the internet) but the most relevant
difference is that ahdemo (the one used by robin) doesn't have
collision detection and this feature affects more BATMAN than OLSR
just because of the high number of packets sent by BATMAN.

Yes, surely OLSR is more tested and widely used, surely both the two
have interesting features but - as in feedbacks - it seems that OLSR
is better than BATMAN
BUT
all have to be deeper tested and always related to our own working
conditions (!), what I'm saying is that using ahdemo mode OLSR seems
more performant than BATMAN.
So, in my opinion, the different performance is firstly due to the
used wireless mode rather than to the protocol internals, or, in other
words, OLSR seems more suitable for ahdemo environments.

[Stephen Ronan]

Thanks for the thorough explanation and all your great work, Antonio.
And I was pleased to see your message today on the Robin forum
indicating that, after the beta-1-3 Robin release, you will be working
with BATMAN maintainer Marek on a test version that will support the
current BATMAN branch.
http://robin.forumup.it/about867-15-robin.html
- Stephen Ronan

Antonio wrote:
> BATMAN used in robin is revision 964 BUT it's patched and not the
> plain version you can get by SVN: so simply changing revision would
> mean hard backward in porting with the risk of losing some features
> specially written for robin.
>
> I assure that the project will continue to support BATMAN but I have
> to find the best way to do it and perhaps choose between the two
> branches BATMAN ADV and BATMAN EXP the most interesting and most
> suitable for the project itself.
>
>

[...]