Hi everyone, I've spent the past few weeks trying to find routers without
blocked firmware and test small deployments of Libre-Mesh. First off, are
there any online tutorials / walkthroughs on installation? I'm basing
everything off one workshop I went to.
I'm at the point now where I have a two Ubiquity airGateways and one
airRouter flashed with builds from here <
are able to broadcast the Libre-Mesh and Libre-Mesh/routerID SSIDs.
But I'm unable to open the router settings. Since I've flashed, I haven't
been able to access any router using any of the following: 192.168.0.1,
192.168.1.1, thisnode.info or http://anygw.
Any tips about what steps I can take next to debug what's going on? I have
no prior experience with Libre-Mesh or OpenWRT so you may have to speak
very slowly to me. Thanks,
Some more-or-less techie friends are meeting tomorrow evening to learn
to compile the code.
The idea is to be able to recycle many of those old ISP routers the
community members say they have. Hopefully they will become nodes of our
future Libre-Mesh networks.
We will follow the steps in the website, but it'd be nice if any of you
could show up tomorrow evening in your IRC channel. Just in case we need
I'm forwarding this discussion because it contains two interesting concepts:
* the Battlemesh community is opening to new testbeds for tests (would
make sense to create one based on LiMe? Just asking... I'm not able to
* the Battlemesh community is looking for a permanent outdoor testbed
(something similar (but no need for being outdoor) would be great also
for LiMe testing)
---------- Forwarded message ----------
From: Benjamin Henrion <zoobab(a)gmail.com>
Date: 2016-05-09 9:36 GMT+02:00
Subject: Re: [Battlemesh] No results again
To: Battle of the Mesh Mailing List <battlemesh(a)ml.ninux.org>
On Mon, May 9, 2016 at 12:35 AM, Nemesis <nemesis(a)ninux.org> wrote:
> Hi everyone,
> I'm sorry to disappoint who's following this list and who was waiting
> for results, but this year we have none.
> We tried very hard, but a series of mistakes and technical issues
> delayed the tests until it was too late.
> I understand what we are doing is hard, but I really do not buy nor
> endorse the argument that we did not have enough people involved or is
> just too hard, because we had several people participating and 3-5
> people constantly working on the testbed. I remember especially Guido
> Ibarren and Alessandro Gnagni working tirelessly.
> We have to realize and accept we have failed for precise reasons, the
> approach we used is not effective. Please do not get aggressive or
> Having worked on the testbed actively, I also failed, so I also assume
> responsibility for failure.
> To sum up, I attribute the failure mostly to these reasons:
> * slow iteration: for every iteration we had to wait wibed nodes to be
> ready, but every time there was a different problem to debug because
> nodes were not becoming ready
> * lack of communication; I tried hard doing daily briefings and FAILED
> miserably; it just won't happen if we don't schedule them in advance and
> enforce them by taking the microphone and asking all the poeple involved
> to stop doing what they are doing and go there to report what problem
> they have and how other people can help
> * configuration mess: complex configuration, too many changes
> I really love the battlemesh: there has never been another event I
> attended 5 years in a row. I love it also because of the test battle.
> Without this peculiar feature the event would be just another conference
> and I'm not sure I would be willing to come every frigging year: there
> are so many conferences I want to attend but I can't got to all of them,
> I have to choose and I allocate a slot to the battlemesh every year
> because its unique mixture of technical talks and live hacking.
> Therefore I don't want to give up the battle and I don't think getting
> results is a mission impossible. That's why at the next battlemesh I
> want to try a different approach.
> After having worked with wibed I can say without doubts that I'm not
> interested in fixing it. At work I manage thousands of OpenWRT devices
> every day without any issue, configurations get updates in minutes.
> I think other solutions to accomplish the same tasks exist, are simpler
> to use, better maintained and more effective.
> I also think we should not hold a monopoly on the testbed, especially if
> the current approach has failed more than once. There are about a
> hundred people coming to the battlemesh, I firmly believe we can afford
> having 2 to (max) 3 testbeds taken care by different groups of people
> who can then run the tests they are most interested in.
> Last year (battlemesh v8 in Slovenia) the failure of the wibed testbed
> was attributed to me and other people who worked on a manually run
> testbed which according to them split the workforce.
> This year we all worked on a single testbed, including all the routing
> protocol developers that were present, and it didn't work.
> Next year please do not attack or blame those who want to try a
> different approach.
> I'm really looking forward to the next battlemesh and I hope we'll all
> be reasonable people, find solutions, compare approaches and use the
> most effective ones that allows us to get results.
You still hit the same problems as we had 10 years ago, it takes too
much time to get a decent testbed running.
I have long time advocated for a permanent outdoor testbed somewhere,
where people could run their scenarios.
I'm using lime-build and wondering how to include
lime-hwd-ground-routing in the image file produced.
I copied the target file for my router in the configs/targets directory
and add just the line CONFIG_PACKAGE_lime-hwd-ground-routing=y
Is there a better and more general way?
As some of you have already noticed, there is a new web page hosted
under the domains libre-mesh.org and libremesh.org. It has been quickly
created because of the `old` server crash.
The cool thing is that the whole web is stored into a Git repository
named lime-web . So anyone with commit rights can add/modify content
just editing the plain text files of the git repository. Also
push-requests are accepted.
It uses asciidoc  for parsing the source files and generate a bunch
of static HTML files (what you see in the web site). There is a helper
script (generate.sh) which executes the proper commands to do such task
(the only required packet is "asciidoc", which is present in most of the
linux distribution repositories).
There is a crontab task in the server which pull the git repository
every 20 minutes and execute the helper script. So if someone makes some
change in the git repository it will be applied at most after 20 minutes.
In addition there is a special directory named "doc" which will contain
the technical documentation, for instance there might be an article
explaining how the uci lime config file work or another talking about
setting up the proper wifi parameters.
We make a CALL for everyone who would like to contribute with the web
page to do it. You don't need access to the server, just download and
modify the git repository. Any kind of help is welcome:
- New content
- Text corrections
- Technical documentation
- CSS styles