Appearance

Thursday 4th of January 2024 at 13:00 UTC (14:00 CET, 10:00 ART). ​

People ​

Gothos, Pony, Nele, Ilario, Javier Jorge, Hiure, Cri

Topics ​

  • Website
  • Assign the work-grant for testing the release candidate
  • GSoC2024
  • Tasks for the next release

Website ​

The restyling has been approved in the previous meeting. The new website will look like this: https://libremesh.antennine.campiinrete.org

Assign the work-grant for testing the release candidate ​

Hiure routers: https://md.coolab.org/YaNewwIUSGuETd1uJRw1kw?view they have routers with DSA.

Ilario: There will be 500$ extra from GSoC mentor money, so we can fund 2 grants! 500$ per person should be enough for funding approx 30 hours of work (one week).

Pony: I would test in both levels. I just wanted to point out in my Email that I have no experience with babeld.

as libremesh we decided to accept the proposal of working for testing the last RC, from Hiure and Pony!

Money will be sent from: https://opencollective.com/libremesh we plan to divide a first part of the payament in the next week and another when they finish the hours of testing.

Send bank details to Cri or Ilario (others admins are Pau, GMarcos, Aparcar and an anonymous account (WTF)) for payment. Half now, half later.

Grant agreement ​

from email of 9/11/23: "During the meeting, a person will be selected, and this person will be entitled to receive the donations' money in an amount of 20 $ per worked hour. Until now, we have available 617-70 = 547 $ so we can fund 27 work hours. If the testing is not completed in the hours that the donations can pay (likely) it is ok, the rest of the testing will be done by the community as usual."

Reunited, the LibreMesh project meeting participants, taking decisions on behalf the whole LibreMesh community for topics related to the LibreMesh project and infrastructure; Pony pny@posteo.net; Hiure hiure@riseup.net.

Observed, that Pony and Hiure fulfill the requirements exposed in the email from 2023-11-09 sent by Ilario to the official LibreMesh mailing list, which can be read here: https://lists.autistici.org/message/20231101.163202.5a0742ed.en.html applying a decision of the LibreMesh project meeting of 2023-11-01, whose minutes can be read here: https://pad.cas.cat/LibreMesh_meetup_2024?view#How-to-use-donations-buying-hardware

Decided, that both and individually Pony and Hiure will receive the testing grant.

Clauses,

  1. each of the grant holders will justify 30 hours of work with a short report sent on the official project mailing list and the official chatroom;
  2. the work of the recipients will have to be aimed to the grant goal defined in the initial email as "Help the release of a LibreMesh release based on OpenWrt 23.05: testing with a realistic setup, reporting issues and, if enough time is available, fixing blocking issues."
  3. specifically, the receivers are required to check if the observed issues are already reported in the project bug tracker on Github, add there any useful information gathered, and file a new bug report for issues that are not yet properly described. The recipients are not required to fix the observed bugs, but they are strongly encouraged to use their work-hours for fixing the issues that they perceive as useful in pursuing the grant goal of "Help the release of a LibreMesh release based on OpenWrt 23.05";
  4. both and each of the recipients will have to build a setup matching the minimum requirements defined in the initial email:

The minimal simple topology we drew is a linear one, represented here:

internet1 --wire-- dual_band#1 --wifi-- dual_band#2 --wire-- single_band#1 --wifi-- single_band#2 --wire or wifi-- internet2

If the topology is going to be different, it is ok, as far as it is useful to test the release in a realistic setup.

Requirements for dual_band router:

  • at least 1 radio at 2.4 GHz
  • at least 1 radio at 5 GHz
  • DSA supported

Requirements for single_band router:

  • maximum 1 radio at either 2.4 GHz or 5 GHz
  • DSA supported

Requirements for internet connections:

  • internet1 and internet2 should preferably be two different internet connections (P.S. either wireless WAN or ethernet WAN, both are fine), but if they are the same it is ok
  1. the minimum scenarios to test are, as defined in the initial email:
  • checking if the internet connection internet1 goes down, if the wifi clients (common AP name) still have connection
  • checking if the internet connection internet2 goes down, if the wifi clients (common AP name) still have connection
  • checking if the internet connection internet1 goes down, if the cabled clients (on dual_band#2) still have connection
  • checking if the internet connection internet2 goes down, if the cabled clients (on dual_band#2) still have connection
  • checking roaming, e.g. with an audio call
  • define exactly how router wire to router is connected: LAN to LAN with mesh configuration e.g. https://github.com/libremesh/network-profiles/tree/master/calafou#lime-community-configuration-3
  1. some additional interesting things to inspect are included here but are not required:
  • document how to set ethernet interfaces for mesh only or clients only
  • inspect local DNS configuration
  • split the test network in two different clouds and checking the connection via wireless and via cable
  1. the LibreMesh project meeting will send 270 $ to each of the recipients as soon as bank details are provided. The received amount could be lower due to the bank transfer expenses.
  2. the LibreMesh project meeting will send 270 $ to each of the recipients as soon as each of them sends their reports on the mailing list. The received amount could be lower due to the bank transfer expenses.

GSoC2024 ​

https://projects.freifunk.net/#/projectshttps://github.com/freifunk/projects/tree/main/_projects

https://developers.google.com/open-source/gsoc/timeline

DEADLINE 6th of FEBRUARY

Enable wifi simulations for qemu ​

Javier: NIIT (INTI) + Altermundi

https://github.com/freifunk/projects/blob/main/_projects/_template.md

Pirania ​

Hiure

lime-app ​

Cri

additionally to LibreRouter fix some part that are not working to generic routers with libremesh, create an app external of the firmware that replaces lime-app, can be an android or a PWA, progressive web app. A the moment is not clear where the devoloping od lime-app is happening, here is stuck from 3of may 2023: https://github.com/libremesh/lime-app

Tasks for the next release ​

gothos proposals ​

I recently rebuilded libremesh based on openwrt 23.05.2 I've done another development build libremesh-master-ow23.05.2-361645e-20231224 [0] https://downloads.libremesh.org/selector/?version=master-ow23.05.2-361645e-20231224https://downloads.libremesh.org/development/master-ow23.05.2-361645e-20231224/

Since the default configuration of libremesh use 802.11s for wireless mesh networking In this build all 'ath10k-ct' packages are replaced with the default not '-ct' driver [1]

I'm going to add the following steps for next development-builds/releases

  • include by default the package wifi-unstuck-wa, that contains a userspace workaround, in each devices that have the buggy ath9k driver [2]
  • ??include by default wpad-mesh-wolfssl or wpad-mesh-mbedtls in devices that has enough space, to allow by default to encrypt the mesh traffic [3]
  • do a mini release

[0] the name follow this scheme: [version_dist]-[libremesh_branch]-ow[openwrt_version]-[libremesh_commit]-[build_start_date] [1] https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s#wireless_hardware_support changes are documented here https://gitlab.com/a-gave/libremesh-ansible-collection/-/tree/master/target/libremesh_master/openwrt_23.05.2?ref_type=heads [2] https://github.com/openwrt/openwrt/issues/7016https://github.com/libremesh/lime-packages/issues/144https://github.com/freifunk-gluon/gluon/issues/130 [3] https://libremesh.org/development.html ######## /end of gothos proposals

Discussion - Mini image ​

Gothos: we could make a release mini with less packages to fit in routers with small flash memories. Trying to not get far away from the default ones for not adding too much maintenance stress. Ilario: no need. It would be harder to use (one of the values of the project is to make things easy for non-technical people), so the people able to use it would be technical enough to compile it by themselves. Hiure: good idea to have a small release. There are people able to use the CLI interface but cannot compile. It allows us to use old routers. Ilario: ok!

KEEP lime-docs-minimal (LibreMesh minimal documentation) NOT NEEDED lime-app (LibreMeshApp) KEEP lime-hwd-openwrt-wan (Respect openwrt wan interface as default) KEEP lime-proto-anygw (LibreMesh anygw proto support) KEEP lime-proto-babeld (LibreMesh babeld proto support) KEEP lime-proto-batadv (LibreMesh batman-adv proto support) KEEP shared-state-babeld_hosts (babeld-hosts module for shared-state) NOT NEEDED shared-state-bat_hosts (bat-hosts module for shared-state) NOT NEEDED shared-state-nodes_and_links (nodes_and_links module for shared-state) KEEP babeld-auto-gw-mode NOT NEEDED batctl-default (B.A.T.M.A.N. Advanced user space configuration tool)

Gothos: what about including WolfSSL or Mbed-TLS? It is better to keep safe. Ilario: OpenWrt moved from WolfSSL to Mbed-TLS. So for sure we should avoid WolfSSL. During BattleMesh, Marek mentioned that OpenSSL is the one that deals better with encrypted mesh over lossy links. But OpenSSL increases the size of the images of about 1 MB, so it could be that it does not fit on some routers. For people just wanting HTTPS on the web interface, Mbed-TLS should be more than enough.

Discussion: differences between ImageBuilder and BuildRoot ​

Cri: there is no documentation from openWRT about the differences in output, we need that before suggesting to our users to use the ImageBuilder

Gothos: selecting batctl-default or other versions, this changes between the build methods

Ilario: for sure these settings will not be present in the ImageBuilder, but they are not important.

bmx7-auto-gw-bw-mode/Makefile: select CONFIG_BUSYBOX_CONFIG_CROND bmx7-auto-gw-bw-mode/Makefile: select CONFIG_BUSYBOX_CONFIG_CRONTAB bmx7-mdns/Makefile: select CONFIG_BUSYBOX_CONFIG_CROND bmx7-mdns/Makefile: select CONFIG_BUSYBOX_CONFIG_CRONTAB lime-debug/Makefile: select BUSYBOX_CUSTOM lime-debug/Makefile: select BUSYBOX_CONFIG_NC lime-debug/Makefile: select BUSYBOX_CONFIG_NC_SERVER

Someone, at some point, should ask to some OpenWrt guru about the differences.