I forgot one thing:
we also realized that we could start using the .test top level domain
for resolving hosts in the local community. More details here:
https://github.com/libremesh/lime-packages/issues/933
On 10/2/22 23:31, Ilario via LibreMesh wrote:
> 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@???
