Useful and great report!
About the automatic distance stuff, SAn tested to have it on bt default on
librerouterOS, he probably remembers the outcome of the testing
Cheers
Gio
On Sunday 2 October 2022 18:33:27 -03 Ilario via 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/40c2cd8bd0f7e7b6553d47c11dacb48acc
> > 533863/package/kernel/mac80211/ath.mk#L112-L121 and is implemented here:
> > https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath
> > 9k/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
