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
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
Hi.
Today I was compiling libre-mesh 15.09 (which should be currently the
last stable release) using lime-build.
So I cloned lime-build and checkout branch "15.09". I found that the
branch 15.09 did not exist in any of our frozen repositories
(openwrt-routing, packages, libremap and oldpackages). So the
compilation process ends up without any error but also without any
packet such as bmx6 nor bat-adv.
I thought we the idea was that once we release a new version we create a
new branch to ALL the repositories including lime-build, so 15.09 must
exist. Am I wrong? I have created 15.09 from 15.04 to all the repositories.
If there is no objection I will write it down on our new web site to
make it clear forever.
Cheers.
--
./p4u
On a TL-WDR3600 I was looking at the differences between the
/etc/config/network file in the last stable release and the develop
branch (great work going on there in these days!!).
Here are some lines which I want to bring to your attention (they could
be ok, but look suspicious to me):
config interface 'wan6'
option proto 'dhcpv6'
which becomes:
config interface 'wan6'
option proto 'none'
config device 'lm_anygw_dev'
which becomes:
config device 'lm_net__lan_anygw_dev'
(yes, with two joined underscores)
config device 'lm_wlan0_adhoc_batadv_dev'
option name 'wlan0-adhoc_203'
which becomes:
config device 'lm_net_wlan0_adhoc_batadv_dev'
option name '-lm-net-wlan0-adhoc_118'
this strange name (starting with a dash) repeats along the file
Then some more random observations :D
batctl if
prints just
eth0-2_118: active
while I expected to see also the wireless interfaces here
# ps |grep bmx
3509 root 1168 S grep bmx
so no bmx daemon is running?
sniffing on the ethernet ports of the router I can see batman packets
coming out just on the WAN port and not on the LAN ports.
I compiled the image using the new recommended system: lime-build
then I noticed that some of the packets that was suggested to deselect
by the old traditional compilation guide are indeed selected here:
CONFIG_PACKAGE_odhcpd=y
CONFIG_PACKAGE_firewall=y
Keep up with the good work :D
Ilario
--
Ilario Gelmetti
iochesonome(a)gmail.com
igelmetti(a)iciq.es
ilario.gelmetti(a)estudiants.urv.cat
