Dear all,
here goes some notes LibreMesh-related discussions that happened in
BattleMesh, in case you were interested.
== Importance of distance setting
Seems that many communities tried LibreMesh on a long distance link and
they stopped using it as "it didn't work". This is very likely due to
the "distance" setting that has a default value of 1 km only.
There is no "right" value, as too large means poor performances and too
short means that it is not going to work at all.
In the documentation and everywhere available, we need to strongly
stress the importance of setting it for each radio.
Some discussion here:
https://github.com/libremesh/lime-packages/issues/932
== Lack of distance setting in lime-app
As the distance setting is so important for performances, it should be
possible to configure it from lime-app (I couldn't find it, but it is
possible that I missed it) on a per-radio basis.
An issue for this was already present:
https://github.com/libremesh/lime-app/issues/341
== Auto distance -- DynAck
Asking around, we discovered that for devices with ath9k wireless chip
(and just for these), there is a feature in the kernel that allows the
distance setting to be "auto", which means that it will adjust to the
farthest connected station. The description is here:
https://github.com/openwrt/openwrt/blob/40c2cd8bd0f7e7b6553d47c11dacb48acc533863/package/kernel/mac80211/ath.mk#L112-L121
and is implemented here:
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/dynack.c
Activating it (from "make menuconfig", select Kernel modules > Wireless
drivers > kmod-ath > Enable Dynack support) increases the squashfs size
by 3 KB (observed comparing the outputs of binwalk on two compiled
images with and without it. 3 KB is not as little as it sounds, in a
router's limited flash memory). If we think this is useful we could ask
the OpenWrt people to activate this by default (i.e. if we want use it
and have it available even compiling images using the ImageBuilder; that
up to now is not really supported for LibreMesh images).
This would be really really useful to have, but the "farthest connected
station" maybe means that works only with AP-station connections
(available in LibreMesh also for the backbone but not the default. The
default is mesh ieee802.11s)... Does anyone have idea? What happens if
we set this on a radio with a mesh link? And on a radio with AP+AP+mesh?
We can continue discussing on this mailing list or here:
https://github.com/libremesh/lime-packages/issues/932
== Presentation by Andrea: "Wireless network with agro-ecological
farmers, near Bologna"
Starting at 3:04:41
https://youtu.be/UMzRlaL6ZWE?t=11081
== Presentation by Jesi&co (Altermundi): "LAC Internet community
networks - for training teams and developers"
Starting from 1:55
https://youtu.be/1BqrX0-ICBQ?t=115
== Presentation by Ilario: "Hands on LibreRouter"
Starting from 53:32
https://youtu.be/XxMFNvwKrH0?t=3212
During the talk, some typos in lime-app were spotted:
https://github.com/libremesh/lime-app/issues/343
Trying to get internet connectivity via a smartphone, we found out that
it would be useful to allow customizing the SSID to be looked for:
https://github.com/libremesh/lime-app/issues/344
We maybe spot one small bug:
https://github.com/libremesh/lime-packages/issues/935
We also couldn't find the distance setting, see above.
== Other interesting things from BattleMesh
OpenWrt 22.03 started using nftables firewall instead of ebtables+iptables.
Luckily, the commands are compatible or there is some kind of translator
already in place... Everything should work without re-writing stuff
unless we are using some exotic iptables or ebtables rules (spoiler: we
are).
DSA replaced swconfig for the switch configuration since OpenWrt 21. The
automatic migration is not available yet (see
https://github.com/openwrt/openwrt/pull/10796), so we will likely need
to adapt some code for having LibreMesh working on newest OpenWrt releases.
When upgrading the firmware using sysupgrade (or LuCI web interface. I
did not test what happens when updating via lime-app) a weird warning
appeared, but it just means that the configuration cannot be preserved.
Annoyingly (IMHO), this warning appears also if the configuration is not
going to be preserved.
Reported here:
https://github.com/openwrt/openwrt/issues/10875
== Lack of documentation for creating network-profiles
Communities are encouraged to create a network profile, but no
documentation is present on the website for guiding them.
We surely need to write some.
Up to now there is just a bit here:
https://github.com/libremesh/network-profiles/blob/master/README.md
and here:
https://github.com/libremesh/network-profiles/issues/66
== List of communities in the homepage
As you can also read in the last meeting log, it would be great to hear
from each community using LibreMesh, so that we can have a rough list in
the website homepage.
== Next BattleMesh in Catalonia
Seems that next BattleMesh will be organized in the countryside of
Barcelona on the 5-11 of June 2023. Specifically, it should be hosted by
Calafou.
The focus will shift from the routing protocols TO THE FIRMWARES, so
this will be hugely useful for all the communities!
We encourage every community to share their feature requests and issues
to fix, so that during the next BattleMesh they can be addressed.
On Github or Gitlab, we can mark such feature requests or bugs with the
"BattleMeshV15" tag.
Ciao!
Ilario
--
Ilario
iochesonome@???
ilario@???
