Appearance

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.