LibreMesh 2023 Meetings

we have the possibility to keep the same structure of the old website: jeckyll + ascii-doc but with a different theme: this is good because the content input can be txt file, and we reuse txt file to put the doc in the firmware and be readable by browser.

Cris: I’m happy that we keep the old habits about the structure oof the content, but with this restyl we move in a more fashionable shape. And I think is motivating also to update the documentation :) that probably the next work that we have to do…​ for the new year
Chris: I think the new theme looks nice. (But I am not a designer)

From this assembly the opinion looks positive to the merge of the "new restyle" of the website. we wait a week to see reaction in mailinglist, and after I(Cris) can accept merge request.

two people answered to this call https://lists.autistici.org/message/20231101.163202.5a0742ed.en.html
I, Cris, think that both are trustable people.. I expected that some of them come to this meeting, but this not happen.

Scenarios to check:

Pony proposal and devices: https://lists.autistici.org/message/20231126.160655.2b35dc1f.en.html
Cris: good point that the devices are with DSA.. not clear "None of them are running babeld though" and not clear if this is give problem to test, for example the first 2 scenarios:

Hiure https://lists.autistici.org/message/20231106.130003.64e0e1be.en.html
Cris: Good point is that can have a test in a real infrastructure. I would like know if the devices are with DSA or not..

we can wait answer in the mailinglist, if is present DSA on the devices is better to test because is one of the new feature present in openwrt23 and 23.

Gio proposed Fantastic Forwarder https://lists.autistici.org/message/20231027.124816.b94a37d1.en.html

For this assembly the name sounds good!

we just introduced the topics.. we are happy to listen proposals in the next weeks in the mailinglist.
the last year with the opportunity and money (circa 3k euro) from th GSoC we wrote Ansible roles to automated the build of the Libremesh release candidate. and this was really good for the Libremesh project.
So lets go to think something of improving for the next year. The work will be done in summer 2024 and we need also 2 people that apply as Mentor.
we can propose probably 2 projects.. but all the year depend from freifunk and google how many project can be really realized.

Topics:
* Assign the work-grant for testing the release candidate
* Website restyling, e.g. https://libremesh.antennine.campiinrete.org
* Next release name
* GSoC2024

Old decision: stickers to be printed by people attending events.

Currently we have 617 $
https://opencollective.com/libremesh#category-BUDGET

We need to write an email defining for what the money can be spent. The decision would be taken in the project meetings.

From the meeting minute of 2023-04-01:

Ger: the priority should be having a release

New proposals:

Minimum testing scenario:

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

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, but if they are the same it is ok

Physical setup requirements:
* none, even if all the routers are on the same table it is ok
* wifi channels have to be selected for avoiding wifi connections between routers that are not indicated as connected (i.e. dual_band#1 and dual_band#2 should be on the same channels. single_band#1 and single_band#2 should be on the same channel, but a different one from the one used by the dual band routers)

Scenarios to check:

Additional tasks:

Cri asked in the ML
SAn answered that is working in the hardware of LibreRouter2

ML is ok
Website also ok (the archive of the ML is public anyway, so public is ok)
Cri will copy the info to the website

Currently, the release candidate 2023.1 is based on OpenWrt 22

Ilario: 23
SAn: 23
Madez: 23
Cri: 22 or 23 are ok
Gothos: 23

Ilario: let’s name the new release candidate 2024.1-rc1

SCENARIO ESISTENTE:

rete mista openwrt & libremesh, feedback that the developing of libremesh is not enought fast as openwrt to releasing. Which relation there is with gluon? and which different?

IMAGES ARE ALREADY AVAILABLE:
https://firmware-libremesh.antennine.campiinrete.org/releases/master-ow23/

Discussing technical solutions in Gluon
Gothos: Would be good to have a network-profile compatible with Gluon
Discussing the problem of slow release cycle in LibreMesh

The server is outdated and is impossible to install anything.
For some next meetings we need to think about it!

Check the "# Add new signing keys" section of this email:
https://lists.autistici.org/message/20230929.142923.34529fc1.en.html

Screenshots from Github:


Seems that the keys cannot be accessed, so we either find who has the original key or we upload a new one.


Ilario writes to the people who could have the original key.
If noone has it, we will just upload a new one/pair during the next project meeting.
Maybe the key on Github is the same also on the repo server.
Gothos will check.

Saturday the 2th of December 2023 at 13:00 UTC (14:00 CET, 10:00 ART).

\o/ yhuuuu Lime 2023.1 is out!
https://lists.autistici.org/message/20230929.142923.34529fc1.en.html
https://lists.autistici.org/message/20230929.152044.f1940e95.en.html

firmware selector!!
https://repo.libremesh.org/selector

One small problem with the compiled images:
they already include a populated /etc/config/lime-community.
This should create a conflict when someone will include (compiling it in or via OPKG) a network-profile
Gothos will compile them again. He originally included the libremesh-default network-profile
Also, some lines are different from the lime-defaults: https://github.com/libremesh/network-profiles/issues/91

TO DO:
- write a News in the news section (Cri, done)
- change the menu item in the website: Get the last release! (ilario, done)

A new stable release and a release candidate for Openwrt 22!

We released a new version of Libremesh based on OpenWrt 19!

https://downloads.libremesh.org/releases/2020.4-ow19/

and a new release candidate based on OpenWrt 22:
https://downloads.libremesh.org/releases/2023.1-rc2-ow22/

This means that the release candidate needs testing, bug fixing and
loads of community love so that we can have an amazing release that can
actually ease the creation of community networks everywhere.

Check out the: https://lists.autistici.org/message/20230929.142923.34529fc1.en.html
https://lists.autistici.org/message/20230929.152044.f1940e95.en.html
for more detailed information.

Another great gourgeous news is that from now we have a Firmware Selector, check it out here:
https://repo.libremesh.org/selector

Keeping each 2 months, first Saturday of month, but adding some extra infraweek days to ease the participation to people who cannot on Saturdays

Next year we use a new pad XD → disroot use the plugin to have header and it is possible have a Table of Contents
https://pad.disroot.org/p/LibreMesh_meetup_2024

Adding some meetings matching the Spanish bank holidays…​
Remember to invite developers that we never see during 2023 and remember to them about "community meeting": konejo, javier,

Update: https://libremesh.org/communication.html →
Wednesday the 1st of November 2023 at 13:00 UTC (14:00 CET, 10:00 ART).
Saturday the 2th of December 2023 at 13:00 UTC (14:00 CET, 10:00 ART).
Thursday 4th of January 2024 at 13:00 UTC (14:00 CET, 10:00 ART).
Saturday the 3rd of February 2024 at 13:00 UTC (14:00 CET, 10:00 ART).
Saturday the 6th of April 2024 at 13:00 UTC (15:00 CEST, 10:00 ART).
Saturday the 1st of June 2024 at 13:00 UTC (15:00 CEST, 10:00 ART).
Monday the 24th of June 2024 at 13:00 UTC (15:00 CEST, 10:00 ART).
Saturday the 3rd of August 2024 at 13:00 UTC (15:00 CEST, 10:00 ART).
Wednesday the 11th of September 2024 at 13:00 UTC (15:00 CEST, 10:00 ART).
Saturday the 5th of October 2024 at 13:00 UTC (15:00 CEST, 10:00 ART).
Friday the 1st of November 2024 at 13:00 UTC (14:00 CET, 10:00 ART).
Saturday the 7th of Dicember 2024 at 13:00 UTC (14:00 CET, 10:00 ART).
…​

https://github.com/libremesh/lime-packages/commits/master

We are waiting to decide whether to increase the default distance parameter

we want relase after decide about "default distance"
https://github.com/libremesh/lime-packages/issues/201
https://github.com/libremesh/lime-packages/blob/v2020.3/packages/lime-system/files/etc/config/lime-defaults#L62-L75

Some data from Gothos and Ilario, with a script for replicating the analysis
https://github.com/ilario/wifi-distance-setting-exploration

Experience on distance parameter:
Cri: in our community with directional links, 10 km is a good default because people can flash the antenna/router by themself and see that Lime works. in other case, they
Troian: we are using omnidirectional routers 80 m away from each other, in a line of 3 to 5 routers, so we flash the firmwares with other distances

Possible point for a release: https://github.com/a-gave/lime-packages/tree/v2023.1

Ansible tool used to do this release candidate: https://gitlab.com/a-gave/libremesh-ansible-playbooks

here local community repo with this release, but with name Master, that is not the best..
https://firmware-libremesh.antennine.campiinrete.org/releases/master-ow22/targets/

Let’s create the 2023.1 branch, add the commit for setting the release name
https://github.com/libremesh/lime-packages/commit/88251b8dbca19783a24b56d29205f8c1d63244ca
and tag v2023.1-rc1
Ilario will do this.

Gothos will use the new Ansible tools for compiling the release candidate

People with access to the repo.libremesh.org:

Adding: Gothos, Cri
Ilario asks if it is ok to add them, with a deadline of a week.

People in the LibreMesh organization on Github:

How to add people: once per year sending an email explaining the criteria for applying. Then during the community meetings in August, accept people is there are not contrary reason.
Cri sends the first email

Adding:
* Cri github.com/digitigrafo
* Daniel Golle? https://github.com/dangowrt - let’s ask
* Gothos https://github.com/a-gave
* Jorge https://github.com/javierajorge - let’s ask

Ilario asks to Jorge, Daniel Golle
Update: I don’t have any contact of Jorge

we have to give back the money to ilario
Ilario will try to collect them from OpenCollective
Update: I managed to request the money on OpenCollective, it is easy!

Some people on the chat asked stickers
If a big community or an event wants to have the stickers they can print them and we pay the printing with the money from donations on OpenCollective

details for printing stickers:
https://lists.autistici.org/message/20230509.143549.d28a5cc1.en.html

files:
https://repo.libremesh.org/tmp/stickers/

some events where we can be and give stickers https://foss.events/:
* https://hackmeeting.org/hackit23/
* https://www.internetfreedomfestival.org/
* https://2k22.balccon.org/

ASU is amazing. It uses the OpenWrt ImageBuilder
If we want to use the official ASU server, we need to use ODHCPD for IPv6:
https://github.com/libremesh/lime-packages/issues/294
I we set up our own ASU server, then there are just tiny things to fix:
https://github.com/libremesh/lime-packages/issues/1000

13 UTC Thursday 17th August

finish at 16:20

Gio sta lavorando sul plugin(?) shared state, non è un pacchetto essenziale nell’ultima release LiMe2020, ma lo sarà nel futuro xchè da un sacco di info, in pratica lo si sta riscrivendo da LUA a C++. il tempo per fare altro è poco.

Come supportare Openwrt 22.05? stan cambiando un sacco di cose, si rischia che la prossima non sia di nuovo compatibile con la precedente

dalla comunity antennine.noblogs.org abbiamo sperimentato e funziona LiMe 2023.1 per le tplink CPE 510 v3
, che non supportano la versione 19 di OpenWrt, ora stiam testando anche le mikrotik Router Board Light Head 5 https://openwrt.org/toh/hwdata/mikrotik/mikrotik_lhg_5

Gio per lavorare si basa perlo più su OpenWrt development

Cri dice che pubblicherebbe i devices provati in valle per dare segno dal sito che LiMe sta andando a supportare le nuove release di OpenWrt

Come si fa una release candidate?

in teoria si fa un tag e poi si fa andare una suite di test, e poi un po a mano la lime-app

Individuare il commit che si è testato:
siam sulla master
Commit: 10e9bf65684708d5739ada850fd280a6abf3cc72 di https://github.com/libremesh/lime-packages

ATTENZIONE ci sn differenze di build tra il buildroot e l’imagebuilder: non ci stampa nel banner il commit della versione libremesh usata per buildare, non abbiam indagato sul perchè..
Altro esempio inserisce batctl-tiny invece che completo

Conveniamo che Libremesh è basato sul buildroot, e in realtà non garantiamo da nessuna parte che davvero concluda le build identiche con l’image builder

Architetture da compilare x la Release Candidate:
ath79
mediatek ( per tutti e 2 ? )
qualcom atheros
ralink
x86
usermod linux

verificati in questa lista: https://downloads.openwrt.org/releases/22.03.4/targets/
ath79
mediatek
x86

una volta compilati i pacchetti con la buildroot…​ o anche la buildroot completa, conviene metterla sul server http che esponiamo: https://downloads.libremesh.org/releases/

Mettere anche i pacchetti volendo tutti buildati uno per uno, però è una mega sbatta, mettendo la buildroot intera, cmq ha tutto. Pacchetti singoli flaggato M, si potrebbe mettere anche nel file di configurazione di opkg.. alcuni device vogliono i pacchetti aggiuntivi compilati nella stessa build con cui è stato compilato il kernel.

https://downloads.libremesh.org/releases/2020.1/targets/ath79/generic/packages/

oppure un tar.gz con tutta la buildroot che ha buildato.
Oppure mettere una immagine docker che ha dentro il tutto, così è riproducibile totalmente.

OK, ci vuole un po di tempo per buildarle tutte.. le mettiamo a fare.

Una volta che si hanno i bin e il tar.gz della buildroot. scrivere in lista LiMe ed o Ilario o .. che possono pubblicare il tutto.

VARIE: rispetto a libremesh curtigghio, è una possibile strada del futuro in quanto 802.11s è una vita che non lo aggiornano.
Gio riprenderebbe più avanti a lavorare su quello. Bello se ci lavorano altri di OpenWrt.. lui può supportare

https://pad.codigosur.org/LibreMesh_meetup_dic_2021#L1438
- resume of the BattleMesh
- resume of the network installed at Calafou for the BattleMesh with the technical tricks included in its network-profile https://github.com/libremesh/network-profiles/tree/master/calafou
- list of issues observed during BattleMesh and traspassing this list to the LibreMesh issues list

as a community approach of managing mesh, so if you are 1 probably libremesh is overkill, but you can use as range extender for example. you flash 2 devices and you try. minimal configuraion. the difficult is at the begin to flashing the device but after you should not need a tech team. also Lime is modular. double mesh protocol, in layer 2 batman and 3 with babbeld. you isolate the layer 3 in your house or the place that you want isolated.

wan just plug and works…​
LAN-LAN if you connect two libremesh nodes via their LAN ports with a cable, you should configure the port for not being included in the br-lan bridge, see https://github.com/libremesh/network-profiles/commit/57eeae71781abb2403ff61afda9ca7d2664bfc7e
anyway, modern routers have a chip that cuts the loops or the CPU should realize and stop the loops

ip6tnl created by a kernel module even if not used
ifb0 for traffic shaping
br-lan switch
dummy0 fake interface for having a stable MAC that does not depend on interfaces going up or down
eth0.1 virtual interface with all the LAN ports
anygw a dummy interface, member of br-lan

https://openwrt.org/playground/arinc9/network.interfaces

lime app with some issues, coneco is workin on this.
https://github.com/libremesh/lime-app/issues/378

connecting by cable to a router connected by cable
and using the thisnode.info IP, all the wire-connected nodes answer, breaking ssh connections
bug present also in previous versions!!!
https://github.com/libremesh/lime-packages/issues/1008
it could have been fixed by Pony

we need a filter for babeld over batman

babeld is complaining a lot
https://github.com/libremesh/lime-packages/issues/1003

wpad-* for mesh encryption has a weird Makefile that makes thing complicated to select in menuconfig
https://github.com/openwrt/openwrt/issues/8312
one option, to write what you want in the .config:
https://github.com/libremesh/network-profiles/blob/master/calafou/indoor2/DOTconfig-xiaomi_mirouter_4A_gigabit_edition

aparcar added documentation for using the ImageBuilder in the readme:
https://github.com/libremesh/lime-packages/blob/master/README.md#using-the-imagebuilder

gothos: using it with x86 does not work on qemu

documentation on network-profiles
https://libremesh.org/development-network_profiles.html
https://github.com/libremesh/network-profiles/tree/master/calafou

german company
explain them the project, they are community-friendly
https://www.stickma.de/

Creating the "v2020.2" tag for the release based on OpenWrt 19.07

And now build!

Build on repo.libremesh.org stops with an error. Maybe due to the old software running on the server??

In the Google Summer of Code we have a solid application by "samlo" for the LibreMesh-related project
Resume about the workflow of GsoC for mentors and students: send reports, write posts in the freifunk website

Super nice that Gluon is a new tag standard of hardware supporting openwrt.
Gluon added Librerouter in supported hardware

There are translations on TranslateWiki that have not been copied to LibreRouterOrg/docs
https://github.com/libremesh/lime-packages/issues/257#issuecomment-1453891582

https://translatewiki.net/wiki/Category:LibreMesh we need to have an appointment with Altermundi and Libremesh so we organize to update translation on the website.

WHEN?

Updates about Home page of website https://libremesh.org/ , update of organizations
Note about website: https://pad.disroot.org/p/libremeshwebsitechecks_ifuemhfjk

Organizations supporting LibreMesh:

Community mesh networks using Libremesh:

Several other community networks are using or used LibreMesh on their devices with their own customizations (network profiles), some of these are listed here.

Ilario rewrites the Get It! page once we have the 2020.2 release

Question: about virtualization for testing Libremesh?→ there is the project of the last year and docker images.. moved the conversation on the next topic: need of a Docker image for unit testing on OpenWrt 22.03

https://github.com/libremesh/lime-packages/pull/938
https://github.com/libremesh/lime-packages/issues/389

Sam can ask to aparcar on Element/Matrix list how to buid a Docker image for that

??ar71xx/generic??

ar71xx/generic will also be compiled

vorremmo compilarla ed esporre dal server da cui esponiamo ora: https://downloads.libremesh.org/releases/
Il server non è aggiornato e non builda, quindi bisogna compilare in locale e poi solo uploadarli.
Una volta che ci sono dalla Valsamoggia possiamo testare alcuni target
Poi facciamo annuncio ufficiale
https://github.com/libremesh/lime-packages/tags

Ilario creates a v2020.2 tag at the commit where G10h4ck created the OpenWrt_19.07_compatible branch.

https://libremesh.org/development-kernel_vermagic.html

We have no news, so we can write an email in list and personally to know news.. (Cri)

(e.g. a compilation server, or donation to Battlemesh) https://opencollective.com/libremesh

Whishlist:
- pay the travel to the battlemesh for some of librerouter/altermundi (maybe next year or another event)
- pay the travel for the travel to battlemesh for some people of Antennine (maybe next year or another event)
- pay the update of the server of downloads CodigoSur? Chiede Cri
- buy some stickers LibreMesh YES
- donation for the domain name? for the newsletter ?
- email @libremesh.org?
- hardware per testare il supporto?

This year there is not support for the travel
C’è stata un acquisto economico di router per fare la rete di Calafou, c’è il piano di usare Libremesh,
plasmacloud pa1200, che hanno openwrt 22.03(?)
quindi vorremmo arrivare al battlemesh con libremesh basato su openwrt22.03

During battlemesh, online and in real life , 13utc, 3rd day of the vent → 10 may

Saturday the 3rd of June 2023 at 13:00 UTC (15:00 CEST, 9:00 ART).

Friday the 7th of April 2023 at 13:00 UTC (15:00 CEST, 9:00 ART).

Closing at 17:24 CEST

Cri, Gio

We use this issue for keeping track of the updates:
https://github.com/libremesh/lime-packages/issues/951

Proposing:
* supporting only OpenWrt 22.03 in the lime-packages' "master" branch.
* create a "target_OpenWrt_19.07" branch for the extended support to OpenWrt 19.07 and a tag with a minor release "2020.2" which can be considered as an updated version of the 2020.1 LibreMesh release "Expansive Emancipation".

HOW we will make available this to the users as builded firmware?
- images of master on Owrt22.03 will be linked here: https://libremesh.org/getit.html
- the extended support to Openwrt19.07 can be explicited here: https://libremesh.org/development.html

Other relevant issues for using OpenWrt 22.03 are:
https://github.com/libremesh/lime-packages/pull/971 (Dnsmasq now can access only specific folders)
https://github.com/libremesh/lime-packages/pull/950 (we were creating a file that now is provided by an OpenWrt package)

FROM Ilario by mailinglist:
My (too complex) dream-solution would be to have an integrated solution with:
* if you access the AP via a WPA interface, you access a VPN made with Tinc (or Wireguard) and have max priority access to the gateway you own in your house, and mid priority access to the other gateways
* if you access the AP via an open interface, you get Pirania captive portal, if you have granted access, you have mid-priority access to all the gateways
* instead, if you Pirania does not grant you the access, you have low priority access to all the gateways

"Legacy hardware that is actually in use in real world community networks"

What hardware are others already using. What hardware CAN be used.

Where is the most up to date list? Should/how can this be organized, and shared on LM website/github, etc

Compatible Hardware

It is recommended that the router has at least 8 MB of flash memory and 64 MB of RAM. For routers with 4 MB flash memory or 32 MB of RAM, use the special firmware named -mini or compile one yourself excluding some heavy packages (e.g. opkg or the LuCI and lime-app web interfaces).

Not all the OpenWrt supported routers work with LibreMesh (at least, not with its default configuration), for a list of the tested hardware, see our hardware page. http://libremesh.org/docs/hardware/index.html

Tested Hardware (from the list in the website)

This is a list of devices that were tested by the community and reported as fully compatible with LibreMesh, it is by no means a complete list of the working devices.

EXAMPLE, now I’m using Cristina : Device Ubiquiti Litebeam M5

Firmware LiMe 2020.1 ExpansiveEmancipation ((no branch) rev. 6f1730e 20210612_1552)

openwrt-19.07 branch (git-21.044.30835-34e0d65) And we have the same firmware also on CPE 510 v2

Updated Hardware List

Equippment ported only to owrt22 - Archer C50 v5, Archer C6 (to test new LIME version)

https://antennine.noblogs.org/post/2021/12/15/tipi-di-antenne-che-usiamo/

Are we limited to the devices on the OpenWRT list? https://openwrt.org/toh/start

How are people porting new devices?

Big changes w/ new OpenWRT version. Sometimes previous LM versions on OpenWRT 18 worked, now with v.19, things break.

How do we define the process of using more hardware, including hardware not on OpenWRT listhttps://github.com/libremesh/lime-packages/issues/.

Relevant?:

https://communitynetworks.group/t/expanding-openwrt-libremesh-hardware-support/790/5

https://communitynetworks.group/t/openwrt-libremesh-image-building-learning-group/823

what do yuo think about aplly QoS in a mesh network, how to know how much bandwith do you share with the others. can you set a distribution of this.
on AP and Client, but difficult in nodes of mesh, because that are running the mesh routing

Bologna: we collect the data by Prometheus + Graphana and show to the community, we have meeting to show with the others, 1 meeting closed with everyone inside the mesh network; ither 3 public meeting in a public place, and we have every season a public tech meeting. we started to do that meeting for show the privacy problem but at he end is usefull for the know the consumtion of bandwith
in my island we are 15 with a connction of 30Mbs down /10Mbs up

Elektra: traffic shaping to go on AP that clients are using.
Is there a more centralized way to do this?

Traffic Control Talk:
https://videos.apc.org/u/nicopace/m/traffic-control-on-openwrt-and-libremesh/

https://communitynetworks.group/t/traffic-control-on-openwrt-and-libremesh-second-round/888

Who else is doing this, or interested in this?

Hiure:
Pirhana, in Brazil. Allow people to access by Voucher. PiHole - to block sites.

A the moment, about the support for OpenWrt 22.03, from Bologna/appennino we have in use a link done on Tplink CPE 510 v2.3

working to merge this https://github.com/libremesh/lime-packages/pull/959

Closing at 14:27 utc
Next tech meeting will be on Wednesday 15th February 2023

Saturday 21 of january at 13 UTC

Gio: to introduce the topic: openwrt22.3 is using DSA (Distributed Switch Architecture), [1] [2]and we in Lime2020 we use SWconfig. Support both could be difficult.
[1] https://openwrt.org/docs/guide-user/network/dsa/start
[2]https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial
[3] https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa
Talk at battlemesh https://youtu.be/1BqrX0-ICBQ?t=3462

Not all targets that we use a lot have been ported to DSA, like:
- LibreRouter v1
- TP-Link TL-WDR3600
- TP-Link TL-WDR4300
- TP-Link TL-WDR4310
- TP-Link TL-WDR3500

There is a big pull request in OpenWrt porting all ath79 to DSA.
https://github.com/openwrt/openwrt/pull/4622
We can take that PR and split it in smaller ones to send to OpenWrt for easing its merging.

Henrik: it is too messy to support both. There are many devices still with swconfig. Have anyone used any router with two real ports (like HiveAP), no switches?

Ilario: The proposal to wait for the merge of DSA for our favourite ATH79 routers would mean waiting for more years and our last release is already very old (2020). Can we make one release that supports both and then dropping swconfig for the following one?

Henrik: Some routers do not work well with swconfig, so if possible we should move to DSA.

Cri: we use Ubiquiti LiteBeam (Atheros). We are patching LibreMesh for using it on OpenWrt 22.03, we listed our patches in the mailing list
https://lists.autistici.org/message/20221210.180941.ac807e16.en.html

Ilario: some of your patches have been used for making this pull request https://github.com/libremesh/lime-packages/pull/959

Henrik: what has been planned?

Ilario: does Altermundi have planning? This meeting is also for making this planning

Gio: old devices are important to support Libremesh, The new devices will be all DSA, but how we do with the old? Are we sure that old devices will support DSA?

Ilario: we have old devices to test and I already checked that can support it
the DSA presence check is already included in https://github.com/libremesh/lime-packages/pull/959

Henrik: OpenWrt is moving away from Lua, going to ucode (own scripting language, better integrated with UCI, similar to JavaScript), rewriting all their scripts. How is this going to affect LibreMesh? Lua is not going to be included by default. I think they do a great work but the problem is the conversion to the new scripts.

https://lxr.openwrt.org/source/ucode/README.md
https://forum.openwrt.org/t/luci-rewrite-in-ucode-testers-wanted/137250
ucode https://github.com/ynezz/openwrt-ucode
ucode git https://github.com/jow-/ucode#about

Ilario: hopefully, if we include the Lua interpreter, our stuff should go on working

Gio: I hate JavaScript

Henrik: they fixed many things, seems like a good step. The major issue is the memory impact of having both UCode and Lua. Anyway Lua is not too big and the impact should be ok.

Rodrigo: Archer C660 C50 C600 only work with OpenWrt 22
Is there some line where help to move forward? Where I can start?

Ilario: start testing a couple of pull request: this for example https://github.com/libremesh/lime-packages/pull/959 is useful if you try others devices. I can propose to use the chat element of Lime, or in the Mailinglist.
Also you will need to include https://github.com/libremesh/lime-packages/pull/950

Rodrigo: I can build myself and test, I can open this server to you for compiling http://compila.ax.org.br:5000/
Sounds good to open a specific channel for testing.

Gio: why not move to a json like format for configuration of.. ?

Henrik: the config format is trying to stay compatible. There are issues with the use of labels and names. E.g. the main device in the /etc/config/network does not have a name. Important that the config file is human readable

Ilario: this issue we hit when preparing the pull request, it is the [0] here: https://github.com/libremesh/lime-packages/pull/959/files#diff-f3b71b4df527c1cf41e8c74bddde83a63cc2424814a06db3e415a640c0e480efR54

Henrik: I made a script for getting around the positional reference issue, I will try to share it on the linked pull request in a few days

Ilario: let’s test the pull requests and talk about this swconfig+DSA vs DSA-only decision in the next meeting

Cri: ok we finshed the first hour of meeting, lets' go to try to set the next meeting

G10h4ck:
- LibreRouter v1
- TP-Link TL-WDR3600
- TP-Link TL-WDR4300
- TP-Link TL-WDR4310
- TP-Link TL-WDR3500

Troian - Nupef : TPLinks- WDR 3500, 3600, 4300 Archer C7v5 Archer C50v4, CPE210v1-3,

Equippment ported only to owrt22 - Archer C50 v5, Archer C6 (to test new LIME version)

bologna appennino: Ubiquity Litebeam M5 - TPlink CPE 510 (ath79)

Hiure - Brasil / India : Cpe510/v1,v2,v3, Cpe210/v1,v2,v3 Cpe220, A7v5, tl-wdr3500, tl-wdr3600, tl-wdr4310, C60, C7, C5

Ilario: what about one technical meeting every two months?

Hiure: what about one or two weeks?

Ilario: ok 2 weeks
Cri: ok,could be on 18th of January? wednesday..

Ilario: is Saturday ok?

Gio: better for me to do it in weekdays, but my agenda is changing so you can organize it in any day and then I will try to join

Hiure, for me is good, but after of 19th of january

ilario: not able to connect during week, available only at night. And weekends.
Ilario: what about alternating meetings on Saturdays with meetings on Wednesdays?

Rodrigo: better during week days at work time

Cri: Saturday the 21st?

Ilario: great! Same time?

Hiure: yes
Cri: yes
Troian: yes

NEXTmeeting: saturday 21 of january at 13 UTC

-→ from India some feedbacks about issues on "How he data are routed inside of the network"?
ex: wireless network, more wired connection, more internal service exposed also to external, DNS configuration works, the server sometimes is not connected due to routing of network..

The problem starts when we use cables, things get unstable
if I try to extend network by cable, I get the problem: the 2 libremesh routers use …​.. and start loops and
callbacks, problems with Batman-adv

Ilario: Can you list a minumal setup for reproducing? Do you only use the LAN ports or also the WAN ports? If you connect via cable a LAN port to a WAN port of another LibreMesh router things are going to be broken for sure.

Gio: are not supperted connect WAN and LAN by cable

S K: The problem appears when you are doing ethernet mesh and connect local servers on the same router

Cri: how do you keep the problem? just a pig with DUP? or what?

Gio: the local server is just as the other clients, should not trigger any issue. Maybe the already existing issue gets more visible when it happens with a server.

S K: One problem is that ip of the local server changes now and then. But the main problem is latency.

Hiure: yes we use the local server with fixed ip in libremesh, editing /etc/config/dhcp and /etc/dnsmasq.d/localserver.conf

Ilario: for leaving some IP ranges out of the auto-configuration and the IP assigned to the DHCP clients https://github.com/libremesh/lime-packages/blob/master/packages/lime-docs/files/www/docs/lime-example.txt#L33-L35

S K: Sorry, my point is that the problem could be that there are two DHCP servers (two nodes) connected with each other through ethernet and then there are clients on the same switch. So that might cause routing problems?

Hiure: when we have only one service it works.
nginx servers with lot of services, using CNAME, some servers have fixed IP.

Ilario: can you share the modifications you do to those two files, for understanding?

Hiure:
/etc/config/dhcp
config hostrecord 'server'
option ip '10.x.y.z'
list name 'servidor.com'

and we copy this on every router.

We have two channels:
https://libremesh.org/communication.html
and also the Github Issues and Pull Requests.

Gio: no time for following the chat but I follow the mailing list

Ilario: prefer to use the chat, so that is easier to share simple observations in a casual way

Rodrigo: I prefer the chat

Ilario: no consensus, no decision.

Closing at 14:56 UTC
Next technical meeting is going to be on Saturday the 21st of January 2023 at 13:00 UTC