2016-07-11 20:49 GMT+02:00 p4u <pau(a)dabax.net>:
> From the README: Or to use your own LiMe packages git repository and/or
> OpenWRT/LEDE (must be executed the first time make is invoked or after
> make LIME_GIT="http://foo.git" <http://foo.git> T=ar71xx P=generic
> OWRT_GIT="http://foo.git" <http://foo.git>
I tried to compile LiMe on LEDE using lime-build develop, I simply issued:
make T=ar71xx P=generic OWRT_GIT="
but I noticed that there are lines in the feeds.conf file  included in
lime-build which are pointing to our static OpenWrt repos.
So, what is a good procedure to build LiMe on LEDE using lime-build?
Is it enough to remove those lines in the feeds.conf file and specify the
OWRT_GIT parameter pointing to LEDE source?
We are currently trying to use the Libre-Mesh.org firmware with
batman-adv enabled on wired Ethernet interfaces alongside with a VLAN
which is a member of the bridge the batX interface also resides in.
T +--------------+ BRIDGE
We do want such a setup to have the best of both worlds: the
performance of a plain bridge but yet benefit from batman-adv topology
information, alfred and all that. As many cheap Ethernet switches do
not support frames larger than 1500 bytes, increasing the MTU is not an
option and thus frames inside batman-adv end up fragmented which hurts
performance if encapsulating all traffic via batman-adv.
I remember there was a discussion during battlemesh about a race-
condition which can confuse BLA and thus batman-adv is still disabled
on wired Ethernet interfaces in Libre-Mesh by default.
So here I am asking you about the current state of affairs regarding
We are discussing it on
and it would be great to hear a more detailed summary because I only
remember the rough details and also haven't been watching if anything
was fixed or improved since we all met in Porto.
2016-07-13 15:39 GMT+02:00 p4u <pau(a)dabax.net>:
> 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
So, from my understanding there are architectures where trying to set both
ad-hoc and ap modes is not going to work, or it would be better to set
802.11s and ap instead (as Pau told for ramips), right?
In my opinion (ap + ad-hoc | just ap | ap + 802.11s) selection could be
made by lime-build depending of the selected target architecture.
lime-build could do this setting different lime-defaults depending on the
target (not implemented yet).
Otherwise I suspect that we should move some files  from lime-system to
new packages lime-mode-adhoc and lime-mode-ieee80211s (and stop using
lime-full), then specifying the wanted packages in the targets files .
 at least these
I've been testing current lime-packages develop branch with OpenWrt
15.05 Chaos Calmer. My testbed is a 20-30 mesh network with real users
in a non easy scenario. It seems to work fine so I created a new branch
in lime-packages and also in lime-build named testing/16.07.
I will do more testing next days but would be nice to have more
feedback. So if you want to compile it yourself clone: "lime-build" and:
git checkout 16.07
make T=ar71xx J=4 P=generic
Or use new profile "ar71xx-mini" made for small 4MB devices.
Do we have some special features we want to have in the next release or
the current develop works?
PS: I took the liberty to do so to try pushing a bit this release.
I had to cherry-pick some small commits from Develop to release 15.09 to
be able to use the lime-freifunk package in the stable release of LiMe.
I know it is not the way we agreed (once the release is done, only
bugfixes can be backported). But we really need this here in freifunk.
They are working with develop and the experience is too much random. We
need some stable firmware.
If the team does not agree, I'll do "git reset" to go back again.
Cheers, hope you understand.
I have been reviewing the branch olsr_integration started by Pau. I have
changed a few stuff for more consistence, in particular we already had the
convention that vlanid=0 mean no vlan and createVlanInterface already take
care of this (still testing it on a real device is TODO)
moreover the way it was implemented named args worked only in specific
interface configuration while now it works also in the general network section
I also removed the extraArgs param because args is already a table
(associative array) so it already support string index (we were already doing
something similar for interface flags)
All modifications should works but are not tested on a real device as i don't
have one under my hands right now, so i haven't merged it
Still it is not clear to me how bmx and olsr can run at same time without
causing strange behaviors in general cases, but it is not a problem for me ;)
While i perfectly see the usefulnes of supporting more routing protocols also
without using vlan
Thanks for the idea of moving also protocols to named arguments and to start
Micha, another freifunker who is testing libremesh at the moment is very
confused about having bmx7 packages when using bmx6 (in developer brunch).
bmx6 is used at the moment, because bmx7 was very unstable in daniels
first setup (also to much packages for 4mb routers)
while daniel was patching that adhoc, micha made some commits, and is
still on testing:
whats your opinion about that problem?
Freifunk Leipzig http://leipzig.freifunk.net
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.