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 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 local5
http://192.168.1.2:8000/packages/mipsel_24kc/profiles
src/gz local6
http://192.168.1.2:8000/packages/mipsel_24kc/routing
src/gz local7
http://192.168.1.2:8000/packages/mipsel_24kc/telephony
src/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@???
