Thanks Antoine!
Here goes more notes from more informal interactions at BattleMesh:
== Gluon and LibreRouter
We played with Gluon (the firmware used in most of the Freifunk network
communities, in Germany), and we even flashed it on a LibreRouter.
Everything worked except one thing: neither Gluon nor plain OpenWrt were
able to interact with the hardware watchdog present in the LibreRouter.
For this reason, the watchdog did its job rebooting the router every 10
minutes (watchdog is a system that reboots your device if it does not
hear any life sign from the operating system).
This has already been reported here
https://github.com/openwrt/openwrt/issues/10856 and fixed by SAn, so
that in the upcoming OpenWrt 22.03.1 should already be fixed.
T_X also wrote a checklist for having the LibreRouter-v1 officially
supported by Gluon firmware:
https://github.com/freifunk-gluon/gluon/pull/2654
== Gluon and local broadcast
Most of the communities using Gluon take advantage of Batman-adv for the
routing part, but limit the layer 2 cloud traffic filtering all of the
broadcast. This is very different from LibreMesh where all the local
network traffic travels as far as the Batman-adv cloud extends
== Update on the distance setting
SAn already tested this with mesh connections and works, so we really
want to have it implemented, and in my opinion we want it to be active
by default (if the wireless driver supports it).
https://github.com/libremesh/lime-packages/issues/932
== Web editor for Pirania splash page
An interesting discussion with Jesi:
the splash page of Pirania (the one that appears when you try to connect
to the internet) should be possible to edit by the local community
easily via a web interface, for adding announcements and information
about the local (virtual and physical) services. So a kind of very
barebone editor that allows an admin to add formatted text (without
needing to know HTML) in the splash page would be great to have.
https://github.com/libremesh/lime-packages/issues/936
Ciao!
Ilario
On 10/2/22 23:55, Antoine Claval wrote:
> Hey all,
>
> I’m a lurker here but most those are informations I missed even after installing a fair share of routeurs.
> Thanks for stitching them together, that’s valuable.
>
> Antoine
>
>> On Oct 2, 2022, at 4:33 PM, Ilario via LibreMesh <libremesh@???> wrote:
>>
>> 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@???
>> --
>> LibreMesh mailing list
>> LibreMesh@???
>> https://www.autistici.org/mailman/listinfo/libremesh
--
Ilario
iochesonome@???
ilario@???
