Thanks Mark for sharing the script!
Maybe, for making the firmware image configuration faster, it can be
enough to do one of the following (without the need for a script):
* provide a file with the desired configuration for menuconfig, like
they do in the LibreRouterOS here [1];
* provide a network-profile with the suggested packages as dependencies.
Maybe we should do both! :)
Advantages of the first: it can deselect packages; it can set a lot of
stuff that otherwise we would be lazy to do by hand, for example some
optional options and strings [2].
Disadvantages of the first: it can get messy quickly and obsolete lines
can stuck there forever (on this topic, help is needed here [3] for
discerning which are the useful lines).
Advantages of the second: it is the default way in LibreMesh to select a
list of packages.
Disadvantages of the second: It cannot deselect packages so that will
have to be done by hand anyway.
Disadvantages of both: if you never do it by hand (selecting the
packages one by one) you don't see what you are including and what else
is there that could be useful.
About the second, I just created a network-profile
"libremesh/suggested-packages"[4], you will find it in the menuconfig under
LibreMesh > network-profile > profile-libremesh-suggested-packages
which selects the packages suggested on the LibreMesh website.
If you want to know more on the network-profiles, check out this new
page on the website [5]!!!!!!
Do you think that we should do also the first?
Do you think we should suggest one of the two in the "development" page
of the website?
Ciao!
Ilario
[1]
https://gitlab.com/librerouter/librerouteros/-/blob/librerouter-1.5/configs/default_config
[2]
https://libremesh.org/development-kernel_vermagic.html
[3]
https://github.com/libremesh/lime-web/issues/103
[4]
https://github.com/libremesh/network-profiles/blob/master/libremesh/suggested-packages/Makefile
[5]
https://libremesh.org/development-network_profiles.html
On 11/9/22 12:18, Mark Birss via LibreMesh wrote:
> 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@??? <mailto:libremesh@krutt.org>> 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
> <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
> <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
> <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
> <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
> <https://github.com/libremesh/lime-packages/issues/927>
> A proposed fix is here:
> https://github.com/libremesh/lime-packages/pull/928
> <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
> <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
> <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
> <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
> <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
> <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
> <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
