lime-dev

lime-dev@lists.libremesh.org

338 discussions

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

3 years, 10 months

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

3 years, 10 months

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

3 years, 12 months

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, 1 month

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

4 years, 7 months

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, 4 months

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, 5 months

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, 5 months

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, 5 months

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.

5 years, 8 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

lime-dev