Hi.
After working and testing lime-build, I think we can publish again the
link to http://downloads.libre-mesh.org. I've tested (also Ilario) the
resulting images and they work fine.
Good point is that now we have many more targets (routers) available.
I've even tested different architectures such as x86 (which works fine)
and RAMIPS (which does not work fine in Ad-Hoc but it does in 802.11s mode).
We can discuss this deeper in some IRC meeting, but I would like to
invite all developers to use lime-build (¿again?) for releasing stable
versions of libre-mesh and for keeping develop working for everyone.
Cheers.
Hi.
I've been working on a huge modification for lime-build. The idea was to
simplify it by removing some functions which were not used anymore and
make it more adapted to our current needs. I hope this way we will
manage to use it by default.
I've add a new concept for Profile, which might be for instance:
generic, freifunk or chef (easy configurable in profile.mk). So this
should be enough to compile one of them:
make info
make T=ar71xx P=freifunk
But please, take a look on the README to know more:
https://github.com/libre-mesh/lime-build/tree/v2.0
I've based it on develop, so right now only compiles develop. If
everything works as expected and we all agree, we can migrate the rest
of the branches.
Testing, bugs, pull-request are welcome!
Cheers.
Hey folks,
i just revived the old redmine (that suffered an extended downtime
around may), in order to look for content that needs to be migrated or
recovered,
http://old.libremesh.org (https will give a cert warning since domain
changed)
the site is only meant to recover data, since it will probably be down
again at some point in the future. (i.e. don't link to it)
also it would be great to make a list of URLs and try to make them work
(redirect to relevant content) in the new site, in order to not break
all the links that are already published around pointing to
dev.libre-mesh.org or anything in /projects for example
I can take care of the second idea (say, in a few weeks) with an nginx
redirect table (legacy link -> new location)
but i'd need help for the first (migration), most probably from the
content creators? al, pau, gio, ilario, etc?
cheers!
ps.
Hi all!
As pointed out in the LiMeCat notes, Chef adds to Libre-Mesh a few scripts.
Some of these are needed for Chef to customize the build, some others
should be included in lime-packages if we want lime-build to produce
images as good as the ones from chef.
For example
/etc/uci-defaults/95_add-sshkeys
/etc/config/lime-defaults
/etc/chef_version
are needed for some of the customization features of chef (but the
lime-defaults file should be up to date with the one in
lime-packages).
While *in my opinion* these files should be moved from chef to
somewhere in lime-packages:
/usr/sbin/reset_deaf_phys.sh
/etc/uci-defaults/93_enable-reset-deaf-phys
/etc/config/libremap
/etc/uci-defaults/93_ugly-fixes
/etc/uci-defaults/95_reboot-daily
/etc/uci-defaults/95_snmpd
/etc/uci-defaults/95_set-timezone
/etc/uci-defaults/95_set-remote-syslog
Gui, is there some of these files we can skip as won't be useful in
the next stable release?
Byyee!
Ilario
I'm working in a new look for the libre-mesh web, again based on the
work made in lede-project.org
This time we are using jekyll + asciidoc to generate the pages. So the
syntax will be the same, just the generation of HTML will be different.
Good points are that it is more automatic so more comfortable for
adding/modifying content, more flexible than just using raw asciidoc and
the CSS stuff rocks (web responsive!).
Bad point is that it depends on ruby, gems, bundler and more stuff, but
it is only a server requirement, we can keep editing the pages using
plain text and git.
Here you can visit the current status of it: http://test.libre-mesh.org
Once I finish the migration I'll push it to the lime-web git repository.
Comments, critics, advises are welcome.
Cheers.
Hi!
I'm currently helping to switch from some ancient OLSR1-based
hand-crafted and hard-to-maintain firmware to a Libre-Mesh based
environment. In order to integrate with the existing OLSR1 mesh, some
nodes should run BMX6/7 as well as OLSRd (using 2 devices is not an
option, we just don't have enough of them). While this generally works
nicely due to the routing-table-import features of BMX6, there is a
single very annoying problem:
Both routing daemons try changing sysctl settings in conflicting ways
without any means for the user to disable that 'egocentric' behaviour.
olsrd[21487]: Writing '0' (was 2) to /proc/sys/net/ipv4/conf/all/rp_filter
bmx7[1237]: INFO check_proc_sys_net(): changing /proc/sys/net/ipv4/conf/all/rp_filter from 0 to 2
I generally believe that a routing daemon shouldn't take-over the OS to
a degree which makes co-existence with other routing daemons or other
networking stuff impossible. Currently both, OLSRd and BMX repeatingly
try to enforce settings even in /proc/sys/net/ipv*/conf/all/ which thus
affects all interfaces and not only the ones governed by that specific
protocol.
I had a discussion with Henning about a similar issue I had with OLSRd
changing send_redirects without any way to configure it not to touch
sysctl values. Now the problem came back and kinda confirms my opinion
that setting sysctl options (/proc/sys/net/*) is a task to be carried
out by the OS, ie. netifd on OpenWrt/LEDE or connman or NetworkManager
or whatever-you-use.
Thus my demand to routing protocols developers: Please at least create
a way to tell your routing daemon "don't touch my sysctl, I'll take
care of it myself!". This should imho be the default for the
OpenWrt/LEDE build of the routing daemons and netifd should handle
stuff like rp_filter and send_redirects -- the routing daemon might
still warn you about UCI settings known to cause problems under certain
conditions.
Cheers
Daniel
On 25/05/16 09:55, Daniel Golle wrote:
> Hi!
>
> Thanks for building that great set of packages enabling (almost)
> stateless autoconfiguration mesh routers! I hope to use all that in my
> local freifunk environment; many people here are interested in LIME and
> I'll help getting it to interoperate with our local legacy OLSRv1 mesh
> and the way we use batman-adv... My main goal is to start collaboration
> (software development, bug fixing, ...) beyond the local firmware
> projects which are either half-abandonned or do not offer anything near
> to how lime's webui is enabling new people to get into the story and of
> course, none of them (meshkit, gluon, ...) are truely modular and/or
> offer good support for more than the single routing protocol they were
> originally written for. It should also be easy to have some
> meta-packages in LIME which would select the packages needed for
> typical freifunk OLSRv1 and/or batman-adv setups (expect pull-requests
> for that to hit your github repo soon).
>
> However, while preparing the switch to libremesh some questions and
> oddities arrised.
> I'm building from source, ie. enabled lime-packages and libremap feeds.
> I can't use the binaries as most of the hardware I use is unsupported
> or works really bad on BB.
>
> Questions which came up for now:
> * what's missing to run LibreMesh on more recent versions of OpenWrt?
> A lot of hardware was added since BB and certainly won't waste time
> backporting stuff to BB, but rather spend it on helping to get LIME
> run on bleeding-edge LEDE or at least OpenWrt's CC release (as people
> will still be backporting hardware support for CC for a while...)
try https://github.com/libre-mesh/lime-build/tree/develop (it's based on
CC), that will turn into a release soon
> * http://chef.libre-mesh.org is unavailble... what's supposed to be
> there and how to bring it back?
mmh, dns is unset for some reason
anyway it points to http://chef.altermundi.net
> * lime-eb-ip-tables: why not use fw3?
personal preferences :P
in my case, i do install and use fw3, but other devs prefer not to
bundle the firewall, so we give the option
(i.e. if you install fw3 everything will work as well and be integrated
as expected)
> * why redundantly create per-device images instead of just using
> OpenWrt/LEDE ImageBuilder? ie. the downloads here
> http://downloads.libre-mesh.org/firmware/
> are hard to understand for outsiders, also for long-term OpenWrt
> hackers like myself. E.g. for which hw-revision is supported by the
> image for the TL-WR841N(D)?
good point :)
currently, pau is the only one vouching for custom renaming,
i'm personally against, and Gio i think doesn't really care
> I had that build-a-wrapper vs. use-OpenWrt-SDK-and-ImageBuilder
> debate a bunch of times and I'm sure that most people building
> wrappers just don't know what they are missing and/or how much extra
> work they have to go through compared to just using OpenWrt/LEDE in
> the way it was meant to be used...
totally agree, but doing a project together involves trying to reach
consensus, and when that's impossible, concessions :)
> * How can I reproduce the way the images on downloads.libre-mesh.org
> have been built (ImageBuilder? List of packages/files added/removed)?
it's supposed to be a simple "git clone lime-build ; cd lime-build ;
make", but Pau can clarify
>
> I'll certainly have more questions soon :)
>
keep them coming! :D
>
> Cheers
>
>
> Daniel
>
Hi!
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
some help.
Cheers!
Hi!
Thanks for building that great set of packages enabling (almost)
stateless autoconfiguration mesh routers! I hope to use all that in my
local freifunk environment; many people here are interested in LIME and
I'll help getting it to interoperate with our local legacy OLSRv1 mesh
and the way we use batman-adv... My main goal is to start collaboration
(software development, bug fixing, ...) beyond the local firmware
projects which are either half-abandonned or do not offer anything near
to how lime's webui is enabling new people to get into the story and of
course, none of them (meshkit, gluon, ...) are truely modular and/or
offer good support for more than the single routing protocol they were
originally written for. It should also be easy to have some
meta-packages in LIME which would select the packages needed for
typical freifunk OLSRv1 and/or batman-adv setups (expect pull-requests
for that to hit your github repo soon).
However, while preparing the switch to libremesh some questions and
oddities arrised.
I'm building from source, ie. enabled lime-packages and libremap feeds.
I can't use the binaries as most of the hardware I use is unsupported
or works really bad on BB.
Questions which came up for now:
* what's missing to run LibreMesh on more recent versions of OpenWrt?
A lot of hardware was added since BB and certainly won't waste time
backporting stuff to BB, but rather spend it on helping to get LIME
run on bleeding-edge LEDE or at least OpenWrt's CC release (as people
will still be backporting hardware support for CC for a while...)
* http://chef.libre-mesh.org is unavailble... what's supposed to be
there and how to bring it back?
* lime-eb-ip-tables: why not use fw3?
* why redundantly create per-device images instead of just using
OpenWrt/LEDE ImageBuilder? ie. the downloads here
http://downloads.libre-mesh.org/firmware/
are hard to understand for outsiders, also for long-term OpenWrt
hackers like myself. E.g. for which hw-revision is supported by the
image for the TL-WR841N(D)?
I had that build-a-wrapper vs. use-OpenWrt-SDK-and-ImageBuilder
debate a bunch of times and I'm sure that most people building
wrappers just don't know what they are missing and/or how much extra
work they have to go through compared to just using OpenWrt/LEDE in
the way it was meant to be used...
* How can I reproduce the way the images on downloads.libre-mesh.org
have been built (ImageBuilder? List of packages/files added/removed)?
I'll certainly have more questions soon :)
Cheers
Daniel
