lime-dev July 2016

lime-dev@lists.libremesh.org

8 participants
15 discussions

by Ilario

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 > clean). > > 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=" https://git.lede-project.org/source.git" but I noticed that there are lines in the feeds.conf file [1] 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? Thanks, Ilario [1] https://github.com/libre-mesh/lime-build/blob/develop/feeds.conf

7 years, 7 months

bridge and batman-adv over ethernet

by Daniel Golle

Hi! 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. ------------------------------ E |VLAN---batadv---bat0 T +--------------+ BRIDGE H |VLAN------------eth0.xx ------------------------------ 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 this issue. We are discussing it on https://github.com/libre-mesh/lime-packages/issues/56 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. Cheers Daniel

7 years, 8 months

Github notifications on dev mailing list

by Ilario

Hi devs! Recently there's a lot of interesting discussion [e.g. 50,56] going on on Github/libre-mesh bypassing completely this mailing list. I think we should mirror Github issues, comments on issues and similar stuff here. There's an easy solution [1] which doesn't require any software running on our side, but requires a mailing list administrator (Nico) to set up it. Shall we do this? Ciao! Ilario [50] https://github.com/libre-mesh/lime-packages/issues/50 [56] https://github.com/libre-mesh/lime-packages/issues/56 [1] https://github.com/w3c/webpayments/wiki/Synchronizing-Github-Issues-with-W3…

7 years, 9 months

Different modes for different targets in lime-build [was: downloads.libre-mesh.org activated again]

by Ilario

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 > mode). > 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 [1] 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 [2]. Byyye, Ilario [1] at least these https://github.com/libre-mesh/lime-packages/tree/develop/packages/lime-syst… [2] https://github.com/libre-mesh/lime-build/tree/develop/targets

7 years, 9 months

lime-mini and ar71xx-mini

by Ilario

In these last two days appeared two different things called "mini" in libre-mesh: * ar71xx-mini target in lime-build [1] for routers with < 4MB of flash memory (really useful!!) * lime-mini package in lime-packages [2] which equals to the classic lime-full without lime-debug I think that having two different meanings for the "mini" concept is confusing, Pau could you rename one of the two? Like "lime-mini" => "lime-basic" or "ar71xx-mini" => "ar71xx-4mb". Thanks, Ilario [1] https://github.com/libre-mesh/lime-build/commit/d8a0a8ecd913f18fb0af920aa83… [2] https://github.com/libre-mesh/lime-packages/commit/36ff885ec54e3bffd9980d11…

7 years, 9 months

Release 16.07

by p4u

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.

7 years, 9 months

commits on release 15.09? don't panic

by p4u

Hi. 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.

7 years, 9 months

mv olsr_integration feature/proto_named_args

by Gio

Hi! 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 coding it! Cheers!

7 years, 9 months

bmx6 vs. bmx7

by Ufo

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: https://git.netzspielplatz.de/ffj-LiMe/lime-packages/commits/develop whats your opinion about that problem? ufo -- --- Freifunk Leipzig http://leipzig.freifunk.net

7 years, 9 months

downloads.libre-mesh.org activated again

by p4u

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.

7 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

lime-dev July 2016