- lime-dev - listas.altermundi.net

by SAn

Hi all! Yesterday I realized that emails that I sent to the list in the last years never reached the list. There was an issue with the mailman config and all the emails that had a DMARC config that did not allow other servers to send emails were dropped without notice. Most email/domains config worked fine but in case you sent an email and never had an answer check that the mail was in the list archives. Now it is fixed, sorry everyone for the inconvenience. SAn

4 years, 3 months

1
0
0 0

LibreMesh 2020.1 and this mailing list

by Ilario Gelmetti

A new LibreMesh version has been released! Find the announcement here: https://libremesh.org/news.html#2020_12_15_libremesh_2020_1_release A question on this mailing list: it has never been used for taking decisions on the project and is silent since months, can we stop listing it on the website? One month with no answer will be taken as no opposition to the removal. If you're not already in, please subscribe to the lime-users mailing list and join the Element(ex-Riot)/IRC chat, links on: https://libremesh.org/communication.html Ciao! Ilario -- Ilario iochesonome(a)gmail.com ilario(a)sindominio.net

4 years, 3 months

3
3
0 0

Fwd: Babeld management under OpenWRT

by Ilario Gelmetti

-------- Forwarded Message -------- Subject: [Babel-users] Babeld management under OpenWRT Date: Wed, 23 Dec 2020 13:29:09 +0100 From: Juliusz Chroboczek <jch(a)irif.fr> To: babel(a)ietf.org CC: babel-users(a)lists.alioth.debian.org Dear all, There's a management interface for babeld integrated with OpenWRt that's being developed. People interested in management might want to chime in. The discussion is happening here: https://github.com/openwrt-routing/packages/pull/630 -- Juliusz _______________________________________________ Babel-users mailing list Babel-users(a)alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users

4 years, 4 months

1
0
0 0

MediaTek routers, ethernet and VLAN 802.11ad

by Ilario Gelmetti

Dear all, I was testing LibreMesh (together with Gio and SAn, lime-packages master branch compiled on top of OpenWrt's openwrt-18.06 branch) on a MediaTek-based router: YouHua WR1200JS. Everything works fine apart the routing on cabled connections. Seems that these routers does not like VLAN of type 802.1ad on cable. It could be an OpenWrt bug or a bug on the device. Can anyone check and confirm on other MediaTek devices please? Here I make a list of what I tested: * setting the routing protocols to run on 802.1q interfaces (rather than on 802.1ad, we usually don't do it as it gave problems with TP-Link routers, can be done giving a third argument in /etc/config/lime, like "list protocols babeld:17:8021q") and the routing protocols see each other via cable, works well (two identically configured routers see each other as neighbours via eth0-1_17 in Babeld, prompted with "echo dump | nc ::1 30003") * listening with Wireshark on the laptop, I receive from the cable broken IPv6 multicast packets. They are correctly marked as VLAN 802.1ad ID 17 but the rest of the packet content is Error/Malformed. * creating an 802.1ad interface on my laptop (e.g. "ip link add link enp0s25 name enp0s25.17 type vlan proto 802.1ad id 17; ip link set enp0s25.17 up"), adding an /24 IP on both sides and pinging from the router to the laptop. My laptop receives the router's ARP requests and answers, but the router keeps asking as if it did not receive the answer. * while pinging from the laptop (10.2.1.2) to the router (10.2.1.1) on the just created tagged cabled interface, I connect via wifi and ssh to the router and run tcpdump on it: ** running it on eth0 shows that my ARP requests physically reach the router and are properly tagged ("tcpdump -i eth0 -nn -e vlan"): 21:03:45.354344 54:ee:75:7a:c2:1f > ff:ff:ff:ff:ff:ff, ethertype 802.1Q-QinQ (0x88a8), length 64: vlan 1, p 0, ethertype 802.1Q-QinQ, vlan 17, p 0, ethertype ARP, Request who-has 10.2.1.1 tell 10.2.1.2, length 42 ** running it on eth0-1_17 shows broken UDP packets (the same Malformed IPv6 multicast packets I received with Wireshark) which likely are generated by Babeld, BUT NO ARP request at all: 21:05:45.395359 IP6 (class 0xc0, flowlabel 0x854bc, hlim 1, next-header UDP (17) payload length: 89) fe80::d65f:25ff:feeb:7ead.6696 > ff02::1:6.6696: [bad udp cksum 0x77ed -> 0x7ce5!] UDP, length 81 21:05:49.255355 IP6 (class 0xc0, flowlabel 0x854bc, hlim 1, next-header UDP (17) payload length: 20) fe80::d65f:25ff:feeb:7ead.6696 > ff02::1:6.6696: [bad udp cksum 0x77a8 -> 0xa0e9!] UDP, length 12 21:05:53.225372 IP6 (class 0xc0, flowlabel 0x854bc, hlim 1, next-header UDP (17) payload length: 20) fe80::d65f:25ff:feeb:7ead.6696 > ff02::1:6.6696: [bad udp cksum 0x77a8 -> 0xa0e8!] UDP, length 12 21:05:57.385373 IP6 (class 0xc0, flowlabel 0x854bc, hlim 1, next-header UDP (17) payload length: 20) fe80::d65f:25ff:feeb:7ead.6696 > ff02::1:6.6696: [bad udp cksum 0x77a8 -> 0xa0e7!] UDP, length 12 21:06:01.245355 IP6 (class 0xc0, flowlabel 0x854bc, hlim 1, next-header UDP (17) payload length: 89) fe80::d65f:25ff:feeb:7ead.6696 > ff02::1:6.6696: [bad udp cksum 0x77ed -> 0x7ce1!] UDP, length 81 * flashed the YouHua router with OpenWrt 18.06.4 as downloaded from the OpenWrt website and created the 802.1ad interfaces using the ip command (installing the ip-full package, "ip link add link eth0.1 name eth0-1_17 type vlan proto 802.1ad id 17; ip link set eth0-1_17 up; ip address add 10.2.1.1/24 dev eth0-1_17") and still it does not ping (my laptop's ARP requests and my laptop's ARP answers does not get to eth0-1_17) * on the same clean router, using nping I sent a raw ethernet packet on the eth0-1_17 interface (using the command "nping --send-eth --source-mac ff:ff:ff:ff:ff:ff --dest-mac ff:ff:ff:ff:ff:ff --data aaaabbbbccccddddeeeeffffffffeeeeddddccccbbbbaaaa -e eth0-1_17 -N 8.8.8.8") and captured it on the laptop. What I got is broken (notice that instead of "aa aa bb bb cc cc" on the second line, I have "aa aa 0e 9c cc cc"). This is when capturing on enp0s25 (plain ethernet) 0000 ff ff ff ff ff ff ff ff ff ff ff ff 88 a8 00 11 0010 08 00 08 00 4c 14 ab ea 00 01 aa aa 0e 9c cc cc 0020 dd dd ee ee ff ff ff ff ee ee dd dd cc cc bb bb 0030 aa aa d6 5f 25 ff fe eb 7e ac ae 2c 00 16 b7 e6 0040 4a c6 4f ee f2 fa And this is when capturing on enp0s25.17 (VLAN 802.1ad ID 17 interface) 0000 ff ff ff ff ff ff ff ff ff ff ff ff 08 00 08 00 0010 2c 48 cb b2 00 05 aa aa 9a 9a cc cc dd dd ee ee 0020 ff ff ff ff ee ee dd dd cc cc bb bb aa aa 64 68 0030 63 70 20 31 2e 32 38 2e 34 0c 07 4f 70 65 6e 57 0040 72 74 the latest part of the packet, both when listening on enp0s25 or on enp0s25.17, varies: usually does not have a transcription while sometimes it can be transcribed as: 0030 aa aa 64 68 63 70 20 31 2e 32 38 2e 34 0c 07 4f ..dhcp 1.28.4..O 0040 70 65 6e 57 72 74 penWrt where 1.28.4 looks like the busybox version on the router, no idea why or how this got here. Capturing the packet with tcpdump from inside the router, listening on eth0-1_17 I got: 0000 ff ff ff ff ff ff ff ff ff ff ff ff 08 00 45 00 0010 00 34 f5 88 00 00 40 01 6a 2e 0a 02 01 01 08 08 0020 08 08 08 00 2f 89 c8 71 00 05 aa aa bb bb cc cc 0030 dd dd ee ee ff ff ff ff ee ee dd dd cc cc bb bb 0040 aa aa then, listening on eth0.1 I got: 0000 ff ff ff ff ff ff ff ff ff ff ff ff 88 a8 00 11 0010 08 00 45 00 00 34 21 a6 00 00 40 01 3e 11 0a 02 0020 01 01 08 08 08 08 08 00 26 19 d1 e1 00 05 aa aa 0030 bb bb cc cc dd dd ee ee ff ff ff ff ee ee dd dd 0040 cc cc bb bb aa aa and listening on eth0: 0000 ff ff ff ff ff ff ff ff ff ff ff ff 81 00 00 01 0010 88 a8 00 11 08 00 45 00 00 34 4c e4 00 00 40 01 0020 12 d3 0a 02 01 01 08 08 08 08 08 00 c8 4f 2f ab 0030 00 05 aa aa bb bb cc cc dd dd ee ee ff ff ff ff 0040 ee ee dd dd cc cc bb bb aa aa so that all these three captures taken from inside the router look good. As a comparison, I used the same nping command on a TP-Link WDR3600 router and the packet captured on my laptop looks perfectly ok, sniffing on enp0s25: 0000 ff ff ff ff ff ff ff ff ff ff ff ff 88 a8 00 11 0010 08 00 45 00 00 34 88 39 00 00 40 01 6f 59 0a 0d 0020 69 1a 08 08 08 08 08 00 da bd 1d 3d 00 05 aa aa 0030 bb bb cc cc dd dd ee ee ff ff ff ff ee ee dd dd 0040 cc cc bb bb aa aa And capturing on enp0s25.17: 0000 ff ff ff ff ff ff ff ff ff ff ff ff 08 00 45 00 0010 00 34 33 0e 00 00 40 01 c4 84 0a 0d 69 1a 08 08 0020 08 08 08 00 60 93 97 67 00 05 aa aa bb bb cc cc 0030 dd dd ee ee ff ff ff ff ee ee dd dd cc cc bb bb 0040 aa aa In case this bug a hardware one for all the MediaTek-based routers, I would suggest considering running Babeld on the br-lan bridge without any VLAN (neither 802.1q nor 802.1ad) rather than on eth0-1_17. BMX6 was already running on the bridge and to avoid it to run also inside BATMAN-adv we were using this ebtables rule: https://github.com/libremesh/lime-packages/blob/master/packages/lime-proto-… we could do the same for Babeld (and for consistency I would also not use VLAN for it on wireless mesh interfaces). Thanks && ciao; Ilario

4 years, 6 months

2
3
0 0

Workflow for developing LibreMesh packages

by Eric Anderson

What is the intended workflow when developing LibreMesh packages (like lime-app, shared-state, etc.)? What I mean is the process of making some change to a LiMe package, compiling it and trying it out on a device running OpenWrt. Just following the compilation instructions <https://libremesh.org/development.html#compiling_libremesh_from_source_code> to produce an entire OpenWrt image every time seems to imply these steps: Make changes to the package source code, and commit those to the repository. Change the suitable Makefile in the LibreMesh source code to point to the commit above. Commit this as well. In the OpenWrt repository, add a LibreMesh feed that points to the LibreMesh repository above, instead of the official one. Compile OpenWrt. While this works, it’s not really practical when you just want to try things out. You also clutter the repository by having to commit things just to test run them. I’m sure you all follow a more convenient procedure, and I’d like to learn about it. Cheers! Eric

5 years

2
1
0 0

Re: [lime-dev] Cannot find LiMe → lime-proto-anygw building from source

by David Medland-Slater

Very much appreciated! I'll give that a go.... On 21/07/19 8:31 pm, SAn wrote: > Hi David! > > I think the problem is that the documentation is not in sync with the last developments we have been doing moving away from alfred to maintain shared state and using a new development called shared-state do do it. So now lime-proto-anygw depends on shared-state-dnsmasq_leases instead of dnsmasq-lease-share. Sorry about this! We will fix the docs. > > Here you can find the config that we are using for the LibreRouter firmware: https://github.com/LibreRouterOrg/openwrt/blob/librerouter-18.06/configs/de… . We have been keeping this config in sync with libremesh-development. > > Best! > SAn > > On 7/21/19 2:28 AM, David Medland-Slater wrote: >> Well at least I'm not going mad then! Could I perhaps ask for some >> general advice Mark on building a more up to date libremesh. I'm >> running the released version but on another project I've found plain >> vanilla openwrt 18 is considerably better than 17. Is there a sensible >> path to get a libremesh 18? This is for a home lab, nothing fancy >> running only 3 nodes, so it doesn't need to be production quality. I >> had hoped the development.html web page would be enough to give me >> working build options, but as you have seen, I'm not making much progress. >> >> With v17, I make use of the distributed DHCP, although I could live >> without that if it was problematic. >> >> Thanks in advance ... >> >> On 21/07/19 8:49 am, Mark Birss wrote: >>> yes, lime-proto-anygw disappear when selecting dnsmasq-lease-share. >>> >>> but seems i dont use it for my builds. I use BATMAN-adv gw mode >>> >>> >>> On Sat, Jul 20, 2019 at 10:25 PM David Medland-Slater >>> <david.medlandslater(a)gmail.com <mailto:david.medlandslater@gmail.com>> >>> wrote: >>> >>> Yes that gives me the same result Mark. For me then, at the point of >>> running menuconfig, lime-proto-anygw is visible. Enable >>> dnsmasq-lease-share and it disappears. As from the docs both need >>> to be >>> selected, I appear to be stuck. >>> >>> Do you get the same effect; selecting dnsmasq-lease-share makes >>> lime-proto-anygw disappear and if you search, it has been deselected? >>> >>> >>> On 21/07/19 6:58 am, Mark Birss wrote: >>> > echo "CONFIG_PACKAGE_dnsmasq=n" >> .config >>> > echo "CONFIG_PACKAGE_dnsmasq-dhcpv6=y" >> .config >>> > echo "CONFIG_PACKAGE_odhcpd=n" >> .config >>> > make defconfig >>> _______________________________________________ >>> lime-dev mailing list >>> lime-dev(a)lists.libremesh.org <mailto:lime-dev@lists.libremesh.org> >>> https://lists.libremesh.org/mailman/listinfo/lime-dev >>> >>> >>> _______________________________________________ >>> lime-dev mailing list >>> lime-dev(a)lists.libremesh.org >>> https://lists.libremesh.org/mailman/listinfo/lime-dev >> _______________________________________________ >> lime-dev mailing list >> lime-dev(a)lists.libremesh.org >> https://lists.libremesh.org/mailman/listinfo/lime-dev >>

5 years, 9 months

2
4
0 0

Cannot find LiMe → lime-proto-anygw building from source

by David Medland-Slater

Hi - I'm following : https://www.libremesh.org/development.html and it mentions selecting the LibreMesh pages which I've done, but I cannot seem to find * LiMe → lime-proto-anygw anywhere in the make menuconfig. I can find all the others mentioned in this documentation, but not this one. Any advice appreciated....

5 years, 10 months

3
19
0 0

Expired certificate and lists check

by amuza

Hi. Yesterday I sent an email to lime-users(a)lists.libremesh.org saying the certificate for libremesh.org got expired. I still have not received that email from the list. Is it possible that there is also a problem with the users' mailing list? Let's see if now I receive this one... Cheers

5 years, 10 months

1
0
0 0

Building and cooking LiMe image for x86 architecture — development branch

by Alejandro Bravo Fernández

Hello everyone, My name is Alejandro and I’m “cooking” LiMe firmware with the lime-sdk tool. My intention is to use the development branch with lime_bmx7 flavor. The hardware (for testing) is Alix2d2 from PcEngines and x86 architecture. I’m doing these steps in my Ubuntu 18.04: - sudo apt-get install subversion zlib1g-dev gawk flex unzip bzip2 gettext build-essential libncurses5-dev libncursesw5-dev libssl-dev binutils cpp psmisc docbook-to-man wget git - git clone https://github.com/libremesh/lime-sdk.git - cd lime-sdk - git checkout develop - ./cooker -d x86/geode - ./cooker -f -./ cooker -b x86/geode -./cooker -c x86/geode — profile=Generic —flavors=lime_bmx7 When these steps have been completed, I get this error but I don't know how to resolve it: [image1.jpeg] I’m hope you can help me and thank you so much for the work of Libremesh (it’s amazing). BR, Alejandro Bravo Fernández.

5 years, 10 months

3
7
0 0

Re: [lime-dev] RFC: new LiMe release

by p4u

I would say there are more than two significant regressions, such as current chef will be broken and libremesh will be less standard and less close to openwrt. In the other side, the only pro is that librerouter will be integrated into the official libremesh building tool. Would it not make more sense to integrate librerouter into Openwrt instead of doing the opposite? Once librerouter will be an official target, everyone will be happy. Just put some efforts here... (is there a point I'm missing so librerouter should not became an official target?) El 20 d’abril de 2019 17:00:42 GMT+04:00, Gui Iribarren <gui(a)altermundi.net> ha escrit: >regarding releasing libremesh as a set of packages , i absolutely >agree, so much that i did come up with exactly this idea a few weeks >ago and even started to draft something here >https://github.com/altergui/packages/commits/merge-libremesh-in-openwrt >that just compiles lime-system, but idea was to extend it to compile >all the lime-* packages and make a PR, ideally before openwrt-19.03 is >branched >i hardly sat down with a laptop since then :( >would love to coordinate efforts somehow > >regarding buildroot vs lime-sdk, the only way to work on hardware >support for librerouter was to work on buildroot, so there was no >decision to take at that point. >the decision was to work with buildroot AND THEN 3 more other complex >and diverse tools (lime-sdk which in turn uses sdk and imagebuilder) or >just focus on one single tool (buildroot). given limited humanpower, >the sensible decision was to use a single tool > >there are two significant regressions, tho: >1) there's currently no organized repo of firmware customizations >(think of altermesh profiles, or more recently github repo >"network-profiles") > >2) firmwares generated with buildroot cannot use kmod-* packages >published by upstream > >(just for context: >before 17.06 we "solved" this issue by compiling all kmod-* for ar71xx, >publishing them under downloads.libremesh.org (or the like), and >pointing opkg.conf to that repo. >in 17.06 we used openwrt SDK to compile lime-* and then we could use >official upstream kmod-*) >in my understanding this will cease to be a problem as soon as lime-* >packages are simply part of upstream (when PR ir prepared and >accepted), since the instructions to "cook" a libremesh firmware could >be to simply download official openwrt 19.03 ImageBuilder and generate >a binary with lime-blah packages, which will come bundled in >imagebuilder along all other packages > >On 16 April 2019 15:21:14 GMT-03:00, Pau <pau(a)dabax.net> wrote: >>In-line. >> >>On 16/4/19 0:40, Marcos Gutierrez wrote: >>> Hi, previously to this thread I wrote something similar in >>Mattermost. I >>> think that the fact that it is duplicating the conversation further >>> reinforces what I raise. >>> I copy and paste what I wrote before. >>> >>https://mattermost.altermundi.net/chaosmonekeys/pl/dqn46n9qmb8ijf1hj3wix4ox… >>> -------------------------------------------------. >> >>I think the mailing list is the official channel we have been using >for >>a long time. So IMO this is the correct place for this discussions. >> >>> *Hello, team*. I think it's necessary to start some conversations. >In >>> the last year I think we lost our way as team and pursued individual >>or >>> particular agendas. In my case, I don't know what those agendas are. >>But >>> this resulted in a decrease in the quality of the code, in >completely >>> unattended communities and in the non-compliance with the releases. >>> >>> >>> LibreRouter and LibreMesh >>> >>> In my experience LibreRouter maintained some pressure on development >>or >>> at least pushed it in some direction. I have noticed that some of >the >>> user community misunderstands this by believing that what was >>developed >>> for LibreRouter does not contribute to LibreMesh, when in fact they >>go >>> along side by side. One of the changes, in terms of what was being >>> proposed from LibreMesh, is related to the development environment, >>to >>> change for a more stable and functional one, replacing lime-sdk with >>> buildroot. My experience in both systems is that buildroot is more >>> predictable and transparent with errors, if any. I didn't notice any >>> extra complexity. It is currently under discussion how to apply some >>> kind of "recipe" that allows a follow up on the build >configurations, >>> that did solve well lime-sdk. >>> >> >>That would be a **horrible decision** IMO. Our past tool (name >>lime-build) used buildroot and we agree, after a looooong discusion, >to >>change to lime-sdk and use ImageBuilder+SDK. Please, find the >documents >>in the mailing list archive which are talking about this topic before >>taking any kind of decision or opening this discussion again. >> >>> Protocols >>> >>> Bmx6 stopped its development and is still the default layer 3 >>protocol >>> in LibreMesh. The discussion about changing it (by bmx7, babel or >>other) >>> never arose. I think this is part of what blocks a new release, >since >>> there is neither a consensus nor accumulated experiences of use by >>the >>> developed, at least not between all. >>> >> >>I really think jumping to bmx7 would be a good decision. I've been >>using >>bmx7 for a long time now and it works just fine. >> >>> Release vs Develop >>> >>> When I participated in the summit of community networks in Brazil I >>was >>> surprised to see that they were installing 17.06 on the routers. >>Since >>> that release was published we had almost 450 commits, many of them >>minor >>> but others very important. Several of those issues were detected by >>the >>> use of LibreMesh in our communities, the result of many headaches. >If >>we >>> don't publish an update we are helping to continue spreading already >>> solved bugs instead of being able to detect new ones. Another >problem >>I >>> noticed is the need to have OpenWrt 18.06.1. I didn't notice this >>> problem because I never used the release, I always used develop or >>some >>> branch of my own, away from the experience of our users. Did the >same >>> thing happen to you? >>> >>> >>> Public roadmap >>> >>> My proposal is that as soon as possible we advance in knowing the >>> private and public roadmaps, collective and individual of those who >>> develop LibreMesh. Then try to reach a consensus on what, when, who >>and >>> how we are going to continue working and make that public. >>> >>> *We build a software that works (however it is but works), that has >>> users and community but that lacks a clear direction.* >>> >>> /If something is not understood it can be a translation problem, let >>me >>> know and I will correct it. / >>> >>> On 15/4/19 14:56, p4u wrote: >>>> I think thay could work and having a new release is quite a need. >>>> >>>> What we need, IMO, is someone moivated managing the technical part >>>> (that could be you), and some real scenario/realcase to test the >>>> release and brint feedback. >>>> >>>> El 15 d’abril de 2019 15:54:02 CEST, Paul Spooren ><mail(a)aparcar.org> >>>> ha escrit: >>>> >>>> Hi all, >>>> >>>> it's been a very long time since we had a LiMe release, and >>currently >>>> the state of master isn't the best, right? >>>> >>>> What do you think of the following: >>>> >>>> We determine a LibreMesh setup fitting most purposes, say >Anygw, >>Batadv, >>>> BMX7, lime-app. Now we make sure this setup works, sure we have >>more >>>> modules and packages, but we focus for a time on these few >>packages and >>>> make them work. >>>> >>>> Now, we kindly ask to get these packages in the official >>repository of >>>> OpenWrt, just like Freifunk did in the past. Now it's suddenly >>super >>>> easy to build LibreMesh, as it's fully compatible to the >>official SDK. >>>> >>>> Once the setup works we can make a new release, saying that the >>>> combination of packages above (or a similar one) is officially >>>> supported, the rest is considered "unstable" as long as not in >>the >>>> official repo. >>>> >>>> Would be happy to work on this for the next weeks until we have >>>> something stable. What do you think? >>>> >>>> Sunshine, >>>> Paul >>>> >>------------------------------------------------------------------------ >>>> lime-dev mailing list >>>> lime-dev(a)lists.libremesh.org >>>> https://lists.libremesh.org/mailman/listinfo/lime-dev >>>> >>>> >>>> -- >>>> Enviat des del meu dispositiu Android amb el K-9 Mail. Disculpeu la >>>> brevetat. >>>> >>>> _______________________________________________ >>>> lime-dev mailing list >>>> lime-dev(a)lists.libremesh.org >>>> https://lists.libremesh.org/mailman/listinfo/lime-dev >>> >>> _______________________________________________ >>> lime-dev mailing list >>> lime-dev(a)lists.libremesh.org >>> https://lists.libremesh.org/mailman/listinfo/lime-dev >>> -- Enviat des del meu dispositiu Android amb el K-9 Mail. Disculpeu la brevetat.

6 years

1
0
0 0

RFC: new LiMe release?

by Paul Spooren

Hi all, it's been a very long time since we had a LiMe release, and currently the state of master isn't the best, right? What do you think of the following: We determine a LibreMesh setup fitting most purposes, say Anygw, Batadv, BMX7, lime-app. Now we make sure this setup works, sure we have more modules and packages, but we focus for a time on these few packages and make them work. Now, we kindly ask to get these packages in the official repository of OpenWrt, just like Freifunk did in the past. Now it's suddenly super easy to build LibreMesh, as it's fully compatible to the official SDK. Once the setup works we can make a new release, saying that the combination of packages above (or a similar one) is officially supported, the rest is considered "unstable" as long as not in the official repo. Would be happy to work on this for the next weeks until we have something stable. What do you think? Sunshine, Paul

6 years, 1 month

5
4
0 0

Re: [lime-dev] Extracting full mesh topology of BMX6

by Mark Birss

Should I then be able to build meshrc firmware using the Beta Chef web builder and selecting the meshrc-node profile only ? https://as-test.stephen304.com/chef/ Regards On Sat, 10 Nov 2018, 16:08 Paul Spooren <mail(a)aparcar.org wrote: > You could have a look at meshrc found here: > https://github.com/aparcar/meshrc > > It's an interface that does long term monitoring of a mesh network based > on bmx7 using some lightweight lua scripts. > > On Nov 9, 2018 22:03, David Johnson <david.lloyd.johnson(a)gmail.com> wrote: > > > > I'm using Libremesh version openwrt-18.06 > > > > I want to extract the topology of the mesh in a json format for some > > visualization software we are building. What do you suggest is the > > best way of doing this > > > > BMX6 version is: > > BMX6-0.1-alpha comPatibility=16 > > revision=0312168aaa384379ccbefd4b2d936fc698664d5b > > > > So far I've tried > > - opkg install bmx6-topology to try and use the topology plugin ... > > but this doesn't exist on this libremesh release > > - Using the b6m-jsonp script > > https://gitlab.com/sim6/sim6s-b6m/blob/master/www/cgi-bin/b6m-jsonp > > > > But logread shows: > > user.notice b6m-jsonp: ERROR: globalId not found, abort > > > > So this version of BMX6 is not exporting that $globalId > > > > Any suggestions > > > > Thanks > > David > > > > -- > > Dr David Johnson > > Director, Ammbr Research Labs South Africa > > Part of the AmmbrTech Group > > http://www.ammbrtech.com > > > > Adjunct Senior Lecturer > > ICT4D, Computer Science Department > > University of Cape Town > > https://people.cs.uct.ac.za/~djohnson/ > > _______________________________________________ > > lime-dev mailing list > > lime-dev(a)lists.libremesh.org > > https://lists.libremesh.org/mailman/listinfo/lime-dev > _______________________________________________ > lime-dev mailing list > lime-dev(a)lists.libremesh.org > https://lists.libremesh.org/mailman/listinfo/lime-dev

6 years, 6 months

1
0
0 0

Re: [lime-dev] Extracting full mesh topology of BMX6

by Paul Spooren

You could have a look at meshrc found here: https://github.com/aparcar/meshrc It's an interface that does long term monitoring of a mesh network based on bmx7 using some lightweight lua scripts. On Nov 9, 2018 22:03, David Johnson <david.lloyd.johnson(a)gmail.com> wrote: > > I'm using Libremesh version openwrt-18.06 > > I want to extract the topology of the mesh in a json format for some > visualization software we are building. What do you suggest is the > best way of doing this > > BMX6 version is: > BMX6-0.1-alpha comPatibility=16 > revision=0312168aaa384379ccbefd4b2d936fc698664d5b > > So far I've tried > - opkg install bmx6-topology to try and use the topology plugin ... > but this doesn't exist on this libremesh release > - Using the b6m-jsonp script > https://gitlab.com/sim6/sim6s-b6m/blob/master/www/cgi-bin/b6m-jsonp > > But logread shows: > user.notice b6m-jsonp: ERROR: globalId not found, abort > > So this version of BMX6 is not exporting that $globalId > > Any suggestions > > Thanks > David > > -- > Dr David Johnson > Director, Ammbr Research Labs South Africa > Part of the AmmbrTech Group > http://www.ammbrtech.com > > Adjunct Senior Lecturer > ICT4D, Computer Science Department > University of Cape Town > https://people.cs.uct.ac.za/~djohnson/ > _______________________________________________ > lime-dev mailing list > lime-dev(a)lists.libremesh.org > https://lists.libremesh.org/mailman/listinfo/lime-dev

6 years, 6 months

1
0
0 0

Extracting full mesh topology of BMX6

by David Johnson

I'm using Libremesh version openwrt-18.06 I want to extract the topology of the mesh in a json format for some visualization software we are building. What do you suggest is the best way of doing this BMX6 version is: BMX6-0.1-alpha comPatibility=16 revision=0312168aaa384379ccbefd4b2d936fc698664d5b So far I've tried - opkg install bmx6-topology to try and use the topology plugin ... but this doesn't exist on this libremesh release - Using the b6m-jsonp script https://gitlab.com/sim6/sim6s-b6m/blob/master/www/cgi-bin/b6m-jsonp But logread shows: user.notice b6m-jsonp: ERROR: globalId not found, abort So this version of BMX6 is not exporting that $globalId Any suggestions Thanks David -- Dr David Johnson Director, Ammbr Research Labs South Africa Part of the AmmbrTech Group http://www.ammbrtech.com Adjunct Senior Lecturer ICT4D, Computer Science Department University of Cape Town https://people.cs.uct.ac.za/~djohnson/

6 years, 6 months

3
2
0 0

fd66:66:66:7:c693 IPv6 unaccessble but 2a00:1508:ac6:d000:: works ok

by Piotr Barszczewski

Hello, I’ve initially asked my question at https://github.com/libremesh/lime-sdk/issues/93 but have been redirected to this mailing list and I hopie this is the right place to ask. I'm trying to figure one thing out and can't wrap my head around it - maybe someone could help me with it. I create a small mesh network (2-7 devices) and it works fine initially. I connect with my PC to it and can ssh/ping and open LuCi over IPv4 and IPv6 addresses in IPv6 fd66:66:66:7:c693:ff: subnet (which is shown in LuCi under http://thisnode.info/cgi-bin/luci/status/bmx6/Nodes ) and 2a00:1508:ac6:d000:: (which is my option main_ipv6_address '2a00:1508:0a%N1:%N200::/64' in /etc/config/lime). After around an hour of working the fd66:66:66:7:c693:ff: address become's unavailable and only 2a00:1508:ac6:d000:: works. This only fixes after I reconnect to the Mesh Wifi network from my PC. I'm totally ok with using main_ipv6_address but LuCi bmx6/nodes shows only addresses from fd66:66:66:7:c693:ff: subnet which makes it very hard for end user to know what is the actual address of specific device (not to mention obtaining it's IPv4 address). Is there a way around this, eg. forcing Luci to show only the 2a00:1508:ac6:d000:: address or how to make fd66:66:66:7:c693:ff: not disappear after a while? For me this would be ideal scenario because figuring the IP address of each node is difficult - I understand how it’s calculated from MAC address but still looking for a single place which would list all the nodes addresses from 2a00:1508:ac6:d000:: subnet. I’m building the image from Lime-SDK commit https://github.com/libremesh/lime-sdk/commit/c3385846bf74d9b7530bc333f59fef… (because of https://github.com/libremesh/lime-sdk/issues/85) and with these packages: src-git base https://github.com/lede-project/source.git^01a8f0e444c9b52f100eff878cc7011f… src-git packages https://git.openwrt.org/feed/packages.git^1df38a4495a5eae7e39d10b93b3c7264a… src-git luci https://git.lede-project.org/project/luci.git;lede-17.01 src-git routing https://git.lede-project.org/feed/routing.git;lede-17.01 src-git telephony https://git.lede-project.org/feed/telephony.git;lede-17.01 src-git libremesh https://github.com/libremesh/lime-packages.git;17.06 src-git libremap https://github.com/libremap/libremap-agent-openwrt.git;master src-git limeui https://github.com/libremesh/lime-packages-ui.git;master + my own repo for app with a REST API Target is ar71xx/generic and profile is carambola2. I can repeat exactly the same for https://downloads.libremesh.org/dayboot_rely/17.06/targets/ar71xx/generic/c… when flashed with lede-17.01.2-lime-default-ar71xx-generic-carambola2-squashfs-sysupgrade.bin - just ping the 2a00:1508:ac6:d000:: and fd66:66:66:7:c693:ff: and after 30-60minutes the fd66:66:66:7:c693:ff: will become unavailable but 2a00:1508:ac6:d000:: will work just fine. Best regards, Piotr Barszczewski

6 years, 6 months

1
0
0 0

FirstBootWizard Description for Hackathon in Quintana

by Nicolas Pace

Hi! As there is going to be a hackathon in Quintana in the upcoming weeks, I was invited to share the progress of the FirstBootWizard (FBW) project. https://github.com/libremesh/FirstBootWizard/ The question it tries to reply is: * How is a new network setted up? What is the first boot experience when a LibreMesh node is turned on? * How do a LibreMesh node joins an existing network? The approach is for nodes (routers) to share their network config with their peer nodes, so they can decide on whether they want to join their network. There are a lot of complexities about this: * hardware differences: original node had a set of radios, antennas and wired interfaces, and mine has a different one, * physical conditions: which radio and which antenna of that radio fetched the config from my peer node?, and what if the radios were configured specifically based on the context of that node? (location, neighbours, etc). * logical roles: one node can be an batman's alfred's coordinator, a gateway with manual configurations, or even have static ip addresses or centralized services running on them... * customization: how do we split config between node config and network config in a way that allows for customization and yet maintainability These are the boundaries that we defined for the first iterations: * We will design for the LibreRouter context first: as it is close to getting released, and this is part of the first experience, needs to be available asap, so we will narrow the focus to implement first the features required for it, then generalize (in this case, triple radios for example). * We will priorize the cases of: 1. One new node in an existing network: because that is the most common case, 2. First node of a network: because this is the inception moment, that will also happen a lot. Some other cases that were not taken into consideration but are part of the process: 3. different frequencies for different radios: the LR has two 5ghz, and it is desired that both have different radios so there is no self-inflicted noise. So, the configs will reflect that and need to consider this situation. 4. Border node of a network: it may happen that a node is put in to communicate to networks with each other 5. TVWS case: The 2.4ghz radio being used with the TVWS Frequency shifter (basically, a device that turns a 2.4ghz radio into a 600Mhz one, capable of non-line-of-sight links). No special considerations yet in my mind, but still to be considered. 6. Extra packages needed: the lime config doesn't include the potential extra packages that might have been installed on a firmware, 7. Attended upgrades server: this is key, as if there is one in your network, you might do that before anything else (as it will have the extra packages installed for example). What has been done already (you can find it in the github repo: https://github.com/libremesh/FirstBootWizard/ ): * serve-lime-config shares the lime-default with the network over http, so anyone can fetch it. It is a symlink for the lime-defaults file to a publicly accesible folder shared by uhttpd. * first-boot-wizard-daemon: a daemon that while in setup state (defined by the presence of the /var/lock/first_run file) keeps searching for nodes and fetching their config. The basic behaviour is: * no network config found around, keeps searching * one network config found around, applies its config and reboots removing first_run file * many networks config found around, don't do anything, and keeps them so the user can choose It also includes a ubus service to ask for the network config files found around, so the user can choose which to join, or trigger it in a latter moment if we want to reset the config to 'network defaults', and also the ability to create a new network. These are the foundations to add support in the lime-app. Caveats: * are there anything within the lime-default file that we don't want to be sharing openly within the adhoc/11s network? * what is the UX we will provide is a password is needed? Hope this is enough info to work on it! Will be around if any questions appear, through here, Riot, Telegram, etc. good luck!

6 years, 7 months

3
6
0 0

Expired certificate at https://libremesh.org

by amuza

Hi devs, Nothing else, just the title. Cheers!

6 years, 8 months

2
3
0 0

Adding a custom ipk file when cooking

by David Johnson

How do I add a customised ipk file to the cooker. I just compiled a slightly modified bmx6-sms plugin with an increased sms length size for the ar71xx/generic target and I want to cook some firmware for a few different ar71xx/generic profiles using this modified ipk file. Thanks David

6 years, 9 months

1
0
0 0

rethinking network-profiles

by Paul Spooren

Hi all, some time ago I had the (bad) idea to convert network profiles into opkg packages to automatically re-install them after an sysupgrade. Also allow upgrading of network-profiles in case something changed. However, this doesn't work so well as the file `lime-defaults` is provided by `lime-system` as well as any network package. This results in the following error: Collected errors: * check_data_file_clashes: Package zz-qmp-v1 wants to install file /home/aparcar/worker/imagebuilder/lime/17.06/ar71xx/generic/build_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/etc/config/lime-defaults But that file is already provided by package * lime-system * opkg_install_cmd: Cannot install package zz-qmp-v1. make[2]: *** [package_install] Error 255 Makefile:120: recipe for target '_call_manifest' failed make[1]: *** [_call_manifest] Error 2 Makefile:201: recipe for target 'manifest' failed make: *** [manifest] Error 2 So, what to do? We could introduce yet another config file, so people with network-profiles wouldn't fiddle with the `lime-defaults` file but with `network-profile` or something, which would be "a layer between" `lime` and `lime-defaults` config. Another approach would be to get rid of the `lime-defaults` per default, and rely on sane defaults in the modules. The lime-config module already support a fallback aka default value, in case the setting is neither found in `lime` nor `lime-defaults`. Lastly, and my favorite, we could convert all `network-profiles` in (a single) uci-defaults file. Individual options are set via uci, if special files like `authorized_keys` are required, it's possible via `cat EOF <>` magic. This approach would a) allow to be easy to handle via the image-server, which then just stores these single text files, and b) easy to transport to the image server. An additional field in chef could be added called "uci-defaults" where the user simply paste in desired uci settings. Eventually a more sophisticated Chef version would allow to automatically generate a single "uci-config" containing IPs, SSH keys, whatever, all set via the web interface and requested via the generic image server API. Versioning could be done via a hash of the config file, meaning, if the hash is different from the upstream version, update. The `lime` config file would have a new field called `network-profile` or something similar, maybe an URL pointing to the latest uci-config, which is then requested on every build-request. Understandable? Greetings from Nikko, Japan, Paul

6 years, 9 months

4
6
0 0

Little "bug" in Librenet6 documentation commands

by al

Hello! Working with Librenet6 configuration I found a scenario where the documentation go to an error that at the beginning is hard to understand why. In Unix systems "hostname" could be an alphanumeric and accept the hyphen ('-')[1], but Tinc "Name" accept alphanumeric and the underscore ('_')[2], not the hyphen. So, there is a scenario not much uncommon where we could have a hostname with hyphens like "virtual-server-1" or "LiMe-0C9B". So, those parts in documentation could became in a bug: In Debian based: Name = host_$(hostname) In OpenWrt based: HOSTNAME=$(uci get system.(a)system[0].hostname) [0] I have permissions for change the documentation and fix that issue, but I want to talk with you about it because my fix proposal change the way of naming hosts (beginning with an "host_" or "topo_") and it could affect some of others of your scripts: As is written in Tinc manual I think that they have knowledge about this possible collision between to ways of naming hosts. So the manual says: "If Name starts with a $, then the contents of the environment variable that follows will be used. In that case, invalid characters will be converted to underscores. If Name is $HOST, but no such environment variable exist, the hostname will be read using the gethostname() system call."[2] About tinc environment variables[3]. So my proposal is changing from Name = host_$(hostname) # bash variable or Name = topo_$HOSTNAME # bash variable to Name = $HOST # tinc environment variable (And in the file names) result: "host_myniceserver" to "myniceserver". "host_virtual-server-1" (that will fail) to "virtual_server_1" "topo_LiMe-0C9B" (that will fail) to "LiMe_0C9B" But in this case we lost info about if the host came from Debian/Ubuntu manual (host_) or came from OpenWrt manual (topo_). What do you think? Also we made an script for my machines that we can share, off course is in case of an script that this standardization process has sense. Regards. [0] http://docs.altermundi.net/LibreNet6/Setup [1] As wrote in RFC 952 and RFC 1123 [2] http://www.tinc-vpn.org/documentation-1.1/Main-configuration-variables.html Name = <name> [required] This is a symbolic name for this connection. The name must consist only of alfanumeric and underscore characters (a-z, A-Z, 0-9 and _), and is case sensitive. [3] http://www.tinc-vpn.org/documentation/Scripts.html#index-environment-variab… ($HOST environment variable (and maybe others) are not documented)

6 years, 9 months

3
2
0 0

Rewriting JavaScript of chef.libremesh.org

by Paul Spooren

Hi, some time ago I created chef.libremesh.org as a "demo" for the used backend [0]. It's kinda hacked as I learned JavaScript while implementing it. I'm quite unsatisfied by the JS code quality so I wanted to ask if somebody would help me to rewrite it in a better way, using some minimal framework? Best, Paul [0]: https://github.com/aparcar/attendedsysupgrade-server

6 years, 10 months

3
2
0 0

Testing LibreMesh based on OpenWrt 18.06.0-rc1

by Paul Spooren

Hi, on our snapshot server [0] you find LibreMesh builds based on OpenWrt 18.06.0-rc1[1] with packages of the development branch (master) of lime-packages[2]. The folder structure may change within the next days a bit. Many new devices are supported, if you can't find your device on the snapshot builder but it's supported, please report the device[3]! Please report issues on GitHub[4] and prefix the titles with "18.06-rc1: ". Best, Paul [0]: https://snapshots.libremesh.org/18.06.0-rc1/ [1]: https://downloads.lede-project.org/releases/18.06.0-rc1/ [2]: https://github.com/libremesh/lime-packages/ [3]: https://github.com/libremesh/lime-sdk/issues [4]: https://github.com/libremesh/lime-packages/issues

6 years, 10 months

1
0
0 0

chef.libremesh.org respect PACKAGES but not /etc/config/lime-defaults

by Gio

as in subject you can reproduce it by creating an image for the canmasdeu/ bridge profile with plain lede flavour I suspect it is because the profile get opkgized and it may be installed before lime-system and then the file get overwritten haven't tested if with last cooker it happens or not to confirm my theory Cheers

6 years, 11 months

3
6
0 0

Re: [lime-dev] LibreMesh docker image

by Paul Spooren

Check the .travis.yml files, feel free to add stuff to a readmeOn Jun 24, 2018 3:45 AM, guifipedro <guifipedro(a)gmail.com> wrote: > > I'm very happy you did that. > > Can you add the details to do the openwrt base image? [1] > > Thanks > > [1] https://github.com/aparcar/openwrt-docker > > On Sat, Jun 23, 2018 at 7:00 PM, Paul Spooren <mail(a)aparcar.org> wrote: > > Hi all, > > > > to simplify image testing for users which are not familiar with qemu I > > created a docker image containing LibreMesh. > > > > If you like check it out at aparcar/libremesh with the tags "latest" or > > "stable" > > > > All further information for usage are described in the README [0], feel > > free to extend it. > > > > In case the docker thing turns out to be of any use, I'd swap it to the > > official libremesh account. > > > > Sunshine, > > Paul > > > > [0]: https://github.com/aparcar/libremesh-docker/blob/master/README.md > > > > _______________________________________________ > > lime-dev mailing list > > lime-dev(a)lists.libremesh.org > > https://lists.libremesh.org/mailman/listinfo/lime-dev > _______________________________________________ > lime-dev mailing list > lime-dev(a)lists.libremesh.org > https://lists.libremesh.org/mailman/listinfo/lime-dev

6 years, 11 months

1
0
0 0

LibreMesh docker image

by Paul Spooren

Hi all, to simplify image testing for users which are not familiar with qemu I created a docker image containing LibreMesh. If you like check it out at aparcar/libremesh with the tags "latest" or "stable" All further information for usage are described in the README [0], feel free to extend it. In case the docker thing turns out to be of any use, I'd swap it to the official libremesh account. Sunshine, Paul [0]: https://github.com/aparcar/libremesh-docker/blob/master/README.md

6 years, 11 months

2
1
0 0

New flavor for new LibreMesh release

by Paul Spooren

Hi all, OpenWrt 18.06 is just around the corner with fun new stuff, like options to encrypted 11s mesh & support for tons of new devices! To create a LibreMesh release that satisfies all tastes, we should think a bit of new flavors, meaning the combination of preinstalled packages. Some points to consider: * There is a new lime-proto-babeld plugin allowing babeld routing * The lime-proto-bmx7 plugin and BMX7 itself became way more stable and has various advances over BMX6 * Using encrypted mesh requires wpand-mesh-{openssl, wolfssl} installed, aka big crypto libs * The lime-app shows some basic infos which could satisfy basic user requirements. I'm happy to merge flavor PRs and build them on our new snapshot server for all common targets. Sunshine, Paul

6 years, 11 months

3
4
0 0

TL-WR941ND board.json content

by Paul Spooren

Hi all, does anyone has a TL-WR941ND laying around? If so, please send me the content of /etc/board.json, that would greatly help me to improve LibreMesh. Best

6 years, 11 months

1
0
0 0

Adding meshrc to snapshots

by Paul Spooren

Hi, for my bachelor thesis I created some tools which hopefully simplify monitoring & managing of mesh networks. The scope wasn't exactly community networks (sorry, not my choice) but we can may bend the stuff to make it work for LibreMesh real purpose as well! All source is found here https://github.com/aparcar/meshrc To simplify my own tests with it, I'd like to setup a package feed. If nobody minds I'd create an additional feed at snapshots.libremesh.org called meshrc. Best, Paul

6 years, 11 months

3
3
0 0

Cleaning GitHub repos

by Paul Spooren

Hi, I found some old GitHub repo forks which rather confuse users then do any good, if everyone is okay with that I'd remove them: * openwrt * openwrt-packages * openwrt-oldpackages * demeshtify What happens at lime-ui-ng? Isn't that covered in lime-packages-ui which uses lime-app? Best

6 years, 11 months

2
2
0 0

Removing comments of Lua code before installing

by Paul Spooren

Hi, in various parts of lime-packages I found the following code snipped: define Build/Compile @rm -rf ./build || true @cp -r ./src ./build @sed -i '/^--!.*/d' build/*.lua endef It removes all comments from the source code before applying it to the devices. Is the size impact worth the fact that a) people locally developing may accidentally change files in ./build rather then ./src and by running make overwriting all their changes b) Make on device developing harder due to missing comments? I'm guessing there are other parts of LibreMesh bloated which could improve storage footprint more than this little hack, what do you think? Best, Paul

6 years, 11 months

2
1
0 0

Rename branch develop to master

by Paul Spooren

I pushed a new branch to libremesh/lime-packages called master. We should from now on use this one instead of develop. I'd the scripts of lime-sdk to use this branch in develop mode. To clean up the outdated branches and repositories of /libremesh please grant me the required GitHub permissions. Best

6 years, 11 months

1
0
0 0

New location for snapshots.libremesh.org

by Paul Spooren

Hi, we got a new snapshots server which can host (and build) CI stuff. I created a travis CI script so on each push it's building all LiMe packages and uploads them to the server. The LibreRouter specific stuff is also mirrored there. Whoever needs access to update these files please ping me. Who is in charge of the libremesh.org domain? Please forward snapshots.libremesh.org to: IPv4: 141.54.160.32 IPv6: 2001:470:6c:1f4::2 Thanks, Paul

6 years, 11 months

2
1
0 0

Add PKGARCH:=all to all possible packages

by Paul Spooren

Hi, dealing lately a bit with CI and build packages for all popular targets I found that most LiMe packages only use scripts like Lua and Bash and therefore don't really need to be compiled target specific. Idea is to add the PKGARCH:=all parameter which allows to install resulting packages on all targets without opkg protesting. I created an Pull request for that[1], please try! You can simply add `.diff` to the url and receive a diff which is usable with `git apply 370.diff`. Eventually we could offer generic feeds in the `/etc/opkg/limefeeds.conf` file and save a lot of build time. A few packages actually require compiling and are thereby not arch independent, namely: * dhcpdiscover * reghack * lime-webui Are the first two packages actively used? I've never stumbled across them. Best, Paul [1]: https://github.com/libremesh/lime-packages/pull/370

6 years, 11 months

1
0
0 0

Re: [lime-dev] Simplify the lime-packages branches

by Nicolas Pace

Agree! On May 29, 2018 2:17:13 AM CDT, Paul Spooren <p(a)aparcar.org> wrote: >Hi all, > >The lime-packages repository has currently a huge amount of branches >making it rather hard to spot active ones. I'd propose to use the >following structure (stolen from OpenWrt): > >* Use one branch for developing (currently called "development", may >better be unified to " master"). >* One brach per release > > >This is great because new people don't start developing on master and >eventually find out its "outdated". The structure is used on literally >every other GH project I'm working on, even on other LibreMesh repos. > >All pull requests should come from forked repos. > >Additionally, the dev branch is currently (partly) protected so that >most devs can't directly push there but need an approved PR, which is >good. However, the master branch aka current stable release lacks this >security measurement. > >Best, >Paul >_______________________________________________ >lime-dev mailing list >lime-dev(a)lists.libremesh.org >https://lists.libremesh.org/mailman/listinfo/lime-dev -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

6 years, 11 months

1
0
0 0

Snapshot builds

by Paul Spooren

Hello again, I think for development it would be nice to automatically compile all packages on the dev branch on every push. Offering them on a server making it easy to use in dev machines. As this introduces plenty of compiling of suggest to use cheap cloud service instead of burning our own (community) hardware. Scaleway offers 4 cores and 25GB SSD for 3€ a month, which should be just enough. Any reasons against pointing snapshots.libremesh.org to such a VM? I'd be happy to set it up and can also pay for now. Best, Paul

6 years, 11 months

1
0
0 0

Simplify the lime-packages branches

by Paul Spooren

Hi all, The lime-packages repository has currently a huge amount of branches making it rather hard to spot active ones. I'd propose to use the following structure (stolen from OpenWrt): * Use one branch for developing (currently called "development", may better be unified to " master"). * One brach per release This is great because new people don't start developing on master and eventually find out its "outdated". The structure is used on literally every other GH project I'm working on, even on other LibreMesh repos. All pull requests should come from forked repos. Additionally, the dev branch is currently (partly) protected so that most devs can't directly push there but need an approved PR, which is good. However, the master branch aka current stable release lacks this security measurement. Best, Paul

6 years, 11 months

1
0
0 0

Does the Version of the WDR3600 / WDR3500 Matter? Also, is the only difference between the 3500 and the 3600 gigabit ethernet ports?

by John W

I found a used WDR3600 version 1.1 and wanted to know if there is any advantage to any particular hardware version for libremesh? Am I correct in saying that the only difference between the WDR3500 and the WDR3600 is that the WDR3600 has gigabit ethernet ports?

7 years, 1 month

2
1
0 0

What LibreMesh Router Models receive the most development effort, the most timely security updates, are most stable / secure with the most developed features, etc?

by John W

What LibreMesh Router Models receive the most development effort, the most timely security updates, are most stable / secure with the most developed features, etc? Thanks! -John

7 years, 1 month

2
3
0 0

Request to support in compiling Libremesh for GL-INET AR750 router.

by senthil kumar

Hi Libremesh Dev Team, I am very actively using Libremesh to set up the community network in India. I have used GL-INet AR150 single band router. Now I would like to build libremesh firmware for AR750 router. More Details about the router https://openwrt.org/toh/hwdata/gl.inet/gl.inet_gl-ar750 This is officially supported in openwrt/LEDE https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2e5252d346e2ec832… Can someone help me in compiling this? I am facing error while compiling. How to add the profile for gl-ar750 in libremesh? Looking forward to the reply. *senthilm@sencloud*:*~/lime-sdk*$ ./cooker -c ar71xx/generic --profile=gl-ar750 --flavor=lime_default --remote -> Using remote repository for ImageBuilder, architecture: mips_24kc -> Cooking ar71xx/generic/gl-ar750 -> Cooking firmware image --> Selected extra packages: lime-full lime-app -dnsmasq make: Entering directory '/home/senthilm/lime-sdk/17.01.4/ar71xx/generic/ib' *Profile "gl-ar750" does not exist!* PS gl-ar150 is compiling without error. -- Thanks and Regards, * • **Senthilkumar M* * • **Community Manager,* * • **Google Developer Group Madurai**,* *• **Mentor, Metoomentor.org* * • **Senior Research Engineer, Qualcomm. * * • allaboutsenthil.in <http://allaboutsenthil.in>* • +91 8095207092

7 years, 1 month

2
2
0 0

GSoC project

by Paul Spooren

Dear all, as some may know I've been working last year [1] in GSoC and like to repeat that. I checked the Freifunk project page [2] and found the following project of LibreMesh I liked most: LibreNet6 integration [3]. As discussed on GitHub [4] wireguard [5] could be a slim & fast replacement for Tinc. Problem is the missing auto provisioning of the clients, as stated on the official website as well [6]. I came up with a small PoC [7] as a centralized solution for the following tasks: * Granting administrators/supporters device access to help with network issues * Secure connection over an unencrypted mesh network * Offer public IPv4/6 to routers A second approach could be to use bmx7-sms plugin to distribute public keys within the mesh and enable not only the three points above but also secure connections between all nodes. The second approach may become obsolete as bmx7 might use `ip xfrm` [8] to encrypt tunnels directly. I'm aware that focus shouldn't be the coolest project but the one most usable for the (Libre)Mesh community. So please share you thoughts if you find other (not listed) project ideas I could work on. Please keep in mind the deadline to apply is within the next weeks. Best, Paul [1] https://github.com/aparcar/attendedsysupgrade-server [2] https://projects.freifunk.net/#/projects [3] https://projects.freifunk.net/#/projects?project=libremesh_librenet6_integr… [4] https://github.com/libremesh/lime-packages/issues/99 [5] http://wireguard.com/ [6] https://www.wireguard.com/todo/#dynamic-web-app-for-provisioning [7] https://github.com/aparcar/wireguard-provisioning [8] http://man7.org/linux/man-pages/man8/ip-xfrm.8.html#DESCRIPTION

7 years, 1 month

3
4
0 0

lime-cc cloud configuration

by Paul Spooren

Hi all, as mentioned in my RFC on GitHub [1] I thought of a simple way to configure a cloud (from within the cloud) by using the bmx7-sms plugin [2]. To show you the idea and how it could work please check my fork [3]. Here the commit message: * lime-cc-client check every 5 minutes for a new configuration received by bmx7-sms. if the configuration is valid and the node is trusted the configuration is used as default, lime-config and lime-apply runs. if not, the configuration is ignored. * lime-cc-server distributes it own lime-defaults to the cloud. If changes happen to the config it will be distributed to the cloud. Would be happiest to hear for comments. Best, Paul [1] https://github.com/libremesh/lime-packages/issues/304 [2] https://github.com/bmx-routing/bmx7#sms-plugin [3] https://github.com/aparcar/lime-packages/commit/e8ceb46dd56166398161090bc75…

7 years, 3 months

1
0
0 0

LiMeCat2018q1

by Ilario Gelmetti

Dear all, there will be a LibreMesh hackaton in CSOA Matakrostes [1] for the weekend of 10th-11th of February. You can participate to the meeting remotely via Matrix chat (also accessible via IRC) [2]. Ciao, Ilario [1] Passeig de Sevilla 132, Valldoreix, Barcelona https://guifi.net/VDXpgSevilla132 [2] https://libremesh.org/communication.html

7 years, 3 months

1
0
0 0

Building SNAPSHOT libremesh releases yourself ?

by Mark Birss

Hi Kindly assist with steps todo my own build with snapshot Regards

7 years, 4 months

1
0
0 0

GSoC 2018 Ideas

by Paul Spooren

Hello, the new GSoC [1] is coming up and all organizations can apply with fresh ideas. This year the deadline is already on 23.01 so we should move quick! Luckly, the german Freifunk community created a website to collect ideas [2]. We could discuss here needed features and projects and decide who writes a (short) proposal for the website. I already did so and created an project proposal to work on the new bmx7 [3]. As I'm still a student I'd very much like to participate again. Last year I worked on the image server and chef [4] which slowly gains some attention. If possible I could continue the work on that as well. So far so good, Paul [1] https://summerofcode.withgoogle.com/ [2] https://github.com/freifunk/projects.freifunk.net-contents [3] https://projects.freifunk.net/#/projects?project=bmx7_semtor_web_interface&… [4] https://chef.libremesh.org

7 years, 4 months

2
1
0 0

Exit via VPN

by Dennis Hecken

Dear LibrrMesh Team, is it possible only grant access to internet only via VPN like vpn.ac or PricateInternetAccess.com or just fastd? In Germany the law is not the best in this case and publishing the private internet Access to public is risky! I did not find any information about this feature. Thanks a lot! Best regards, Dennis

7 years, 4 months

2
1
0 0

lime-sdk fails to generate some images (too big kernel size)

by Roger Pueyo Centelles | Guifi.net

Dear LiMers, I've been recently using the lime-sdk tool (actually, a fork <https://dev.qmp.cat/projects/qmp-cooker/>) to generate images for a number of devices <https://dev.qmp.cat/projects/qmp-cooker/repository/revisions/master/entry/q…>. Overall it's been very successful but, with some of them, I've faced some trouble. Take the example of the Alfa N5 outdoor wireless CPE (target=ar71xx/generic, profile=ALFANX), which has 8 MB of flash (enough to fit a lot of packages). Once the additional packages are built (./cooker -b ar71xx/generic --force-local) I cook the image (./cooker -c ar71xx/generic --profile=ALFANX) but the process fails: the kernel built locally is too big to fit in the device's partition scheme. I guess the problem comes from the fact that the SDK builds packages with some extra options (debug, symbols, etc.) compared to the Buildroot. Have you experienced this behaviour? Do you have any idea on how to overcome this? The lime-sdk cooker is a wonderful tool, and it would be very nice to make it work with all the devices. Cheers, Roger

7 years, 4 months

3
3
0 0

SSH access with password

by Paul Spooren

Hi all, I've just checked and the following servers all allow login via password (instead of SSH key only). Is anyone actually using this? I'd recommend to disable all password access and SSH key only or additionally install sshguard [1] to block brute force attacks. - libremesh.org - downloads.libremesh.org - snapshots.libremesh.org - more? Best, Paul [1] https://packages.debian.org/jessie/sshguard

7 years, 5 months

2
1
0 0

Community profiles

by Anthony Garcia

Hello Libremesh team, first and foremost thank you for your hard work and effort that has gone into creating this platform. I have a question regarding the creation of local network profiles. Based on the directory structure for the community profiles established. In order to customize the firmware are we supposed to place the lime-default file in lime-sdk/communities/communityname/profilename/etc/config/ When I specify my own custom profile, the cooked firmware is not customized using the "--community=name/profile"" switch. I can successfully cook the pre-existing network-profiles that were downloaded from the git. Is there any additional documentation regarding this function that I may have missed for local development? Thank you, -Tony

7 years, 6 months

2
6
0 0

Jefe.tk to build images

by Paul Spooren

Hi all, as chef.altermundi.net is somewhat outdated I created a simplified version called "Jefe" (Spanish for chef). Currently it jefe.tk has the following features: - Build latest stable 17.06 (dev tree could be added as well) - Easy to find device, just type in the name - Choose network profile - Choose flavor - Edit packages (if desired) More features can be added, let me know what you need. This is a very early version, let me know what you think! Best, Paul

7 years, 6 months

9
19
0 0

are we checking that the wifi drivers support apname?

by Nicolas Pace

Hi all, While reading the openwrt wiki, I stumbled upon this paragraph: https://wiki.openwrt.org/doc/uci/wireless#wifi_networks A complete wireless configuration contains at least one wifi-iface section per adapter to define a wireless network on top of the hardware. Some drivers support multiple wireless networks per device: broadcom if the core revision is greater or equal 9 (see dmesg | grep corerev) madwifi always supports multiple networks mac80211 STA mode is supported. STA and AP at the same time is supported as well. So... we are using multiple-ap extensively and maybe some of the devices that we can flash this on does not support them. It might be interesting to add to our heuristics this check: if the driver is not one of those, then use that radio only for one use. What do you think? Regards,

7 years, 7 months

1
0
0 0

Release 17.06 "Dayboot Rely"

by Gui Iribarren

So, this release was meant to be announced many months ago (as the numbering suggests) but lack of coordination (me, gio, pau) delayed it. In the meantime, some more fixes and improvements were introduced, and most importantly, several (unpublished) intermediate "release candidates" have been running for months now, in different community networks (QuintanaLibre mainly, thanks to persevering NicoEchaniz, and other smaller deployments) Highlights are that ieee80211s is used by default (instead of adhoc) which breaks "backward" connectivity with previous releases, as well as changes in vlan tagging policy of bmx6 and batadv (which also are not backwards compatible by default) most notably, this vlan change fixes a hard-to-debug mtu shrinking bug that pestered all releases so far (symptoms were varied and bizarre, like having timeouts when trying to browse certain https sites, sometimes, on random devices) the biggest highlight on the dev side, is that we now use upstream SDK (thanks to dangowrt for pushing this, and pau for implementing it!) which brings us much closer to LEDE/OpenWrt and allows reporting upstream ath9k bugs or such, among other benefits * generic binaries, meant for testing or setting up temporary networks (i.e. when having the default AP SSID = LibreMesh.org is fine) http://downloads.libremesh.org/dayboot_rely/17.06/targets/ (build is running right now, binaries should be ready tomorrow for sure) * for custom builds, the recommended tool at this point is lime-sdk http://libremesh.org/getit.html#cook_your_own_firmware_using_lime_sdk https://github.com/libremesh/lime-sdk * chef builds are not available at this point. there are plans to integrate this release into chef in the future, but no ETA :( ### Most of the following changelog was accomplished during the 2017/03 hackaton (https://www.youtube.com/watch?v=5UX1FwhIKGY) Changelog Dayboot Rely 17.06 (since 16.07) * based on LEDE 17.01.2 * build everything using LEDE SDK, via new lime-sdk cooker (instead of lime-build) * use ieee80211s instead of adhoc * reintroduced "firewall" package (to keep closer to upstream) * lime-system: fix ieee80211s proto, correctly construct ifnames * lime-system: sanitize hostname (transform everything into alphanumeric and dash) * lime-system: new proto static * lime-system: new wifi mode client * lime-system: set dnsmasq force=1 to ensure dnsmasq never bails out * lime-system: explicitly populate /etc/config/lime with calculated values * lime-webui: enable i18n, finally webinterface is available in Spanish * lime-webui: Major rework by NicoPace, thanks! * bmx6 node graph now uses colors in a clever way * simple way to add "system notes" that are shown along with /etc/banner and webui * luci-app-lime-location: fix google maps api key * new read-only view: switch ports status * alert luci-mod-admin users that their changes might get overwritten by lime-config * fix batman-adv status webui * new package available to install lighttpd instead of uhttpd (needed for an upcoming android app) * added a lime-sysupgrade command: does a sysupgrade but only preserving libremesh configuration file * added a lime-apply command: basically calls reload_config, but also applies hostname system-wide without rebooting * lime-hwd-ground-routing: ground routing now supports untagged ports too * lime-proto-anygw: unique mac based on ap_ssid (using %N1, %N2) * lime-proto-anygw: integrate better into /etc/config/dhcp instead of /etc/dnsmasq.d/ * lime-proto-wan: allow link-local traffic over wan (useful for local ping6 and ssh, without global exposure) * lime-proto-batadv: set batadv gw_mode=client by default to counteract rogue DHCP servers * lime-proto-bmx6: introduce bmx6_pref_gw option, adds priority (x10) to a specific bmx6 gateway * lime-proto-bmx6: don't tag bmx6 packets over ethernet and so use at least mtu=1500 everywhere * lime-proto-bmx6: avoid autodetected wan interface use vlan for bmx6 * bmx6: doesn't flood log with some spurious warnings anymore (syslog=0) * bmx6: sms plugin now enabled by default * bmx6: daemon is now supervised by procd, so it is restarted in case of crashes * bmx6: doesn't "configSync" by default anymore (no more "uci pending changes" because of auto-gw-mode) * new bmx6hosts tool: maintain an /etc/hosts that resolves fd66: <-> hostnames.mesh * watchping: convert to procd and add reload triggers * safe-reboot: fix, use /overlay/upper instead of /overlay * safe-reboot: add "discard" action * ath9k: debugged some hangs (interface is deaf) and workaround it, with new package "smonit" * set wifi default "distance" parameter to 1000 metres and make it configurable through webui * alfred: fix bat-hosts facter, check for errors and don't nuke /etc/bat-hosts in case of failure * introduce new lime-basic-noui metapackage * new packages separated: lime-docs and lime-docs-minimal * various Makefile dependency problems fixed known bugs: * safe-reboot: newly introduced "discard" action is half-baked, avoid usage until next release: It doesn't check whether there's a backup to restore or not - https://github.com/libremesh/lime-packages/issues/203 so executing "safe-reboot discard" without having done "safe-reboot" first, will brick the router. (unbricking is possible via failsafe boot, and doing "mount_root && firstboot") In the commit log authors you can see the usual suspects ;) but happily many new names! https://github.com/libremesh/lime-packages/graphs/contributors?from=2016-09… and remember it's not only code/commits what matters, so big thanks as well to everyone participating in mailing lists, maintaining website, documentation (spread around the web, in many languages!)

7 years, 7 months

1
0
0 0

documentation

by ignifugo＠insicuri.net

hi, I did a new pull request in lime-web with the translation of howto. I'm tring also to do a guide of the web interface of LibreMesh. This is a first idea: https://uploads.knightlab.com/storymapjs/b6a9a4c44954565a32b64198c73cb6e7/1… the problem for me is that doc is not to improve, but to write, and I'm not enough in deep to do these. Can someone help me. thanks Ignifugo

7 years, 8 months

2
1
0 0

strange messages in cooker

by Gio

Cooking with this command i get this strange messages, should we mind about them? ./cooker -c ar71xx/generic --flavor=lime_newui_test --extra-pkg="lime-app collectd collectd-mod-network collectd-mod-interface collectd-mod-syslog collectd-mod-load collectd-mod-memory collectd-mod-ping" -- community=NonoLibre/comun --profile=tl-wdr3500-v1 tmp/.config-package.in:7:warning: ignoring type redefinition of 'PACKAGE_busybox' from 'boolean' to 'tristate' tmp/.config-package.in:27:warning: ignoring type redefinition of 'PACKAGE_dnsmasq' from 'boolean' to 'tristate' tmp/.config-package.in:101:warning: ignoring type redefinition of 'PACKAGE_firewall' from 'boolean' to 'tristate' tmp/.config-package.in:122:warning: ignoring type redefinition of 'PACKAGE_jsonfilter' from 'boolean' to 'tristate' tmp/.config-package.in:166:warning: ignoring type redefinition of 'PACKAGE_libc' from 'boolean' to 'tristate' tmp/.config-package.in:194:warning: ignoring type redefinition of 'PACKAGE_libgcc' from 'boolean' to 'tristate' tmp/.config-package.in:251:warning: ignoring type redefinition of 'PACKAGE_libpthread' from 'boolean' to 'tristate' tmp/.config-package.in:373:warning: ignoring type redefinition of 'PACKAGE_rpcd' from 'boolean' to 'tristate' tmp/.config-package.in:436:warning: ignoring type redefinition of 'PACKAGE_ubus' from 'boolean' to 'tristate' tmp/.config-package.in:451:warning: ignoring type redefinition of 'PACKAGE_ubusd' from 'boolean' to 'tristate' tmp/.config-package.in:465:warning: ignoring type redefinition of 'PACKAGE_uci' from 'boolean' to 'tristate' tmp/.config-package.in:1384:warning: ignoring type redefinition of 'PACKAGE_kmod-ath' from 'boolean' to 'tristate' tmp/.config-package.in:1458:warning: ignoring type redefinition of 'PACKAGE_kmod-ath9k' from 'boolean' to 'tristate' tmp/.config-package.in:1488:warning: ignoring type redefinition of 'PACKAGE_kmod-ath9k-common' from 'boolean' to 'tristate' tmp/.config-package.in:1889:warning: ignoring type redefinition of 'PACKAGE_kmod-cfg80211' from 'boolean' to 'tristate' tmp/.config-package.in:2158:warning: ignoring type redefinition of 'PACKAGE_kmod-mac80211' from 'boolean' to 'tristate' tmp/.config-package.in:2731:warning: ignoring type redefinition of 'PACKAGE_libiwinfo-lua' from 'boolean' to 'tristate' tmp/.config-package.in:2746:warning: ignoring type redefinition of 'PACKAGE_lua' from 'boolean' to 'tristate' tmp/.config-package.in:2851:warning: ignoring type redefinition of 'PACKAGE_libip4tc' from 'boolean' to 'tristate' tmp/.config-package.in:2865:warning: ignoring type redefinition of 'PACKAGE_libip6tc' from 'boolean' to 'tristate' tmp/.config-package.in:2895:warning: ignoring type redefinition of 'PACKAGE_libxtables' from 'boolean' to 'tristate' tmp/.config-package.in:2964:warning: ignoring type redefinition of 'PACKAGE_libblobmsg-json' from 'boolean' to 'tristate' tmp/.config-package.in:3065:warning: ignoring type redefinition of 'PACKAGE_libiwinfo' from 'boolean' to 'tristate' tmp/.config-package.in:3080:warning: ignoring type redefinition of 'PACKAGE_libjson-c' from 'boolean' to 'tristate' tmp/.config-package.in:3093:warning: ignoring type redefinition of 'PACKAGE_liblua' from 'boolean' to 'tristate' tmp/.config-package.in:3209:warning: ignoring type redefinition of 'PACKAGE_libnl-tiny' from 'boolean' to 'tristate' tmp/.config-package.in:3322:warning: ignoring type redefinition of 'PACKAGE_libubox' from 'boolean' to 'tristate' tmp/.config-package.in:3348:warning: ignoring type redefinition of 'PACKAGE_libubus' from 'boolean' to 'tristate' tmp/.config-package.in:3361:warning: ignoring type redefinition of 'PACKAGE_libubus-lua' from 'boolean' to 'tristate' tmp/.config-package.in:3375:warning: ignoring type redefinition of 'PACKAGE_libuci' from 'boolean' to 'tristate' tmp/.config-package.in:3388:warning: ignoring type redefinition of 'PACKAGE_libuci-lua' from 'boolean' to 'tristate' tmp/.config-package.in:4329:warning: ignoring type redefinition of 'PACKAGE_luci-base' from 'boolean' to 'tristate' tmp/.config-package.in:4355:warning: ignoring type redefinition of 'LUCI_LANG_hu' from 'boolean' to 'tristate' tmp/.config-package.in:4358:warning: ignoring type redefinition of 'LUCI_LANG_pt' from 'boolean' to 'tristate' tmp/.config-package.in:4361:warning: ignoring type redefinition of 'LUCI_LANG_sk' from 'boolean' to 'tristate' tmp/.config-package.in:4364:warning: ignoring type redefinition of 'LUCI_LANG_no' from 'boolean' to 'tristate' tmp/.config-package.in:4367:warning: ignoring type redefinition of 'LUCI_LANG_en' from 'boolean' to 'tristate' tmp/.config-package.in:4370:warning: ignoring type redefinition of 'LUCI_LANG_el' from 'boolean' to 'tristate' tmp/.config-package.in:4373:warning: ignoring type redefinition of 'LUCI_LANG_uk' from 'boolean' to 'tristate' tmp/.config-package.in:4376:warning: ignoring type redefinition of 'LUCI_LANG_ru' from 'boolean' to 'tristate' tmp/.config-package.in:4379:warning: ignoring type redefinition of 'LUCI_LANG_vi' from 'boolean' to 'tristate' tmp/.config-package.in:4382:warning: ignoring type redefinition of 'LUCI_LANG_de' from 'boolean' to 'tristate' tmp/.config-package.in:4385:warning: ignoring type redefinition of 'LUCI_LANG_ro' from 'boolean' to 'tristate' tmp/.config-package.in:4388:warning: ignoring type redefinition of 'LUCI_LANG_ms' from 'boolean' to 'tristate' tmp/.config-package.in:4391:warning: ignoring type redefinition of 'LUCI_LANG_pl' from 'boolean' to 'tristate' tmp/.config-package.in:4394:warning: ignoring type redefinition of 'LUCI_LANG_zh-cn' from 'boolean' to 'tristate' tmp/.config-package.in:4397:warning: ignoring type redefinition of 'LUCI_LANG_ko' from 'boolean' to 'tristate' tmp/.config-package.in:4400:warning: ignoring type redefinition of 'LUCI_LANG_he' from 'boolean' to 'tristate' tmp/.config-package.in:4403:warning: ignoring type redefinition of 'LUCI_LANG_zh-tw' from 'boolean' to 'tristate' tmp/.config-package.in:4406:warning: ignoring type redefinition of 'LUCI_LANG_tr' from 'boolean' to 'tristate' tmp/.config-package.in:4409:warning: ignoring type redefinition of 'LUCI_LANG_sv' from 'boolean' to 'tristate' tmp/.config-package.in:4412:warning: ignoring type redefinition of 'LUCI_LANG_ja' from 'boolean' to 'tristate' tmp/.config-package.in:4415:warning: ignoring type redefinition of 'LUCI_LANG_ca' from 'boolean' to 'tristate' tmp/.config-package.in:4418:warning: ignoring type redefinition of 'LUCI_LANG_es' from 'boolean' to 'tristate' tmp/.config-package.in:4421:warning: ignoring type redefinition of 'LUCI_LANG_pt-br' from 'boolean' to 'tristate' tmp/.config-package.in:4424:warning: ignoring type redefinition of 'LUCI_LANG_cs' from 'boolean' to 'tristate' tmp/.config-package.in:4427:warning: ignoring type redefinition of 'LUCI_LANG_fr' from 'boolean' to 'tristate' tmp/.config-package.in:4430:warning: ignoring type redefinition of 'LUCI_LANG_it' from 'boolean' to 'tristate' tmp/.config-package.in:4435:warning: ignoring type redefinition of 'PACKAGE_luci-mod-admin-full' from 'boolean' to 'tristate' tmp/.config-package.in:4540:warning: ignoring type redefinition of 'PACKAGE_luci-theme-bootstrap' from 'boolean' to 'tristate' tmp/.config-package.in:4580:warning: ignoring type redefinition of 'PACKAGE_luci-lib-ip' from 'boolean' to 'tristate' tmp/.config-package.in:4618:warning: ignoring type redefinition of 'PACKAGE_luci-lib-jsonc' from 'boolean' to 'tristate' tmp/.config-package.in:4632:warning: ignoring type redefinition of 'PACKAGE_luci-lib-nixio' from 'boolean' to 'tristate' tmp/.config-package.in:5197:warning: ignoring type redefinition of 'PACKAGE_ip6tables' from 'boolean' to 'tristate' tmp/.config-package.in:5245:warning: ignoring type redefinition of 'PACKAGE_iptables' from 'boolean' to 'tristate' tmp/.config-package.in:6525:warning: ignoring type redefinition of 'PACKAGE_uhttpd' from 'boolean' to 'tristate' tmp/.config-package.in:6561:warning: ignoring type redefinition of 'PACKAGE_uhttpd-mod-ubus' from 'boolean' to 'tristate' tmp/.config-package.in:6760:warning: ignoring type redefinition of 'PACKAGE_hostapd-common' from 'boolean' to 'tristate' tmp/.config-package.in:6923:warning: ignoring type redefinition of 'PACKAGE_iw' from 'boolean' to 'tristate' tmp/.config-package.in:7136:warning: ignoring type redefinition of 'PACKAGE_wpad-mini' from 'boolean' to 'tristate' tmp/.config-package.in:7172:warning: ignoring type redefinition of 'PACKAGE_iwinfo' from 'boolean' to 'tristate' tmp/.config-package.in:7185:warning: ignoring type redefinition of 'PACKAGE_jshn' from 'boolean' to 'tristate' tmp/.config-package.in:7256:warning: ignoring type redefinition of 'PACKAGE_libjson-script' from 'boolean' to 'tristate' Config-build.in:10099:warning: defaults for choice values not supported Config-build.in:10103:warning: defaults for choice values not supported Config-build.in:10107:warning: defaults for choice values not supported Config-build.in:10111:warning: defaults for choice values not supported Config-build.in:10115:warning: defaults for choice values not supported Config-build.in:10119:warning: defaults for choice values not supported Config-build.in:10135:warning: defaults for choice values not supported

7 years, 8 months

2
3
0 0

Licensing for the code

by Ilario Gelmetti

I cite from Marcos: > I was analyzing the licensing situation in the lime-packages > repository. There is no file that indicates the global license, there > is no CLA (Contributor License Agreements) and there are copyright > headers set in some files inconsistently. >> Talking with some of the developers we consider it appropriate to > establish a license (such as GLPv3 or AGPLv3). This would affect future > contributions, but it would be necessary for contributors to accept > that their already written code is also licensed. > > To solve this situation I propose: > > * Set a license > * Clarify that the contributions made in this repository respect that > license. > * Change existing headers and add missing ones. > * Create a pull request with all these changes and approve the merge > among all contributors as a form of acceptance. The discussion started here: https://github.com/libremesh/lime-packages/issues/213

7 years, 9 months

1
0
0 0

Porting Libre Mesh into MP02-AWD

by Carlos Rey-Moreno

Hi everyone, I've following the list for quite some time and it was only in the last month that I got myself together and installed LiMe in some Mesh Potatoes (based on Dragino MS14) that I had with me. In Zenzeleni we've been using MPs and VillageTelco firmware from the beginning, and although they are "very Plug & Play" and easy to use for non-geeks, I was pretty impressed by LiMe. What you have done making IP disappear is quite something as it is one of the concepts people struggle with the most. So now, we are seriously considering using LiMe at Zenzeleni. However, we need a bit of guidance on creating a built for the MP02-AWD which is the hardware we have in our networks. It is based on the Dragino MS14, so the internal radio works from scratch after flashing. However, I'd like to add the secondary radio (ralink usb) to the build, and have the wireless config files modified accordingly, so it works directly after being flashed. Anyone keen to guide me about how to do it? Thanks in advance, carlos -- Carlos Rey-Moreno, PhD PostDoctoral Fellow University of the Western Cape Zenzeleni Networks: zenzeleni.net https://www.youtube.com/watch?v=YxTPSWMX26M Cel: +27 (0) 76 986 3633 <+27%2076%20986%203633> Skype: carlos.reymoreno Twitter: Creym

7 years, 9 months

3
9
0 0

Suggestion on spreading knowledge

by Amuza

Hi, Sometimes I feel shy to ask in the mailing list things that have been answered before. Sometimes it is not easy to find those old answers. If someone is new to the list, maybe she should first browse within the old archives published in the web [0] so that you don't get sick of us. I do not know an easy way to browse those old mail archives in the web. Would you be interested in having the mailing list published as a web forum too? That might boost the learning curve for just-arrived people. New users would have all the answers easily accessible in a web forum. In Trisquel the mailing list [1] and the web forum [2] -which has a very useful 'search' box- are connected. They are the same thing, they have the same contents, published in real time. You can use either the mailing list or the web forum to both read and write. I do not know if you find this interesting to have it for LibreMesh. I do not know if this is something easy to implement. But I am sure the animals in the Trisquel community would be happy to share with you. (Or maybe you know better solutions) I do not know whether old LiMe mail archives could be dumped into a web forum so that old mail is also published there, or the forum would need to start from scratch. It was just a suggestion, if you do nothing it's alright, you normally answer everything we ask. [0] https://lists.libremesh.org/pipermail/lime-users/ [1] https://listas.trisquel.info/mailman/listinfo/ [2] https://trisquel.info/en/forum

7 years, 9 months

3
4
0 0

First steps on Continuous Integration for LibreMesh

by Nicolas Pace

Hello everyone, Ilario and I finally finished to have everything configured to have continuous integration for the lime-packages repository. https://github.com/libremesh/lime-packages/pull/186 Continuous Integration (CI) is the practice of having tests done on every branch that is going to become part of your master branch, in order to fulfill a certain level of quality. The current stake on doing CI runs a build on all the repo and verifies that it runs successfully. So, if you have any tests on your code (hint: nothing there for the moment) it will be run with your build and fail if something changed that broke the code. Also, the CI will publish the resulting images from the build as a comment on the Pull Request to facilitate the testing... no more need to build locally to test the branch. Just download the image, run it on qemu and test. That way we reduce preparation time for testing from 30+ minutes to 5 minutes or less. if you are interested in adding tests to the code, I've written a blogpost on freifunk blog about talking about lua and testing (one of the languages we use on LibreMesh): https://blog.freifunk.net/2017/06/29/tdd-unit-testing-lua-openwrtlede-c ase/ If you want to check past previous executions, you can check them here: https://travis-ci.org/libremesh/lime-packages Also we have a badge that indicates the health of the branch on the README: https://github.com/libremesh/lime-packages/blob/develop/README.md Hope this helps people get more involved on coding for LibreMesh! Regards,

7 years, 9 months

1
0
0 0

simple router resource monitoring/alerting

by Paul Spooren

Hello, deploying a weak router (like wr841) as gateway might be a bottleneck for the network. Would it be possible to generate simple monitoring/alerting solution for network performance affected parameters (load?). A possible alert could be via the routers LEDs (like blinking all at once rapidly) or triggering a slack-like webhook[1]? This could enable users to detect them selfs an overload and possibly upgrade to a better hardware. Best, Paul [1]: https://api.slack.com/incoming-webhooks

7 years, 10 months

2
1
0 0

We have Continuous Integration!

by Nicolas Pace

Hi Everyone, We have a first trial on having Continuous Integration for LiMe: https://github.com/libremesh/lime-packages/pull/186 https://travis-ci.org/libremesh/lime-packages It runs a build for each pull request and each commit in each pull request and each merge. If the build fails, it fails. If the build succeds... don't know, because now is failing :) This builds an x86 image so you can download an test fast using qemu. For that I need a server where to upload the image. If anyone can provide me with that, I can add that feature later. I think it would be great to also build ar71xx so we can test phisical things. Regards,

7 years, 10 months

4
5
0 0

hidden Mesh

by Paul Spooren

Hello, is it possible to hide the 802.11s mesh? It appears as an unencrypted mesh and may confuses users. Best, Paul

7 years, 10 months

3
6
0 0

lime-defaults "lime wifi" auto channel

by Paul Spooren

Hello, LEDE supports auto choosing the least used wifi channel. According to the lime-defaults [1] Libremesh defaults to channel 11 for 2.4GHz and 48 for 5GHz. Is a setting for "auto" possible in the "config lime wifi" section and if so, wouldn't that be a better default value? If not, wouldn't that be a very useful feature to avoid channel overloads when people flash the same image on dozens of routers? Best, Paul [1]: https://github.com/libremesh/lime-packages/blob/develop/packages/lime-syste…

7 years, 10 months

2
1
0 0

Re: [lime-dev] Building lime for Raspberry Pi

by Nicolas Pace

(Adding Axel cause it is a a BMX7 compilation error... sorry axel for sending you so many same emails) I'm trying to compile Libremesh for Raspberry pi 2. I had an issue with a diff file on ath9k (below). And now there is a BMX7 compile error. $ J=1 V=s ./cooker -b brcm2708/bcm2709 --flavor=lime_default -- profile=rpi-2 ... make[5]: Entering directory './lede/brcm2708/bcm2709/sdk/build_dir/target-arm_cortex-a7+neon- vfpv4_musl_eabi/bmx7-r2017011101' ccache_cc -pedantic -W -Wall -Wstrict-prototypes -Wno-unused- parameter -Os -g3 -std=gnu99 -DGIT_REV=\"589ee21b49d370056a24d8931d663626608f3c12\" -DAVL_5XLINKED -pedantic -W -Wall -Wstrict-prototypes -Wno-unused- parameter -Os -g3 -std=gnu99 -DGIT_REV=\"589ee21b49d370056a24d8931d663626608f3c12\" -DAVL_5XLINKED -Os -pipe -mcpu=cortex-a7 -mfpu=neon-vfpv4 -fno-caller- saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno- error=unused-result -mfloat-abi=hard -iremap./lede/brcm2708/bcm2709/sdk/build_dir/target-arm_cortex-a7+neon- vfpv4_musl_eabi/bmx7-r2017011101:bmx7-r2017011101 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,- z,now -Wl,-z,relro -fpic -I. -I./lede/brcm2708/bcm2709/sdk/staging_dir/target-arm_cortex-a7+neon- vfpv4_musl_eabi/usr/include -DCRYPTLIB=MBEDTLS_2_4_0 -DCORE_LIMIT=20000 -DTRAFFIC_DUMP -DNO_TRACE_FUNCTION_CALLS -DBMX7_LIB_IWINFO -c ip.c -o ip.o In file included from ./lede/brcm2708/bcm2709/sdk/staging_dir/toolchain-arm_cortex-a7+neon- vfpv4_gcc-5.4.0_musl_eabi/include/linux/if_tunnel.h:6:0, from ip.c:44: ./lede/brcm2708/bcm2709/sdk/staging_dir/toolchain-arm_cortex-a7+neon- vfpv4_gcc-5.4.0_musl_eabi/include/linux/ip.h:85:8: error: redefinition of 'struct iphdr' struct iphdr { ^ In file included from ip.c:41:0: ./lede/brcm2708/bcm2709/sdk/staging_dir/toolchain-arm_cortex-a7+neon- vfpv4_gcc-5.4.0_musl_eabi/include/netinet/ip.h:25:8: note: originally defined here struct iphdr { ^ ip.c: In function 'opt_dev': ip.c:3458:10: warning: unused variable 'TODO_use_proc_for_getting_parent_ifname' [-Wunused-variable] IDM_T TODO_use_proc_for_getting_parent_ifname; ^ Makefile:32: recipe for target 'ip.o' failed make[5]: *** [ip.o] Error 1 make[5]: Leaving directory './lede/brcm2708/bcm2709/sdk/build_dir/target-arm_cortex-a7+neon- vfpv4_musl_eabi/bmx7-r2017011101' Makefile:21: recipe for target 'all' failed make[4]: *** [all] Error 2 make[4]: Leaving directory './lede/brcm2708/bcm2709/sdk/build_dir/target-arm_cortex-a7+neon- vfpv4_musl_eabi/bmx7-r2017011101' Makefile:186: recipe for target './lede/brcm2708/bcm2709/sdk/build_dir/target-arm_cortex-a7+neon- vfpv4_musl_eabi/bmx7-r2017011101/.built' failed make[3]: *** [./lede/brcm2708/bcm2709/sdk/build_dir/target-arm_cortex- a7+neon-vfpv4_musl_eabi/bmx7-r2017011101/.built] Error 2 make[3]: Leaving directory './feeds/routing/bmx7' package/Makefile:109: recipe for target 'package/feeds/routing/bmx7/compile' failed make[2]: *** [package/feeds/routing/bmx7/compile] Error 2 make[2]: Leaving directory './lede/brcm2708/bcm2709/sdk' package/Makefile:105: recipe for target './lede/brcm2708/bcm2709/sdk/staging_dir/target-arm_cortex-a7+neon- vfpv4_musl_eabi/stamp/.package_compile' failed make[1]: *** [./lede/brcm2708/bcm2709/sdk/staging_dir/target- arm_cortex-a7+neon-vfpv4_musl_eabi/stamp/.package_compile] Error 2 make[1]: Leaving directory './lede/brcm2708/bcm2709/sdk' ./lede/brcm2708/bcm2709/sdk/include/toplevel.mk:200: recipe for target 'world' failed make: *** [world] Error 2 make: Leaving directory './lede/brcm2708/bcm2709/sdk' -> Error compiling SDK

7 years, 10 months

2
3
0 0

retrieve release information

by Paul Spooren

Hi, I'm trying to find a generic way to find the currently installed release. On standard LEDE I'm using `ubus call system board` and check the `release` section. On Libremesh a look at /etc/lime_release provides the information. Is it possible to modify the ubus output to give the same information as lime_release does? The most simple solution could be to modify the /etc/openwrt_release file. Thanks in advance! Best, Paul

7 years, 10 months

1
0
0 0

Domain for (beta) update server

by Paul Spooren

Hi all, I'm making some progress with my GSoC project [1] and need a secure https connection for a new feature. Would it be possible to create an A record of betaupdate.libremesh.org (or something similar) to 35.189.253.152? If you need more information please don't hesitate to write me! Best, Paul [1]: https://blog.freifunk.net/2017/06/26/attended-sysupgrade-status-report/

7 years, 10 months

2
2
0 0

doc - "Quick starting guide" translated in Italian

by ignifugo

HI! for the Ninux community I translated the page quickstartguide. https://github.com/libremesh/lime-web/pull/28 I had the switch between the languages only in that page. And in jekyll I did't found as change automatically the set lang in html tag.. but works.. :) see you soon Ignifugo

7 years, 10 months

2
2
0 0

UniFi AC Mesh Support

by Nicolas Pace

Hi guys, We are here with George from Sarantaporo testing this UniFi AC Mesh devices. We successfuly flashed two of them that are meshing with each other and with other devices through 2.4ghz and 5ghz with AC. The problem is that the throughput is not very good. Doing a netperf, we get (on the AC link): root@LiMe-3c5540:~# netperf -H fe80::f29f:c2ff:fe3e:5435%wlan0-mesh netperf -cCD1 -t tcp_maerts -l30MIGRATED TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to fe80::f29f:c2ff:fe3e:5435%wlan0-mesh () port 0 AF_INET6 : demoRecv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.06 55.41 and on the 802.11g link: root@LiMe-3c5540:~# netperf -H fe80::f29f:c2ff:fe3d:5435%wlan1-mesh netperf -cCD1 -t tcp_maerts -l30 MIGRATED TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to fe80::f29f:c2ff:fe3d:5435%wlan1-mesh () port 0 AF_INET6 : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 11.88 1.19 So... pretty crappy, isn't it? (the devices are 30cm away from each other, and no wireless traffic is around but those. Also, another thing called my atention. These are the luci wireless outputs for both of the devices. Isn't it strange that both of them have high reception speed and super slow transmission speed with each other? We have already tried changing the channels. Also tried to avoid 11s/adhoc and connect as client/master. The outcome is the same: root@LiMe-3c5540:~# netperf -H fe80::f29f:c2ff:fe3c:5435%wlan0-1 netperf -cCD1 -t tcp_maerts -l30MIGRATED TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to fe80::f29f:c2ff:fe3c:5435%wlan0-1 () port 0 AF_INET6 : demoRecv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.01 62.59 I haven't tried all this configs yet: https://wiki.openwrt.org/doc/uci/ wireless#ac_capabilities But maybe there is some knowlege in the group that can help on this. What do you think about this? Regards,

7 years, 10 months

3
2
0 0

Xiaomi Mi Wifi R3 Support help

by Nicolas Pace

Hi guys, George from Sarantoporo and I are trying to give support to a new device (yes, couldn't we start from something easier, right?). Could you give us some guidance on supporting a new device that apparently has only changed the Storage structure from the previous version. Unsupported new version: Xiaomi Mi Router 3: https://wiki.openwrt.org/toh/xiaomi/mir3#mtd_output_from_stock_firmware Supported old version: Xiaomi Mi Router Mini: https://wiki.openwrt.org/toh/xiaomi/mini#mtd_partitioning We have already collected all the relevant information in the Wiki What users in the forum were saying is that the 'only thing' that needs to change is the MTD definition, but I don't know how to do it. Any guidance? I have the devices in front of me and I'm open to brick them (they have a recovery partition method embedded so it is not a problem apparently) The problem is that there is no developer with one of them at hand... and I have it in front of me ... so why don't we try and have it supported? It is a very neat device (28 euros for a dual band, ufl- attached 3 antenna router with 128 storage, 64 ram, usb...) Any suggestion? Regards,

7 years, 10 months

1
0
0 0

repo.download.org EXTRA_IMAGE_NAME with flavor

by Paul Spooren

Hi all, currently images with different flavors look the same. ---/lime_mini/lede-17.01.2-libremesh-ar71xx-generic-tl-wdr3600-v1-squashfs-factory.bin /lime_default/lede-17.01.2-libremesh-ar71xx-generic-tl-wdr3600-v1-squashfs-factory.bin Would it be possible to use the EXTRA_IMAGE_NAME (already used to add "libremesh") to add the flavor as well? lede-17.01.2-libremesh-lime_default-ar71xx-generic-tl-wdr3600-v1-squashfs-factory.bin I think it wouldn't cause any split("-") troubles in scripts as the -v1- is already individual per profile. Best, Paul

7 years, 10 months

3
2
0 0

Libremesh Firmware for gl-inet AR150 router

by senthil kumar

Hi Libremesh Dev Team, I am Senthilkumar from India. This year Battlemesh V10 event. I heard about the Libremesh firmware and how it makes easy to create a mesh network on single flash. I really like the implementation and want to flash the Libremesh firmware in my existing community wireless nodes. I am using GL-INET AR150 routers for all my existing nodes. But I couldn't able to find the correct firmware for the https://wiki.openwrt.org/toh/gl-inet/gl-ar150 router. Can you please help me on finding the right firmware for this router. Looking forward to hear from you. -- Thanks and Regards, * • **Senthilkumar M* * • **Community Manager,* * • **Google Developer Group Madurai**,* *• **Mentor, Metoomentor.org* * • **Senior Research Engineer, Qualcomm. * * • allaboutsenthil.in <http://allaboutsenthil.in>* • +91 8095207092

7 years, 10 months

2
2
0 0

Re: [lime-dev] one-way ip6ip6 tunnels done right

by Axel Neumann

I tested the proposed approach and below patch again after updating my machine to ubuntu 16.04 with 4.8.0 kernel and there ip4-in-ip6 and ip6-in-6ip all just works out of the box. No need to configure ip6tnl0 tunnel in any mode. It seems enough that bmx6 already configures the bmxdefault tunnel device in any/ipv6 mode with a :: remote address. First packet of an icmp request sequence at the receiving side always pops out of the bmxdefault tunnel. Then, its reply triggers the creation of a dedicated bidirectional tunnel also at the receiving side which is used for following request and reply icmp packets. No fake ipv6 tunnel addresses are used anymore! To ensure backwards compatibility it should be checked how kernels in already deployed openwrt and Lede based lime version behave. cu /axel On 14.06.2017 07:30, Henning Rogge wrote: > On Wed, Jun 14, 2017 at 7:18 AM, Axel Neumann <neumann(a)cgws.de> wrote: >> I put a patch for bmx6 in this branch >> https://github.com/axn/bmx6/commits/master.NonFakeTunAddresses >> https://github.com/axn/bmx6/commit/5dc6678cf9c2887ca5e32c8d7527c5f660ddb7e9 >> >> But due to the current kernel behavior it does not acceppt ip4-in-ipv6 >> tunnelled packets if the remote tunnel address is not explicitly >> specified and matching with the incoming tunnel packet. For ip6-in-ip6 >> it works. >> >> The problem is addressed by below linked patches. But none of them seems >> to have been applied to current kernels. If somebody known or finds out >> an alternative solution would be great. >> >> /axel >> >> http://lists.openwall.net/netdev/2014/10/29/20 >> http://archive.linuxvirtualserver.org/cgi-bin/mesg.cgi?a=lvs-devel&i=53D75B… > > Maybe we should ask about these patches again on netdev? > > Current behavior is a bit inconsistent and stupid. > > Henning >

7 years, 11 months

1
0
0 0

the upcoming release

by Daniel Golle

Hi! I finally got to the point to test the results of running 802.11s on plain LEDE and want to switch to the upcoming LiMe release and help testing. As most of the folders on the release download server are still empty I liberated enough free space on my SSD to build the SDK and IB from scratch myself. The good part: Congratulations for switching to the IB+SDK and starting a more productive colaboration with the upstream projects! It's great to see that the Libremesh fishtank has finally poured into the open sea :) In the next week I'll be working on a test-deployment which will be based on the upcoming LiMe release and hence LEDE-17.01.2(-pre) on a Lantiq XRX200 device providing a VDSL gateway plus a bunch of ar71xx devices providing the mesh+APs. I hope that we can then annouce to have sucessfully overcome the boundaries of only using only one hardware platform. And make the switch to 11s (which I'll be using there as well) The rather sad part of the tour through the upcoming release was to find 'libusys' which was apparently pulled in by 'organge-rpc': Please take a look the code at https://github.com/mkschreder/libusys/tree/master/src Did you notice that this is someone trying to recycle Felix code' from 5 years ago? And never send a single message to the upstream mailing lists or ever tried to contribute just one line? Besides that, it's also sad in terms of making best use of our scarse flash and memory resources, because we already got everything which is there (uloop, ulog, ...) and need it anyway for procd, netifd, ... Now have a look and compare with the above: https://git.lede-project.org/?p=project/libubox.git https://git.lede-project.org/?p=project/ubox.git https://git.lede-project.org/?p=project/ustream-ssl.git (and some more) Why on earth include it again, in an outdated version?! To me it was quite shocking to see that you are using weird outdated stuff which is featured by an isolated one-man-show rather than participating in the much wider and public collaboration. If you really need websockets, why not attach them to uhttpd (I didn't quite understand why you need them in that context I must admit)? If you want a JSON-RPC, why not use uhttpd-mod-ubus? Anyway. It somehow happened. What's the plan and how to proceed with the lime-ui story? Maybe I'm just lacking information... Cheers Daniel

7 years, 11 months

2
10
0 0

one-way ip6ip6 tunnels done right

by Gui Iribarren

(Braindumping here, sorry for the lack of context) made two one-way tunnels: packets put into torreunc "foo" will be captured at nicojesigioia "fool" and viceversa, nicojesigioia "foo" -> torreunc "fool" but foo doesnt need any "fake" source address, the key is that "fool" is constructed using "remote ::", and it catches packets with destination equal to the "local 2001:db8::" address, but regardless of the source address i.e. ip -6 tun add fool local fd66:66:66:15:c24a:ff:fefc:6567 ### torreunc root@torreunc:~# ip a s foo 13076: foo@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1 link/tunnel6 2801:1e8::827a:4a00 peer fd66:66:66:13:c24a:ff:fefc:6566 inet6 fe80::fc21:acff:fe96:f61f/64 scope link valid_lft forever preferred_lft forever root@torreunc:~# ip a s fool 13281: fool@NONE: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1 link/tunnel6 fd66:66:66:8:62e3:27ff:fe4a:7a82 brd :: inet6 fe80::d893:19ff:fec4:3163/64 scope link valid_lft forever preferred_lft forever root@torreunc:~# ip r get 2801:1e8::827a:4a00 local 2801:1e8::827a:4a00 from :: dev lo table local proto none src 2801:1e8::827a:4a00 metric 0 pref medium ### nicojesigioia root@nicojesigioia:~# ip a s foo 2207: foo@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1350 qdisc noqueue state UNKNOWN group default qlen 1 link/tunnel6 2801:1e8:2::6565:fc00 peer fd66:66:66:8:62e3:27ff:fe4a:7a82 inet6 fe80::ec05:abff:fefe:54c9/64 scope link valid_lft forever preferred_lft forever root@nicojesigioia:~# ip a s fool 2380: fool@NONE: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1 link/tunnel6 fd66:66:66:13:c24a:ff:fefc:6566 brd :: inet6 fe80::b853:54ff:fe4a:3de5/64 scope link valid_lft forever preferred_lft forever root@nicojesigioia:~# ip r get 2801:1e8:2::6565:fc00 local 2801:1e8:2::6565:fc00 from :: dev lo table local proto none src 2801:1e8:2::6565:fc00 metric 0 pref medium This works, and I propose bmx6/7 sets up tunnels like this, without specifying a "peer" on the "receiving" tunnels, so that "sending" tunnels can use real ipv6 source addresses and ICMPv6 errors messages can be sent back successfully and not break PMTUD in case of MTU size changes as a reference, here's how current bmx6 sets up the equivalent of the "fool" interface, but specifying a "remote" (innecesarily) root@torreunc:~# ip a s bmxmain 16: bmxmain@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1460 qdisc noqueue state UNKNOWN group default qlen 1 link/tunnel6 fd66:66:66:8:62e3:27ff:fe4a:7a82 peer fd66:66:66:ff00:62e3:27ff:fe4a:7a82 inet 10.5.24.12/32 scope global bmxmain valid_lft forever preferred_lft forever inet6 2801:1e8::827a:4a00/128 scope global valid_lft forever preferred_lft forever inet6 fe80::ce:9cff:fe25:2c92/64 scope link valid_lft forever preferred_lft forever root@nicojesigioia:~# ip a s bmxmain 16: bmxmain@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1 link/tunnel6 fd66:66:66:a:c24a:ff:fefc:6565 peer fd66:66:66:ff00:c24a:ff:fefc:6565 inet 10.5.0.6/32 scope global bmxmain valid_lft forever preferred_lft forever inet6 2801:1e8:2::6565:fc00/128 scope global valid_lft forever preferred_lft forever inet6 fe80::f87c:4ff:fe19:ebde/64 scope link valid_lft forever preferred_lft forever and a corresponding equivalent 'foo' tunnel root@nicojesigioia:~# ip a s bmxOut_torreun 2391: bmxOut_torreun@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1358 qdisc noqueue state UNKNOWN group default qlen 1 link/tunnel6 fd66:66:66:ff00:62e3:27ff:fe4a:7a82 peer fd66:66:66:8:62e3:27ff:fe4a:7a82 inet 10.5.0.6/32 scope global bmxOut_torreun valid_lft forever preferred_lft forever inet6 2801:1e8:2::6565:fc00/128 scope global valid_lft forever preferred_lft forever inet6 fd66:66:66:ff00:62e3:27ff:fe4a:7a82/128 scope global deprecated valid_lft forever preferred_lft 0sec inet6 fe80::f005:3cff:fe4a:26d/64 scope link valid_lft forever preferred_lft forever

7 years, 11 months

2
1
0 0

Release candidate for BattleMesh

by Ilario Gelmetti

Hi all! We need a release candidate to be ready for testing at BattleMesh. I added to lime-packages repository on Github a "WBMv10-RC" milestone [1] and a "release-blocker" label [2] to use for prioritizing issues. Bye! Ilario [1] https://github.com/libremesh/lime-packages/milestone/1 [2] https://github.com/libremesh/lime-packages/labels/release-blocker

7 years, 11 months

3
5
0 0

Request to join Lime Development Team

by Muhammad Mubarak

I am Mubarak Dada, a computer programmer with more than 7 years experience coding and also a Bachelors of Engineering. I was fortunate to know about different Libre community products at the just concluded Africa Internet Summit and i will love to be join the development team. I code in C, C++, Python, Fortran and C#, i recently started learning lua. I have done several projects and worked on big data and artificial intelligence. I hope in making the lime associated components more intelligent and geek free if i am given the chance to work with the team. Thank you Kind Regards

7 years, 11 months

2
1
0 0

Request to Join Lime Development Team

by Muhammad Mubarak

I am Mubarak Dada, a computer programmer with more than 7 years experience coding. I was fortunate to know about different Libre community products at the just concluded Africa Internet Summit and i will love to be join the development team. I code in C, C++, Python, Fortran and C#, i recently started learning lua. I have done several projects and worked on big data and artificial intelligence. I hope in making the libre router and it's associated components more intelligent and geek free if i am given the chance to work with the team. Thank you Kind Regards Mubarak

7 years, 11 months

1
0
0 0

[LEDE-DEV] GSoC 2017 & RFC - Attended Sysupgrade

by Paul Spooren

Dear all, I'm Paul Spooren and applied for this years GSoC. My project is to build an attended sysupgrade to easily reflash routers on new releases. For more information please read my blog post here: https://blog.freifunk.net/2017/05/30/gsoc-2017-attended-sysupgrade/ Thanks in advance for all kind of feedback! Best, Paul Spooren

7 years, 11 months

2
1
0 0

Re: [lime-dev] [LEDE-DEV] Planning v17.01.2

by Daniel Golle

Hi Jo, On Wed, May 24, 2017 at 10:34:20PM +0200, Jo-Philipp Wich wrote: > Hi, > > I'd like to start preparing the v17.01.2 release during the upcoming > weekend with the goal to release final binaries within the next week > (~May 29th till June 3rd). > > Changes that shall be part of 17.01.2 should be merged until Sunday, the > 28th. > > You can find the current list of changes since v17.01.1 at > https://lede-project.org/releases/17.01/changelog-17.01.2 > > The most notable change is a security fix affecting the builtin dropbear > SSH server. While the default configuration does not appear to be > vulnerable, we still should provide updated images as soon as possible. > > > If you want specific fixes cherry-picked/backported to lede-17.01, > please mention them in a reply to this mail. I'd like to see commit ed62d91f4b5296a4aa883ce975d76f590ef4e910 from Nick Lowe hostapd: add legacy_rates option to disable 802.11b data rates commit 1a16cb9c67f0d2c530914aec31c721b75f03a908 from Matthias Schiffer mac80211, hostapd: always explicitly set beacon interval included as that fixes co-existence of AP+mesh interface combination which was previously broken. Cheers Daniel

7 years, 12 months

1
0
0 0

GSoC 2017 - Attended Sysupgrade

by Paul Spooren

Hello everyone, I'm Paul Spooren and I'll work on attended auto upgrades for LibreMesh (and Lede) this GSoC. Some personal information, I'm 24 years old and study computer science at the University of Leipzig. First I applied to work on captive portal login but after some discussion with my mentor(s) we decided to create an semi auto upgrade via the luci(-ng) fronted. The shortcomings of captive portals will be covered in my first blogpost. Once finished, the web interface will notify on new upgrades and the (to be created) update server will auto generate an image with all installed packages. This will simplify the update routine for all users, even with special setups where packages are required for Internet connection. The "image as a service" approach could also optimize the current chef.altermundi.net setup. What I've done last week: * setup the build environment and get to know the build process * "design" a requests model for the "image as a service" process What I plan to do next week: * setup a cache mechanism in the build scrips * check luci(-ng) sysupgrade process * write the blog post and create a timeline Regards, Paul Spooren

8 years

2
1
0 0

changelog for upcoming release

by Gui Iribarren

This is what we did so far (mostly during the hackaton, and a few things before and after) Changelog Dayboot Rely 17.04 (since 16.07) • based on LEDE 17.01.1 • build everything using LEDE SDK, via new lime-cooker (instead of lime-build) • lime-system: fix ieee80211s proto, correctly construct ifnames • lime-system: sanitize hostname (transform everything into alphanumeric and dash) • lime-system: new proto static • lime-system: set dnsmasq force=1 to ensure dnsmasq never bails out • lime-webui: enable i18n, finally webinterface is available in Spanish • lime-webui: Major rework by NicoPace, thanks! ∘ bmx6 node graph now uses colors in a clever way ∘ simple way to add "system notes" that are shown along with /etc/banner and webui ∘ luci-app-lime-location: fix google maps api key ∘ new read-only view: switch ports status ∘ alert luci-mod-admin users that their changes might get overwritten by lime-config ∘ fix batman-adv status webui • new package available to install lighttpd instead of uhttpd (needed for an upcoming android app) • added a lime-sysupgrade command: does a sysupgrade but only preserving libremesh configuration file • added a lime-apply command: basically calls reload_config, but also applies hostname system-wide without rebooting • lime-proto-anygw: unique mac based on ap_ssid (using %N1, %N2) • lime-proto-anygw: integrate better into /etc/config/dhcp instead of /etc/dnsmasq.d/ • lime-proto-batadv: set batadv gw_mode=client by default to counteract rogue DHCP servers • lime-proto-bmx6: introduce bmx6_pref_gw option, adds priority (x10) to a specific bmx6 gateway • bmx6: doesn't flood log with some spurious warnings anymore (syslog=0) • bmx6: sms plugin now enabled by default • bmx6: daemon is now supervised by procd, so it is restarted in case of crashes • bmx6: doesn't "configSync" by default anymore (no more "uci pending changes" because of auto-gw-mode) • new bmx6hosts tool: maintain an /etc/hosts that resolves fd66: <-> hostnames.mesh • safe-reboot: fix, use /overlay/upper instead of /overlay • safe-reboot: add "discard" action • ath9k: debugged some hangs (interface is deaf) and workaround it • alfred: fix bat-hosts facter, check for errors and don't nuke /etc/bat-hosts in case of failure • various Makefile dependency problems fixed pending for confirmation: (already done but waiting merge or testing) • don't tag bmx6 packets over ethernet and so use at least mtu=1500 everywhere • make 80211s work correctly

8 years

1
0
0 0

leipzig release hackathon

by Daniel Golle

hi! p4u mentioned that there is interest in a hackathon for the next libremesh release. at first i was sceptical whether this would be a good idea (because i just came back to leipzig myself and things weren't as comfortable as i was hoping). however i can now officially invite you because everybody here likes the idea. you will have choice between spaces with all sorts of possible test-deployments which will be thankful. one new and pretty large trailerspace now got VDSL with 50MBit/s and they need to distribute the available bandwidth in a quite large space and among quite a number of people. they also got a building on the which can host all of us and provide useful working space (electricity and, as i mentioned, bandwidth :) anyway: if this is desired, i'll need to know the exact timeframe and number of people to expect asap to go to the affected assemblies and reserve the space for us. it'd also be nice to put a mixed agenda which would also involve some talks and workshop with a general audience (think: people who might have heard about freifunk but have no idea about the details as well as folks interested in deployment skills and maybe even developers, but that'd definitely be a minority). and a decent release party :) let me know what you think! cheers daniel

8 years, 1 month

2
1
0 0

luci-Fwd: luci-mod-status (found at libremesh)

by Ufo

who could/should copy that package to luci? gui? what about other luci-related libremesh packages? ufo -------- Forwarded Message -------- Subject: luci-mod-status (found at libremesh) Date: Sat, 04 Mar 2017 19:34:52 +0100 From: ufo(a)rund.freifunk.net To: luci(a)lists.subsignal.org Using Libremesh Firmware makes me going crazy about such nice web-graphs inside their Luci. screenshot: https://twitter.com/Freifunk_L/status/747919909510852609 so now i was modifying at least their luci-mod-status package to makes it running on brandnew lede-1701-release, inside our freifunk firmware. Very cool! We are using it for Freifunk Mesh-Nodes but it also seems to be very useful for even "normal" Accesspoints or Wifi-Clients: STatus AND Wifi Details are shown in realtime, even without password. Thats the nicest way to wifi-tune the device: Moving it with a look at this graph and even installing long-range wifi-links is very easy to do. screenshot: https://twitter.com/Freifunk_L/status/837995052408451075 Wouldnt it be nice to include that package into normal luci-packages? Who should/could commit that? Best case, the programmer himself, gui!? There are some other useful packages too (batman-adv and bmx6 luci packages), how should we deal with that? screenshot bmx6: https://twitter.com/rundfreifunk/status/838014942246764544 greetings, ufo p.s. original code: https://github.com/libremesh/lime-packages my edits: https://github.com/freifunk-leipzig/lime-packages/tree/develop/packages/luc… you can try it: i was compiling and testing already (LEDE_1701_Release SDK for ath9k) opkg install http://firmware.leipzig.freifunk.net:8004/srv2/lede/lede-sdk-1701/bin/packa… opkg install http://firmware.leipzig.freifunk.net:8004/srv2/lede/lede-sdk-1701/bin/packa… opkg install http://firmware.leipzig.freifunk.net:8004/srv2/lede/lede-sdk-1701/bin/packa… i also have a dirty bash-script to convert arp-entries to /etc/bat-hosts on batman-adv-less . devices. so you can see ipv4 adresses instead of mac-adresses.

8 years, 1 month

1
0
0 0

Open discussion about IPv6 delegation prefix in LibreMesh

by Pau

Most of the discussion regarding this issue has been done on this pull request: https://github.com/libremesh/lime-packages/pull/71 I copy the last Daniel's statement from the lime-dev thread with subject "[lime-dev] downloads.libremesh.org being unavailable" to keep discussion from this point. > Do we have a consensus with regarding minPrefixLen, maxPrefixLen and > using whether watchping should add/remove a route to 2000::/3 or ::/0? > To me it looked like we concluded to make the naming consistent with > the rest of lime ('publicv6') and use 2000::/3. Yes, if there are not voices against it my vote is to use 2000::/3 instead of ::/0 for the Internet announcement. But as commented on the pull-request limr-proto-bmx6 and lime-proto-bmx7 must be modified according this change ([1]). Also this must be implemented to avoid problems with RFC6877: >so we should probably have several watchping sections testing for >them. Ie. pinging a well-known IPv6-mapped IPv4 address and setting up >explicit tunIn for them. > But the prefix length > was still an ongoing debate and I'm also less flexible there, simply > because I cannot test things with maxPrefixLen >= 64 because all > ARPAnet gateways I have access to only got a single /64 and hence > should not delegate anything shorter than a /72 (ie. max 255 clouds > using that gateway). Thus it's impossible for me to actually test any > setup which involves shorter prefixes. In any case we need a DHCPv6 server which allows the delegation of prefixes smaller than /64. Current dnsmasq does not but we might patch it. Using odhcpd means that we have to implement also the dnsmasq-share-leases stuff into it. @Gui is our dnsmasq guy, let's see what we says. > Also note that the counterpart, the needed changes on the client-side > to make bmx6/7 automatically choose the right prefix and address is > still missing afaik and I don't have time to implement that right now. We might try to involve @axn to this. > Anyway. Let me know what to do, I'll do it, so we can move on :) Great. [1] https://github.com/libremesh/lime-packages/blob/develop/packages/lime-proto… -- ./p4u

8 years, 1 month

3
3
0 0

Re: [lime-dev] bmx6 logging excesively

by Axel Neumann

Thanks for the feedback. On 21.03.2017 03:00, Gui Iribarren wrote: > Hey Axel, > we're having a flood of these messages in logread, > around 10 per minute, which is quite annoying > > Tue Mar 21 01:55:52 2017 daemon.err bmx6[5530]: INFO > create_ogm_aggregation(): IID jump 2 from 432 to 539 Ack, that is annoying. But not harmful. Its probably because you have many nodes changing their description frequently. How many nodes does your network have more or less? And does it appear only as "IID jump 2..." or also as "IID jump 3 and more...? > > they are being logged regardless of dbgMuteTimeout=10000 > or dbgMuteTimeout=1 or whatever setting > > how exactly does --dbgMuteTimeout work? It mutes messages that are logged with dbgf_mute() function after having appeared twice for the amount of ms you specified with --dbgMuteTimeout. The log message you complain about was not logged with the dbgf_mute() function and was therefore always logged. > > and how can we prevent those messages from showing up in the logs? You could only change the code, or update to the latest bmx6 master-branch version. It contains below patch :-) https://github.com/axn/bmx6/commit/4016a1980d900309771e432d1f7c741d6c48d477 cheers too /axel > > cheers!! >

8 years, 1 month

2
4
0 0

RFC: warn non existent default opt access

by Gio

I have been thinking about the unexpected behavior made evident by modifications in the branch reproducible_config Look at line 5 of this paste for an example of misbehavior http://pastebin.com/deGbPvmB I have been investigating for what can be causing it and discovered we are accessing configurations that are not declared in our default file, so I have added a couple of them that were obviously missing and added some code to avoid insurgence of this again in the future So please test 568ffd9b80a8aec053ae3ff16c6f5ff1647d17bd and feedback ;) Cheers!

8 years, 1 month

2
5
0 0

Comment on 7a563f581eebc78af821438fb087741f39b305a3

by Gio

This commit enable bmx6 sms plugin by default do we need to depend on some package to have it in our images, or bmx6 does ship all plugins by default? Cheers!

8 years, 1 month

2
1
0 0

Changing from Ad-Hoc to 802.11s on next release 17.02

by Pau

From long time ago LibreMesh supports 802.11s as link layer protocol for the WiFi/mesh connections (with deactivated HWMP, the routing layer). Traditionally we have been using Ad-Hoc (IBSS) for linking the nodes but it is old and broken on most of the current WiFi drivers. 802.11s has some advantages like: * easy setup (just mode=mesh) * several 802.11s virtual devices supported in a single WiFi interface * supports encryption * it has power saving support, so better for mobile devices * better and more driver support So as already discussed on some other mailing thread, I propose to use it by default instead of IBSS on the next LibreMesh release. Of course it will break the compatibility with older releases. But IMHO it is better now than in the future, in any case we will probably have to do it soon or later. In addition anyone who want can use IBSS instead, can use Chef or lime-build to generate an image firmware. It is as easy as adding "list proto adhoc" into /etc/config/lime-defaults. Please, speak up. Silent will be considered acceptance :) Cheers. -- ./p4u

8 years, 2 months

4
6
0 0

Fwd: GSoC Mentors Mailinglist

by Ilario

---------- Forwarded message ---------- From: Andreas Bräu <ab(a)andi95.de> Date: 2017-03-06 16:49 GMT+01:00 Subject: [Battlemesh] GSoC Mentors Mailinglist To: battlemesh(a)ml.ninux.org Hi there, I recently published a blog post for GSoC 2017 at https://blog.freifunk.net/2017/03/05/gsoc-2017-and-freifunk-students-wanted/ Hopefully this answers some questions to interested students, feel free to share :) Our next step is to invite you as possible mentors to the GSoC Dashboard and to our mentors mailing list. Can you please send me your email address you wish to be registered there? After having you on the mailing list it will be easier to distribute information, instead of writing to a bunch of different mailing lists :) We also need it to discuss proposals later on. The org admins you can contact via gsoc-org-admins(a)freifunk.net Best regards, Andi _______________________________________________ Battlemesh mailing list Battlemesh(a)ml.ninux.org http://ml.ninux.org/mailman/listinfo/battlemesh

8 years, 2 months

4
3
0 0

LiMe on LEDE 17.01 or rather LiMe-NG?

by Daniel Golle

Hi! Good to see that lime is still alive after all. I thought about some things which need to be taken care of and would like to get some feedback and opinions: * wouldn't it be great to finally use LEDE's SDK + ImageBuilder instead of lime-build (which is hard to maintain)? LEDE does rolling-release for packages and promissed regular maintainace cycle for their releases. 17.01 just came out, 17.01.0 is already in the pipe, 17.01.1 will come in May/June, and so on. suggestion: drop lime-build in favour of using the lime-packages feed with the SDK to provide packages to be used with the ImageBuilder. If there is any real reason to fork LEDE and/or use custom builds, please speak up, I'll be your advocate on board of the LEDE team to resolve those issues. * lime-config currently re-writes UCI configuration. ie. if I mess up /etc/config/network, running lime-config will not necessarily fix it. There are also situations which make re-running lime-config impossible as that would break the config completely. To resolve that mess I suggest to refrain from re-writing UCI configuration and rather generate it from scratch every time by using the new /bin/config_generate script. If anything is missing in that new board-config aka. uci-defaults approach, then we should add it and discuss with upstream, ie. make sure that all board-specific details needed to generate the entire configuration are covered. Hence I'd like to re-write lime-config from scratch. And maybe use Shell instead of Lua. I know, this may sound terrible, but I'm sure it'd be a great step towards reusability of the code for other projects (which may not use all the rest of LiMe, maybe not even use Lua at all) and also make the lime firmware more robust and cover more use-cases (such as re-configuring images on the go rather than using CHEF or imagine changing things in the field using some remote mass-management tools, I'm thinking of OpenWISP) * speaking about CHEF: what's happening on that scene? I find CHEF very complicated, but I'm not a web guy :( I saw it finally found someone willing to maintain it. Is there a roadmap or something? And how can people contribute documentation, localization and all that? And will it move to github? * hardware support: I think we should support more hardware targets, not just ar71xx, x86 and mt7621 (I do appreciate that mt7621 made it to the current release!). I'm working a lot on MT7620 lately, there are a terrible lot of devices out there and though this chip (or driver...) does not allow combining Ad-Hoc + AP, it apparently does allow combining 802.11s + AP! suggested additional hardware platforms, in random order, high- priotity is marked with an '!': !mvebu, !ramips/rt305x, ramips/rt3883, !ramips/mt7620, !ramips/mt7628, !ramips/mt7688, !ipq806x, !lantiq/xrx200, !lantiq/xway, octeon, !x86/generic, x86/geode, !x86/64, arm64, armvirt, sunxi, mediatek, brcm2708/bcm2708, brcm2708/bcm2709, brcm2708/bcm2710 (ie. all up-to-date platforms with good support in LEDE) I don't know enough about the bcm53xx, brcm47xx and brcm63xx targets to tell if any of those could be useful, but most likely they can, especially those with brcmsmac or brcmfmac wifi. For all others, especially those marked to be high-priority in the list above, I'm more than willing to help and contribute whatever is needed to get going. * speaking about 802.11s: should we switch to use the 802.11s MAC by default? Ad-Hoc/IBSS has many known problems and nobody among the people hacking the drivers seems to really care about it as it's broken by design... Cheers Daniel

8 years, 2 months

2
3
0 0

downloads.libremesh.org being unavailable

by Daniel Golle

Hi! All download and snapshot build sites are down: chef.altermundi.net doesn't offer downloads without registering first builds.libremesh.org and downloads.libremesh.org both point to some parking site rather than allowing to download anything. lime-build fails due to chaoscalmer not building due to unavailable openwrt.org resources. It's kinda hard to promote the use of libremesh in this situation. How can we improve this situation? Cheers Daniel

8 years, 2 months

2
6
0 0

Re: [lime-dev] TODO and Pad for LiMeCat2017q1

by Ilario

2017-03-04 13:15 GMT+01:00 Ilario Gelmetti <iochesonome(a)gmail.com>: > Here you are: > https://pad.eigenlab.org/p/LiMeCat2017q1 I copy and paste the pad sorted by assigned person, there are many easy tasks if you want to go for them :) (sorry for cross posting) =================== Whoever can do this ------------------- == Improve online documentation == Fill the gaps in the quick starting guide and add examples of common configs (e.g. 1 port router, set the port as WAN) Add link to Italian translation (NinuxBO) Complete the big tested hardware table http://libremesh.org/docs/hardware/index.html == Test LibreNet6 into LibreMesh and produce documentation on the process == This can be useful for GSoC project on LibreNet6 implementation in LibreMesh https://wiki.freifunk.net/Ideas#LibreMesh_LibreNet6_integration There are users trying it: https://lists.libremesh.org/pipermail/lime-users/2017-March/000400.html Gui and Nico are needed for deciding criteria for delivering /64 from LibreNet6 == WPA access point for clients and for backbone == Thread: https://lists.libremesh.org/pipermail/lime-users/2017-January/000325.html GSoC idea: https://wiki.freifunk.net/Ideas#LibreMesh_WPA2_and_802.11s_mesh_encryption_… It is already supported for AP and client, just we need to document it. == Advertisement of student positions in GSoC program == If we don't advertise it and we're not present in IRC channel for answering them, we'll have just a few students General mailing list for Freifunk's GSoC: http://lists.freifunk.net/mailman/listinfo/wlanware-freifunk.net hackmeeting-es (Ilario) hackmeeting-it (???) guifi-users (Al) hacklab Dontpanic (Al, Gio) eigenLab (Ilario) retroshare forums (Gio) student application period: March 20th - April 3rd suggesting to contact via lime-users list (our presence in IRC is quite scarce) == Use Gio's thesis for lime-web == adapt contents and insert them in lime-web and fix link to the thesis s/~gioacchino/~gio/ in lime-web ===================================================== Whoever can do this but I will do if no one else does ----------------------------------------------------- == Improve offline documentation == Add a reminder for "lime-config" command in the header of the configuration files == lime-build: mt7621 not an available target == just add that target in the available targets in targets.mk https://github.com/libremesh/lime-build/issues/15 This has already been fixed by Pau in f92c2d5 in develop but that commit is not present in branch 17.02 Do a new PR adding just this, ask for merge in 17.02 == lime-build: make bin-clean == A make option for deleting binary images in build/src/bin directory can be useful and should be part of the make process for avoiding confusion: https://lists.libremesh.org/pipermail/lime-users/2017-February/000373.html make clean is not the same as deletes a lot of stuff that has to be compiled again == Add spaces and client_encryption 'psk' to lime-example == https://github.com/libremesh/lime-packages/blob/develop/packages/lime-syste… == lime-build: specify profile in make menuconfig in readme == https://lists.libremesh.org/pipermail/lime-users/2017-February/000371.html == lime-build: Avoid error from make if targets/*.kernel is absent for the current target == https://lists.libremesh.org/pipermail/lime-users/2017-February/000389.html Decision: put an IF before the cp statement ============= I can do this ------------- == Update and reopen lime-example update PR == https://github.com/libremesh/lime-packages/pull/67 ================ Devs can do this ---------------- == Add an option for customizing DHCP range == https://github.com/libremesh/lime-packages/issues/33 https://lists.libremesh.org/pipermail/lime-users/2017-February/000377.html https://lists.libremesh.org/pipermail/lime-dev/2017-February/000842.html == Merge and close PR on IPv6 GW detection == https://github.com/libremesh/lime-packages/pull/71 == Check compatibility with new versions of LuCI == Verify the PR and check for other similar issues https://github.com/libremesh/lime-packages/issues/73 == luci-app-batman-adv and Alfred: a 3 years old problem, still open == https://github.com/libremesh/lime-packages/issues/1 confirmed is still an issue, maybe not needed because the web interface will be rewritten https://github.com/libremesh/lime-packages/blob/develop/packages/luci-app-b… https://github.com/libremesh/lime-packages/blob/develop/packages/luci-app-b… == lime-webui-ng will be included in 17.02? == Pau? Unitl when it does not work should be moved in a specific branch, not in develop as now is. https://github.com/libremesh/lime-packages/tree/develop/packages/lime-basic… == lime-build: Document how to add new hardware targets == Up to now just Pau did it Split specific taget lines from generic lime configs in targets/* files and move these ones to an unique file. == Redirect libre-mesh.org to libremesh.org == And check on the internet where we can fix it https://www.google.es/search?q=%22libre-mesh%22+-site:libre-mesh.org Gui should do this == Update or close repository on GitLab == Having an out of date version there is not good https://gitlab.com/libre-mesh/lime-packages Decision: we will set up syncronization Gio should do this == Update or close repositories on GitHub == We have a lot, that looks like a ugly list https://github.com/libremesh openwrt-oldpackages could be useful for someone compiling 15.09, shall we keep it? Yes, add comments in the repo description https://github.com/libremesh/openwrt-oldpackages lime-field-tools, nicoechaniz... are we using it or updating it or something? https://github.com/libremesh/lime-field-tools an old presentation on LibreMesh, we could make a repo for graphics and move it there, adding logos etc. Or can be moved in lime-web but should be updated. https://github.com/libremesh/libre-mesh-tecnical-presentation-1h-reveal.js libremap moved to its own user 3 years ago, so the repo in our organization is not useful. Delete it. https://github.com/libremesh/libremap ruci is an old script from Gui, let's ask him https://github.com/libremesh/ruci FFT_eval should be needed https://github.com/libremesh/FFT_eval another old presentation, see the previous comment https://github.com/libremesh/libremap-talk-2013-is4cwn super old repo superseeded by libremap https://github.com/libremesh/altermap ask Pau if we can delete this https://github.com/libremesh/dhcpdiscover let's remove this https://github.com/libremesh/demeshtify Devs should confirm we can delete these == Test and document how to use nodogsplash with LibreMesh == During last LiMeCat2016q3 we decided to not include nodogsplash in LibreMesh, but some GSoC projects go in that direction. https://wiki.freifunk.net/Ideas#LibreMesh_Captive_Portal_and_Access_Control Also nodogsplash is something which users ask for: https://lists.libremesh.org/pipermail/lime-users/2016-December/000287.html We need Gui for this. == Verify users reports == === Hostnames propagation === https://lists.libremesh.org/pipermail/lime-users/2016-November/000223.html === Strange errors === This happened long time ago, likely it's solved: https://lists.libremesh.org/pipermail/lime-users/2016-October/000197.html === Publishing on the website a guide for captive portal and coupon sharing? === https://lists.libremesh.org/pipermail/lime-users/2017-January/000317.html === Speed and latency issues === https://lists.libremesh.org/pipermail/lime-users/2017-February/000374.html === Mysterious /8 route in BMX6 === https://lists.libremesh.org/pipermail/lime-dev/2016-October/000787.html info in p.s., not in the main email body not an error, means accept routes in this range === trap in bmx6-auto-gw-mode logic === https://lists.libremesh.org/pipermail/lime-dev/2016-November/000797.html we can fix adding uci commit at the end of each watchping check === not existing luci-i18n-english === https://lists.libremesh.org/pipermail/lime-dev/2016-December/000818.html === Libremesh & qMp don't ping with same BMX6 revision === https://lists.libremesh.org/pipermail/lime-dev/2017-February/000837.html == No watchping, no pingcheck, better a wget == meh meh meh?? == lime-build: Need an alert for non existent profile == It affected an user here: https://lists.libremesh.org/pipermail/lime-users/2017-February/000389.html The issue is equivalent to this but for profile: https://github.com/libremesh/lime-build/issues/1 confirmed to do == Chef should ask for a root user password to be included in cooked firmware == For avoiding attacks while the password is still not set https://lists.libremesh.org/pipermail/lime-dev/2017-January/000827.html Chef could leak cleartext password, Chef should make the hash itself. == Discuss how a testbed for Battlemesh can be obtained from LiMe == Directions to forward to the student who will work on this GSoC idea https://wiki.freifunk.net/Ideas#LibreMesh_based_Battle_Mesh_testbed lime-proto-babel lime-proto-*** ask Nemesis for how they did the alternative WBM firmware == Develop a test suite with qemu or similar == We need to test the new commits against a few sample configurations and check that everything continues working. As doing this with real devices would be hard, something virtual would be accessible. Decision: much more useful to make something with real hardware, but needs to be able to reset to previous firmware. So we will never do it this way. So... Which virtual machines platform we can use for this? ================================================== Devs can do this but I will do if no one else does -------------------------------------------------- == Remove luci-mod-lime-basic == https://github.com/libremesh/lime-packages/issues/72 == Complete and test lime-proto-client == https://github.com/libremesh/lime-packages/issues/47 For now the network "wan" is hardcoded, it should be possible to use it for lan also When we have it for lan, we will have to test a non-mesh network (backbone made by AP-sta links) prio Remove args["network"] = "wan" for avoiding lime-proto-wan dependency of lime-system == lime-build: close an old PR - build sdk for all profiles == either completing it or refusing it https://github.com/libremesh/lime-build/pull/8 == lime-build: Re-add bmx7olsr1 profile to PROFILES_AVAILABLE == https://github.com/libremesh/lime-build/commit/f92c2d5354a62518435823153df2… Pau deleted this by error == Start using projects or labels and milestones for issues on Github == lables can indicate easy-to-address bugs for newbies we can transfer on github the majority of the issues listed in this document or include them as tasks in "projects" in Github Decision: yes for labels == Add topics to lime-packages repository for imrpoving visibility == As we're on Github, let's take advance for having a bit of visibility https://github.com/blog/2309-introducing-topics Decision: yes == Change link to old PabloCastellano repo in alterchef repo == https://github.com/libremesh/alterchef/blob/master/README.md And add description ============================= Completed tasks and decisions ----------------------------- == Discuss if "lime-config" could be inserted in LEDE init == This could broke custom configurations but avoids the common mistake of forgetting lime-config Decision: no. == lime-build: Discuss if we need a profile with 802.11s configured as default == This way it would be easier for the users to build a 802.11s based mesh. Decision: we will have just 802.11s https://github.com/libremesh/lime-web/commit/0d147690bb1a0a97f8c301dfcbe1ed… == Change BSSID and VLAN ID of BMX6 for compatibility with QMP == As we will broke compatibility with 802.11s, we can rediscuss other things like BSSID and VLAN ID of BMX6, we can change these for making easier the interoperability with QMP. For wireless link the same BSSID is not enough as QMP uses ad-hoc and we will use 802.11s Decision: yes In qMp default BSSID: 02:CA:FF:EE:BA:BE default VLANID: 12 == General switch to 802.11s for link layer? == ad-hoc seems to have a poor support by widely used drivers, 802.11s seems better (e.g. https://lists.libremesh.org/pipermail/lime-users/2017-January/000318.html ) The later the more painful will be the change. In LiMeCat2016q3 the change was decided for the next release, which is the 17.02 (cfr the pad of LiMeCat2016q3 https://pad.eigenlab.org/p/LiMeCat2016q3 ) Decision: confirmed, we need testing. We won't have back-compatibility. Network who will stick to ad-hoc will have to keep 16.07. Or configuring 17.02 with ad-hoc in Chef or post-flashing. Can cause problems. Decision: we need a super easy way in the webui for switching from 802.11s to ad-hoc == Plan deployment of LibreNet6 configuration helper webpage == In "mid-2017", similar to vpn.qmp.cat https://lists.libremesh.org/pipermail/lime-users/2016-November/000204.html Decision: WTF? Centralizing TINC configuration on a server? No.

8 years, 2 months

1
0
0 0

Libremesh & qMp don't ping with same BMX6 revision

by al

Hi from Barcelona Hacklab. In order to mount new nodes with Libremesh in places where exist networks with qMp and Libremesh we tested with two Nanostation M5 with same revision of BMX6: BMX6-0.1-alpha comPatibility=16 revision=2a87b770d3f9c254e3927dc159e2f425f2e0e83a this is the default BMX6 in each stable release (Libremesh stable and qMp Clereance 3.2.1) For replicate the issue: Working on same test channel (48) with same VLAN (default qMp 12) we got good link and we can see BMX6 routes from each other, but we can't ping each other. Any ideas? Thanks!

8 years, 2 months

2
8
0 0

OpenWisp GSoC ideas

by Gio

Openwisp mentoring organization said to me that we are welcome toput lime ideas on openwisp ideas page too, and in case have some slot from them Cheers!

8 years, 2 months

1
0
0 0

LiMeCat2017q1 and q2

by Ilario Gelmetti

Let's organize a couple of meetings for getting this 17.02 release done! I suggest to meet one weekend as soon as possible and another one in April. Here you are the website for expressing your availability (this time the results will be hidden, for the sake of participants' privacy): https://framadate.org/LiMeCat2017q1q2 The venue will be in Valldoreix (Bcn), not yet exactly defined. See you! Ilario

8 years, 2 months

1
1
0 0

Re: [lime-dev] [lime-users] Fwd: LEDE v17.01.0 final

by Ilario

2017-02-24 12:08 GMT+01:00 Juergen Kimmel <juergenkimmel(a)gmail.com>: > So I started as well compiling for ZBT APE522ii using menuconfig which > failed. > > At the very beginning I noticed: > "Adding profile packages: lime-full cp: Aufruf von stat für > 'targets/ar71xx.kernel' nicht möglich: Datei oder Verzeichnis nicht gefunden This is normal (maybe there should be a check and not an error? Should be easy to fix, anyone?) in English (for pasting output for debug please use English, prepend "LANG=C " at the beginning of the command line for changing language) I get: cp: cannot stat 'targets/ar71xx.kernel': No such file or directory this means that the profile you're using doesn't have any specific configuration for kernel. For example ar71xx-mini does have one. > Then I tried: > osboxes@osboxes:~/lime-build-17.02$ make T=mt7620 P=ape522ii UPDATE=1 J=1 > Profile of APE522ii is missing? There's no such profile I think... You can use make info for listing the profiles, you may use the profile "generic". The image for APE522ii should be built for the target you selected. > So why branch=develop? Uh! There's no branch "17.02" in lime-packages, at a certain point (now?) we will need to create that first (devs...?) and then change this line: https://github.com/libremesh/lime-build/blob/17.02/config.mk#L7

8 years, 2 months

1
0
0 0

Fwd: LEDE v17.01.0 final

by Ilario

Now we can start working on LibreMesh 17.03 :D From: Jo-Philipp Wich <jo(a)mein.io> To: LEDE Development List <lede-dev(a)lists.infradead.org> Subject: [LEDE-DEV] LEDE v17.01.0 final Hi, The LEDE Community is proud to announce the first stable version of the LEDE 17.01 version series. LEDE 17.01.0 "Reboot" incorporates thousands of commits over the last nine months of effort. With this release, the LEDE development team closes out an intense effort to modernize many parts of OpenWrt and incorporate many new modules, packages, and technologies. --- Some selected highlights of this release are: * Linux kernel updated to version 4.4.50 (from 3.18 in Chaos Calmer) * Update of essential software: * dnsmasq updated to 2.76 (from 2.73 in Chaos Calmer) * busybox updated to 1.25.1 (from 1.23.2 in Chaos Calmer) * mbedtls version 2.4.0 (from polarssl 1.3.14 in Chaos Calmer) * openssl updated to 1.0.2k * Improved Security Features * Use SHA256 instead of MD5 to validate source code for packages * mbedtls: disable SSLv3 support * OpenSSL: disable support for compression, heartbeats, NPN, Whirlpool, and J-PAKE * Memory Corruption Mitigation Methods * gcc -Wformat -Wformat-security * User space Stack-Smashing Protection (Regular) * Kernel space Stack-Smashing Protection (Regular) * buffer-overflows detection (FORTIFY_SOURCE) (Conservative) * RELRO protection (Full) * Improved Networking Support * Smart Queue Management (SQM) minimizes bufferbloat by using the cake and fq_codel qdisc's. * Improvements to the WiFi stack eliminating bufferbloat on ath9k, mt76 and some ath10k chipsets * Airtime fairness scheduler for ath9k to prevent slow stations from hogging too much airtime * Various stability and regression fixes to the Linux wireless stack and ath9k in particular * Provide alternative Candela-Tech ath10k-ct driver * IPv6 hardening * Updated toolchain * musl 1.1.16 * gcc 5.4.0 * binutils 2.25.1 * Platform and Driver Support * Lantiq * Added redistributable DSL firmware * Updated DSL phy drivers * Added new targets: * apm821xx (AppliedMicro APM821xx) * arc770 (Synopsys DesignWare ARC 770D) * archs38 (Synopsys DesignWare ARC HS38) * armvirt (QEMU ARM Virtual Machine) * ipq806x (Qualcomm Atheros IPQ806X) * layerscape (NXP Layerscape) * zynq (Xilinx Zynq 7000 SoCs) * Reorganized x86 target: * Drop dedicated Xen DomU target, merged with x86/generic * Enable AES-NI support * Removed targets: * realview, replaced by armvirt * ppc44x, disabled due to code brokeness * netlogic, dropped due to no available hardware * Build system improvements * Separation of base system and community feeds to simplify distribution of binary package updates * Fixes and enhancements in package dependency handling, better support for virtual provides * Per-device rootfs images to better tune package selection to each individual device profile * New image build code improving compilation times and simplifying device profile declarations * New package/.../check make target to run a series of standard diagnostics on Makefiles * Support for fetching sources using Curl * Generate reproducible source tarballs when packing SCM checkouts * Image Builder / SDK * Rework library bundling to allow for better portability between different Linux distributions * Add support for building kernel modules using the SDK * Added support for a many new routers and boards For a detailed list of changes since 17.01.0-rc2 refer to https://lede-project.org/releases/17.01/changelog-17.01.0-final For a complete list of changes since the start of the LEDE project, see https://lede-project.org/releases/17.01/changelog-17.01.0 --- Known issues: * Available space on devices with only 4MB flash is very low, users requiring extra packages might want to consider using the image builder to repack custom images * The available memory on devices with 32MB RAM might be too low to reliably run opkg or sysupgrade operations, especially in conjunction with LuCI * Any outstanding issues reported at https://bugs.lede-project.org/ --- For latest information about the 17.01 series, refer to the wiki at: https://lede-project.org/releases/17.01/ To download the v17.01.0 images, navigate to: https://downloads.lede-project.org/releases/17.01.0/ --- A big thank you goes to all our active package maintainers, testers, documenters and supporters. Have fun! The LEDE Community

8 years, 2 months

2
1
0 0

DHCP range in anygw [was: [lime-users] VPN]

by Ilario

Hi devs! In lime-users mailing list Nicolas asked how to change the IPv4 DHCP server range in LiMe. I realized that there's no way to do it. Anygw configures dnsmasq to use the whole broadcast domain as DHCP range. Here is where this happens: https://github.com/libremesh/lime-packages/commit/3a6596d50b3c0446b988f84d3… In theory there should be no problem as there should be a check for the availability of the IP (by the DHCP server or client?), anyway I think we should fix this. Should we add a new option in /etc/config/lime? Or use the values from /etc/config/dhcp? 2017-02-14 1:43 GMT+01:00 Ilario <iochesonome(a)gmail.com>: >> We give APs static addresses of 10.13.64.1, 2, 3, and so on. They must all >> be different. Try and stay out of the DHCP range which starts at 100 I >> think. > > A very interesting question. There's no option for DHCP range in > /etc/config/lime* files (and this is ok). > But I supposed that the range was defined in /etc/config/dhcp, which > on LibreMesh is identical than on OpenWrt/LEDE and contains: > # cat /etc/config/dhcp > [...] > config dhcp 'lan' > option interface 'lan' > option start '100' > option limit '150' > option leasetime '1h' > > But trying to ask for a DHCP lease I received an IPv4 out of the > 10.x.x.100-250 range, looking around I found that the DHCP range for > anygw is hardcoded: > https://github.com/libremesh/lime-packages/commit/3a6596d50b3c0446b988f84d3… > resulting in the whole subnet... No good. @devs?

8 years, 2 months

1
0
0 0

Fwd: [Battlemesh] A call for papers on DIY networking

by Pau

I thin the LiMe network architecture is a topic that may fit into a research paper. Maybe this workshop would be a nice place to send it. Is there someone here able working on the academa and able to participate on this? I might participate but not as a first author. Cheers. -------- Missatge Original -------- De: Leonardo Maccari <mail(a)leonardo.ma> Enviat: 14 de febrer de 2017 15:53:22 GMT-03:00 A: battlemesh <battlemesh(a)ml.ninux.org> Assumpte: [Battlemesh] A call for papers on DIY networking Hi battlemeshers, for those of you that work in (conjunction with) the academia, but also for those that can afford a scientific conference, there is this nice workshop we are setting up, the week right after the battlemesh. http://diynetworking.net/ifipnetworking2017/ The theme of the workshop is exactly what we do in community networks, so, along technical papers we also welcome non strictly technical contributions to understand what is needed to empower people to make "the Internet": experiences, architectures, incentives, governance, success or failure cases are very useful, because normally these things remain under the surface. The full CFP is below, and the website of the main conference is here with all the details: http://networking.ifip.org/2017/ I hope to see papers coming from some of the people of the BM community. leonardo. CFP: IFIP Networking 2017 - Interdisciplinary Workshop on DIY and Community Networking, Stockholm, Sweeden --------------------------------------------------------------------------- Our apologies if you received multiple copies of this CFP --------------------------------------------------------------------------- CALL FOR PAPERS IFIP Networking 2017 Interdisciplinary Workshop on DIY and Community Networking Place: Stockholm, Sweden Date: June 12, 2017 http://diynetworking.net/ifipnetworking2017/ Important Dates Abstract submission: March 20, 2017 Full paper: March 30, 2017 Notification of acceptance: April 10, 2017 Camera-ready papers due: April 27, 2017 DIY networking Workshop: June 12, 2017 Submission guidelines http://diynetworking.net/ifipnetworking2017/submission.php --------- Scope: This workshop is a joint venture of three EU Horizon2020 projects, MAZI, netCommons, and RIFE, in an effort to join forces around the design and use of DIY and community networking technologies for the common good, using a highly interdisciplinary and transdisciplinary approach. With DIY and community networking we refer to a diverse set of networking technologies that range from large-scale community networks to small scale wireless installations supporting local applications accessible only to those residing in the coverage area of the network. DIY and community networking represent two frontier research themes that can open new and exciting research and application areas. On the one hand, the locality of DIY networks enables the design of hybrid spaces and places for social sustainability, collective awareness, and conviviality. On the other hand, community networking is one of the most promising approach to overcome digital divide. What bridges these two themes is the idea that networks are not only a way to "access the Internet", but they are a way to connect people, and people make "the Internet". This workshop will contribute to investigate the way that local applications can influence the creation and the governance of community networks, and how community networks can stimulate the creation of novel local applications. DIY and community networks are embedded with the local social environment where they grow, so their study cannot be separated from the understanding of their societal stimuli and societal impact. For this reason the workshop will be highly interdisciplinary aiming to bridge the communication gap between those that build the technology (computer scientists, engineers, and hackers) and those that understand better the complex urban environment where this technology will be deployed (social and political scientists, urban planners, and designers). More specifically, people working on applications and uses of ICT are not always aware of the capabilities of technology for building local communication networks, on the other hand, scientists in the field of networking are often indifferent on the actual use and social implications of the technical solutions they design. We believe that we are currently in a moment in history when it is particularly important to bridge this gap between engineering and social sciences, to create an alternative to the current trend of centralization of resources and control that is taking place at a global scale on the Internet. Some of the themes that we want to be central in the workshop are: - Technical contributions that render DIY networking technology easier to understand and use by for less technically savvy people - Theoretical contributions that can facilitate the understanding of the various inherent trade-offs in the design of DIY networks and the translation of engineering decisions to constraints and requirements for applications developers and vice versa. - The integration of community networking with DIY applications, models of deployment, experiences of success and failure for this combination. - The exploration of the trade-off between Internet access networks and local networks for experimenters, hackers and citizens. - The way DIY and community networks can be placed in the frame of other horizontal and bottom-up experiences, such as Peer Production movements. - The links and interrelations between DIY and community networking in the frame of the models for alternative Internets, such as peer-to-peer networking, overlay networks, blockchain technologies etc. - Revisit key engineering questions, such as routing protocols, energy consumption, automation, resiliency in light of the possible practical uses of DIY networking technologies. For the special interdisciplinary session we welcome the following types of contributions: - Demos of working prototypes of DIY networking applications or systems - Posters or design mock-ups of imaginary applications - Short tutorials on important concepts that can facilitate interdisciplinary collaborations - Other alternative formats like interviews, testimonies, artistic treatments ----- Organizing Committee: Chairs Panayotis Antoniadis (NetHood, CH) Leonardo Maccari (University of Trento, IT) Jörg Ott (Technical University of Munich, DE) Arjuna Sathiaseelan (University of Cambridge, UK) Programme Committee Ileana Apostol (NetHood Zurich, CH) Roger Baig (Guifi.net Foundation, ES) Bart Braem (University of Antwerp, BE) Dimitris Boucas (University of Westminster, UK) Roberto Caso (University of Trento, IT) Renato Lo Cigno (University of Trento, IT) Manos Dimogerontakis (UPC, ES) Melanie Dulong de Rosnay (CNRS, FR) Felix Freitag (UPC, ES) Mark Gaved (The Open University - Milton Keynes, UK) Federica Giovanella (University of Trento, IT) Christian Fuchs (University of Westminster, UK) Ingi Helgason (Edinburgh Napier University, UK) Karin Anna Hummel (Johannes Kepler University Linz, AU) George Iosifidis (Trinity College Dublin, IR) Jussi Kangasharju (University of Helsinki, FI) Merkourios Karaliopoulos (Athens University of Economics and Business, GR) Thanasis Korakis (University of Thessaly, GR) Matthias Korn (University of Siegen, DE) Iordanis Koutsopoulos (Athens University of Economics and Business, GR) William Lieu (Auckland University of Technology, NZ) Anders Lindgren (Swedish Institute of Computer Science Kista, SE) Maria Michalis (University of Westminster, UK) Leandro Navarro (Universitat Politècnica de Catalunya, ES) Andrea Passarella (CNR - Pisa, IT) Claudio Pisa (CNIT - Roma, IT) Amalia Sabiescu (Loughborough University London, UK) Douglas Schuler (Evergreen State College - Olympia, US) Michael Smyth (Edinburgh Napier University, UK) Felix Treguer (CNRS, FR) Andreas Unteidig (UdK Berlin, DE) _______________________________________________ Battlemesh mailing list Battlemesh(a)ml.ninux.org http://ml.ninux.org/mailman/listinfo/battlemesh -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

8 years, 3 months

2
1
0 0

Fwd: [LEDE-DEV] Release Candidate Test Plan - first draft

by Ilario

The first release candidate for LEDE 17.01.0 is out: https://downloads.lede-project.org/releases/ -------- Forwarded Message -------- Subject: [LEDE-DEV] Release Candidate Test Plan - first draft Date: Mon, 30 Jan 2017 15:14:08 -0500 From: Rich Brown <richb.hanover(a)gmail.com> To: LEDE Development List <lede-dev(a)lists.infradead.org> Folks, There have been a couple questions on the forum about what needs to be tested in the LEDE release candidate. I put together a draft of a note that lists how to install, what to test, and how to report problems. It's at: https://lede-project.org/playground/releasecandidatetestplan Comments, updates, etc. welcomed. Rich _______________________________________________ Lede-dev mailing list Lede-dev(a)lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

8 years, 3 months

1
0
0 0

Libremesh Chef new mantainer

by Nicolas Pace

Hi Everyone, I'm the new mantainer of Libremesh's Chef tool: http://chef.altermundi.net/ I'm hunting down issues, so if you had any issue in the past with this tool it would be awesome to have it reported. You can do it by filling an issue report on Github here: https://github.com/libremesh/alterchef/issues/new Or you can send an email to this list or directly to me at: nico+chef(a)libre.ws Hope knowing about your issues/feature requests soon!

8 years, 3 months

1
0
0 0

LEDE 17.01 is close

by Ilario

This week LEDE developers should release LEDE 17.01 :D http://lists.infradead.org/pipermail/lede-dev/2017-January/005404.html Now we can seriously think about our LEDE-based relese :D

8 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

lime-dev