[lime] Technical meeting log

このメッセージを削除

このメッセージに返信
著者: Ilario
日付:  
To: LibreMesh
題目: [lime] Technical meeting log
Dear all,
we just finished the first technical meeting.
Please find below the meeting minutes.

One important bit you should not miss:
the plan is to have a meeting every two weeks, alternating a meeting on
Wednesday with a meeting on Saturday.
So, the next meeting has been set for Saturday the 21st at 13:00 UTC.

====================
=== 2023-01-04 =========
====================
TECH MEETING

Rodrigo, Cri, Hiure, Gio, Ilario, Henrik, S K, Dinesh, Ger

Wish list:
* decide if both swconfig and DSA should be supported in the next release
* Legacy hardware that is actually in use in real world community networks
* Next meeting dates
* debug connectivity problems with local services (Hiure)
* Channel for technical discussions
* LibreMesh support for OpenWrt 22.03 (or better next release?)
* support for OpenWrt 22.03, QoS,using TC (traffic control)
* review all the pull requests
* prioritise a list of issues to be resolved for the next LibreMesh release


Meeting:

Saturday 21 of january at 13 UTC

==================================================================
     decide if both swconfig and DSA should be supported in the next release
==================================================================
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
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 usefull 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 our of meeting, lets' go to try to set the
next meeting

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

     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, 3500, 3600, 4310, C60, C7, C5




==================================================================
Next meeting dates
==================================================================

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

==================================================================
 debug connectivity problems with local services (Hiure)
==================================================================
--> 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'


/etc/dnsmasq.d/localservice.conf
cname=serv2.iruway.in,janastunuc
cname=nextcloud.iruway.in,serv2.iruway.in
cname=prometheus.iruway.in,janastu.iruway.in
cname=grafana.iruway.in,janastu.iruway.in
cname=collaborate.iruway.in,janastu.iruway.in

and we copy this on every router.

=======================================================
Channel for technical discussions
=======================================================

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
==================================================
Closing at 14:56 UTC
Next technical meeting is going to be on Saturday the 21st of January
2023 at 13:00 UTC