Thank you for the detailed explanation (towards what actually need to be
resolved) and information
I also find myself looking for OpenWRT 22.03 compatibility with LibreMesh
(mostly due to support for some newer IPQ4018 devices)
e.g MikroTik hAP AC3 / AC2 and a 3G Router - Cell C RTL30VW
for myself in the past (Sep 2020) i created a script to speed up the
selection process of packages i wanted to include in OpenWRT/LibreMesh
build for my own use
I have attached the script if anyone else finds it useful. (script.sh)
should be modified to clone later OpenWRT releases
Run and choose the target hardware
One then just needed to run make menuconfig too confirm the selection of
wpad-mesh-openssl
Looking forward to the process of resolving the found issues in order to
build on top of OpenWRT 22.03
Regards
On Wed, Nov 9, 2022 at 11:01 AM Ilario via LibreMesh <libremesh@???>
wrote:
> Hello!
> I share here some unsolicited notes on the testing I did using the
> latest LibreMesh code on top of OpenWrt 22.03, mostly because I hit an
> issue that seems a bit complicated for me to fix...
> And also because Jesi asked if I could share an easy-to-understand
> explanation of my open pull requests and issues on Github and I think
> this is a great idea :)
>
>
> ==== Technical stuff - skip this unless you want to replicate ====
>
> I compiled an image of clean OpenWrt 19.07 and another of OpenWrt 22.03
> following the instructions on the LibreMesh website (for the latter I
> replaced all "19.07" occurrences with "22.03").
> In order to have a clean OpenWrt image I selected the LibreMesh packages
> as <M> in menuconfig instead than <*>. This means that the LibreMesh
> packages are compiled and are available in the openwrt/bin/ folder but
> they are not included in the compiled firmware image.
> This way I can later install the LibreMesh packages one by one in the
> routers.
> A quicker alternative would have been to take OpenWrt already compiled
> from OpenWrt repository, add LibreMesh repositories, add the LibreMesh
> repository signing key as trusted and install the LibreMesh packages
> from there (but I don't know how to get and add the packages' signing key).
>
> The reason for flashing an image compiled with only OpenWrt without
> LibreMesh stuff is:
> * LibreMesh is not yet tested to work on top of OpenWrt 22.03, so that
> could malfunction.
> * The easiest way to return a router to a working state if you screw up
> with some configuration is the reset button, which takes back the router
> to the state it was when it was just flashed. But if you flash something
> broken, it takes you back to a broken state, not useful. So if you flash
> a plain OpenWrt, and then you break something while installing or
> configuring LibreMesh components, you can just go back to plain OpenWrt
> using the reset button.
> * This way I can analyze the LibreMesh packages one by one, easier for
> debugging.
>
> Then I set a static 192.168.1.2 IPv4 to my laptop and I connected to the
> router.
>
> --
> Side note #1:
> modern Linux systems will refuse old RSA keys that are used in OpenWrt
> 19.07 and you will get an error like this:
>
> Unable to negotiate with 192.168.1.1 port 22: no matching host key type
> found. Their offer: ssh-rsa
>
> in this case you will have to add these options to your ssh and scp
> commands:
>
> -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa
> --
>
> --
> Side note #2:
> with modern ssh clients, scp will complain with an error like this:
>
> ash: /usr/libexec/sftp-server: not found
> scp: Connection closed
>
> unless you add a "-O" option (from the man page "-O Use the legacy SCP
> protocol for file transfers instead of the SFTP protocol.")
> --
>
> Then I added this to /etc/opkg/customfeeds.conf (would have been smarter
> to add it in the buildroot compilation process creating a
> files/etc/opkg/customfeeds.conf file):
>
> src/gz local1 http://192.168.1.2:8000/packages/mipsel_24kc/base
> src/gz local2 http://192.168.1.2:8000/packages/mipsel_24kc/libremesh
> src/gz <http://192.168.1.2:8000/packages/mipsel_24kc/libremeshsrc/gz>
> local3 http://192.168.1.2:8000/packages/mipsel_24kc/luci
> src/gz local4 http://192.168.1.2:8000/packages/mipsel_24kc/packages
> src/gz <http://192.168.1.2:8000/packages/mipsel_24kc/packagessrc/gz>
> local5 http://192.168.1.2:8000/packages/mipsel_24kc/profiles
> src/gz <http://192.168.1.2:8000/packages/mipsel_24kc/profilessrc/gz>
> local6 http://192.168.1.2:8000/packages/mipsel_24kc/routing
> src/gz <http://192.168.1.2:8000/packages/mipsel_24kc/routingsrc/gz>
> local7 http://192.168.1.2:8000/packages/mipsel_24kc/telephony
> src/gz <http://192.168.1.2:8000/packages/mipsel_24kc/telephonysrc/gz>
> local8 http://192.168.1.2:8000/targets/ramips/mt7621/packages
>
> then I shared the packages from the buildroot on my laptop with:
>
> cd openwrt/bin
> python -m http.server
>
> And on the router again:
>
> root@OpenWrt:/etc/opkg# opkg update
>
> This succeeds to download the local ones and fails to download the
> others as I did not connect the router to the internet.
>
>
>
> ==== Here starts the HUMAN UNDERSTANDABLE (maybe) part ====
>
> During the packages selection in menuconfig, an already existing bug (in
> the Makefile of an OpenWrt package) that was deselecting the
> wpad-mesh-wolfssl package, got much worse with OpenWrt 22.03. So that,
> if we want to have encryption over the node-to-node mesh connections we
> need to choose another package (better to use OpenSSL as WolfSSL is not
> designed for dealing with packets loss).
> The discussion is going on here:
> https://github.com/libremesh/lime-packages/issues/613
>
>
> During the compilation of LibreMesh on top of OpenWrt 22.03 there is an
> error that says that two packages contain a file with the same name
> "/etc/udhcpc.user". When the package ubus-lime-utils was created, this
> file was not present in OpenWrt so there was no problem. But recently,
> an empty placeholder with that filename was included in netifd and this
> causes the clash.
> Reported here:
> https://github.com/libremesh/lime-packages/issues/927
> A proposed fix is here:
> https://github.com/libremesh/lime-packages/pull/928
>
> Using the fix, the compilation run to completion.
>
>
> So I started installing the LibreMesh packages starting from the core
> one: lime-system
>
> And I got an error as lime-system requires the jsonc library contained
> in luci-lib-jsonc, but this was not installed as it was not listed in
> the lime-system list of dependencies.
>
> root@OpenWrt:/etc/opkg# opkg install lime-system
> [...]
> /usr/bin/lua: /usr/lib/lua/lime/utils.lua:6: module 'luci.jsonc' not found:
>
> This issue has been reported here
> https://github.com/libremesh/lime-packages/issues/940
>
> and while fixing it I realized that the luci-lib-jsonc dependency was
> missing from many other packages and that also other libraries were used
> without being mentioned in the dependency list.
> So here goes the pull request adding these dependencies:
> https://github.com/libremesh/lime-packages/pull/941
>
> Currently, everything works even with this lack of dependencies. This
> happens because when you select many LibreMesh packages, some of these
> packages will select the needed things also for the others. But it could
> be a problem when only a few packages are selected (for example for
> creating a very small firmware image).
>
>
> Fixing the dependencies, I realized that pirania package (the captive
> portal with vouchers) needs shared-state-pirania (for sharing the list
> of the valid vouchers) and that shared-state-pirania needs pirania.
> This is a "circular dependency" which means that the two packages should
> be merged as they cannot work without each other. Or the dependencies
> are wrong? Reported here:
> https://github.com/libremesh/lime-packages/issues/942
>
>
> Once installed re-flashed the router with the new set of dependencies, I
> got a couple of errors: the first happens both with OpenWrt 19.07 and
> the second only with OpenWrt 22.03:
>
> root@OpenWrt:/etc/opkg# opkg install lime-system
> [...]
> /usr/bin/lua: /usr/bin/migrate-wifi-bands-cfg:38: bad argument #1 to
> 'pairs' (table expected, got nil)
> [...]
> /usr/lib/lua/lime/utils.lua:17: bad argument #2 to 'format' (string
> expected, got nil)
> [...]
>
>
> The first one is just caused by a script looking for some files that do
> not exist yet, reported here:
> https://github.com/libremesh/lime-packages/issues/945
>
>
> The second error is much more interesting, and it could be the reason
> why Batman-adv was not working when people tried LibreMesh on top of
> OpenWrt 21.02, see Gothos' email here:
> https://lists.autistici.org/message/20221017.205236.2d9481ea.en.html
> What happened is that OpenWrt 19.07 used "swconfig" as a configuration
> syntax for switches (the ethernet ports), but since OpenWrt 21.02,
> swconfig has been replaced by "DSA" which has a different syntax. This
> means that the configuration that was created by LibreMesh for swconfig
> is not understood by DSA.
> This has been reported here:
> https://github.com/libremesh/lime-packages/issues/944
>
> and, in order to fix, quite a lot of understanding of the networking
> mechanisms in LibreMesh is needed, can anyone try to fix this?
>
> Ciao!
> Ilario
>
>
>
>
> --
> Ilario
> iochesonome@???
> ilario@???
>
>
>
>
>
> --
> LibreMesh mailing list
> LibreMesh@???
> https://www.autistici.org/mailman/listinfo/libremesh
>
