Dear all,
please find below the meeting minutes of the meeting that happened on
Wednesday.
The next meeting is on the upcoming Saturday the 4th of October 2025 at
13:00 UTC (15:00 CEST, 10:00 ART).
The scheduled meetings are listed here:
https://libremesh.org/communication.html#online_meetings
During the meeting, many technical topics were discussed. The log of the
meeting can be quite inaccurate on the technical topics, sorry for that.
## Wednesday the 24th of September 2025 at 13:00 UTC (15:00 CEST, 10:00
ART).
### People
Cri, Gothos, Blaudio, Ilario, Victor, Javier, Agustin
### Topics
* Updates on GSoC 2025
* Updates on testing grant by Gothos
* Integration of Victor's GSoC into a permanent testbed CI/CD
* Updates on opening a Mastodon account, Cri
* Review of roles on the mailing list
* Updating roles on Github
* Proposals sent by Gothos via email
1. Do maintenance on the repo server
2. Use the repo server as endpoint to add a minimal telemetry of libremesh
3. Add to repo server a minimal public stats of downloads (may be a
simple grafana dashboard that read a prometheus-nginx)
4. Add a dns entry for firmware-selector.libremesh.org
5. Install an openwisp server on top of the repo server to experiment
with libremesh-openwisp
6. Create imagebuilders with a reduced kernel and let's see how far the
devices 8/64 go (kernel config SMALL_FLASH suggested by Javier [0])
7. Rework lime-docs asciidoc inclusion and packaging and substitute the
actual jekyll with a more modern vitepress or docusaurus
### Updates on GSoC 2025
Victor: good! It would be very nice if the work can be integrated in the
CI/CD permanent testbed. There are many tests to add. Also it would be
nice to test the lime-app web interface.
Final blog post by Victor:
https://blog.freifunk.net/2025/09/01/gsoc-2025-bringing-wi-fi-support-to-qemu-simulations-for-libremesh/
Ilario: thanks Javier for the students' selection, the results this year
have been amazing!
Agustin: 4 tasks about simplifying LibreMesh and getting it closer to
vanilla OpenWrt:
1. watchcat (created custom package lime-hwd-watchcat that uses
watchcat. Can be used instead of deferrable-reboot package that was
unmaintained)
2. odhcpd (harder project. Created shared-state-odhcpd-leases that
converts the leases and shares them)
3. removing VLANs from Babeld (modify lime-proto-babeld that now runs
directly on network interfaces (e.g. on lan1 without VLAN). Needed to
filter Babeld packages that go on the bridge and into Batman-adv.
Solution tested with DSA routers, to be checked how to have it working
with swconfig routers)
4. layer3-only LibreMesh version (just a proposal, didn't complete this.
Trying to create a network that does not have lime-proto-batadv, just
Babeld)
Javier: Gio said that maybe we should filter also Babeld hello packages
going to other interfaces like APs. We have to have a discussion about
whether we need the VLAN. About the selection process: what I did was
speaking to the people and handing out easy tasks.
Javier: Andi is positive on continuing GSoC for Freifunk.
Ilario: mentors' stipends half to Freifunk half to LibreMesh
OpenCollective account (for funding testing grants). Ok by mentors
(Javier and Cri)
### Updates on testing grant by Gothos
Original text of the grant proposal agreement:
https://lists.autistici.org/message/20250504.153057.850a1bae.en.html
Formal application by Gothos:
https://lists.autistici.org/message/20250515.134927.f52ad85a.en.html
Report by Gothos
https://lists.autistici.org/message/20250919.164615.9feb1461.en.html
Gothos most time spent studying LibreMesh and how to solve the issue of
cabled DSA-DSA connections
https://github.com/libremesh/lime-packages/issues/1192 "Default anygw
route working intermittently via cable #1192"
Proposed a solution here:
https://github.com/libremesh/lime-packages/pull/1214 "fix: anygw not
working via cable in dsa devices #1214"
Future work: how to handle MAC spoofing and MAC collisions. It is not
only a DSA issue, also swconfig gets crazy if another router presents
itself with the same mac address on it's br-lan/primary interface. This
anygw issue was a form of mac collision. The solution is to edit
manually the mac bridge forwarding database, it can be done using the
ip-bridge package. This happens when the interfaces are included in the
bridge.
Sorry I did not add logs in the report, I can send them on request.
Also, I added firewall rules blocking packages coming from anygw of
another node.
A problem remaining: Babeld neighbour nodes are being seen on the same
interface, even if there should be only one neighbour seen and the
second one, that is further away, should be seen by the other router alone.
Ilario: with a layer3-only network we would not have this issue, right?
Javier: yes, this is also an issue for batman-adv. Nowadays that
everything is streamed, maybe you don't want to stream to your
neighbours, so that a netowork with only Babeld would be more adequate
to the modern usecases.¿what are the interfaces that colide? What is the
root of this problem? In the case of ap-up there is a pull to fix a
similar issue.
Ilario: in my opinion the testing grant is fulfilled, thanks Gothos for
the amazing work. We can unlock the money transfer from OpenCollective
to Gothos as agreed. We can discuss in December for a new minor release
(still based on OpenWrt 23) and a new major release (based on OpenWrt
24, as tested by Gothos).
Ilario and Gothos will manage the payment of the testing grant.
### Integration of Victor's GSoC into a permanent testbed CI/CD
Javier: do you think we can have some scripts for automating the tests
in a virtual environment? Quesiton linked to Victor's job.
Gothos: Problem with GitHub actions' ImageBuilders that were not
creating the x86_64 images, that was needed for the testing. More work
to do with QEMU. I can do part of the job in the next period and setting
up the tests.
Javier: part of work of Victor was to adapt the OpenWrt's infrastructure
for automated testing (even on real hardware) to LibreMesh. Now we want
to set up a hardware real testbed.
Victor: I set up, for the GSoC, a virtual network with star topology.
https://github.com/VGDSpehar/openwrt-tests-libremesh
We started using labgrid for running automated tests on the virtual
network. The work is based on Aparcar's work done for OpenWrt.
https://github.com/aparcar/openwrt-tests
It would be great to run the tests on real hardware or at least a
permanent setup, we need to self host the Github actions.
Javier: so far we have Github actions running automatically Lua tests.
OpenWrt has distributed laboratories, so they can run tests on different
hardware even if some routers are in some place and some in another
place. Makes sense for a distributed project to distribute also the
testing. Maybe some tests with QEMU can be run inside Github actions run
by Github? Or must these be self-hosted?
Gothos: we can host, Codeberg can run tests on our hardware, maybe also
Github?
Javier: once we have this, we can also offer our labs to OpenWrt for
their testing. Planning a meeting with Aparcar. People are welcome to
join this meeting, let me know if you are interested.
https://aparcar.org/openwrt-tests-ui/
### Updates on opening a Mastodon account, Cri
Cri: I checked the conditions for using Freifunk's Mastodon server. If
we open an email, we have to decide who reads and answers the emails. I
tried to register inserting the mailing list direction as the
registration email, but the activation link did not arrive. And it did
not appear in the moderation page.
Ilario: let's create an email. If we don't advertise it, nobody will
write there. We could define that we just answer to contact the mailing
list and the chat, in case anyone writes.
Blaudio: I can ask to Andi Brau.
Cri: the email is used for activation and password reset.
### Review of roles on the mailing list
Subscribers 178 people!
Currently admins/moderators:
German Ferrero
Santiago Piccinini
Ilario
Cri
Removed German and Santiago
Added Javier
### Updating roles on Github
Adding or removing people? No.
### Proposals sent by Gothos via email
https://lists.autistici.org/message/20250924.075322.66356327.en.html
1. Do maintenance on the repo server
2. Use the repo server as endpoint to add a minimal telemetry of libremesh
3. Add to repo server a minimal public stats of downloads (may be a
simple grafana dashboard that read a prometheus-nginx)
4. Add a dns entry for firmware-selector.libremesh.org
5. Install an openwisp server on top of the repo server to experiment
with libremesh-openwisp
6. Create imagebuilders with a reduced kernel and let's see how far the
devices 8/64 go (kernel config SMALL_FLASH suggested by Javier [0])
7. Rework lime-docs asciidoc inclusion and packaging and substitute the
actual jekyll with a more modern vitepress or docusaurus
Gothos: on Saturday I will not be able to connect.
Point 1: is it ok to have downtime for upgrading? Ok to replace Apache
with Nginx? Should we continue to use the repo server for binaries (it
does not have much space)? Rather we could use it for monitoring.
Javier: excellent.
Telemetry, we can use
https://grafana.altermundi.net. Some nodes are
sending there their statistics. Different nodes from different
organziations are using it.
OpenWISP, I created a package similar to a distributed version of
OpenWISP, but it is not exposed to the web interface yet. It is a
collection of shared-state packages, all the ones containing the "info"
string, they collect info to show on the map. But the graphical
interface with the map and the representation is finished yet (v3
candidate branch form lime-app has all the latest changes). Still it
would be useful to have a self-hosted OpenWISP server for seeing what it
offers.
Ilario: let's keep at least the binaries for the latest release
Gothos: let's delete the release candidates and let's keep the release
based on OpenWrt 19 and the latest release. Also let's keep all the x86
ones.
Point 7: it is long term, we just improved the website, so the next
iteration can be left for 2026.
All other topics and proposals are left for discussion on the next
meeting that will be just in few days, on Saturday the 4th of October.
