Hi,
I respond quickly
thanks a lot kevin for the feedback!
For sure for adding the the replacements of ath10k-ct to non-ct, I'll do
it asap
The things to do are already mapped also in gluon
https://github.com/freifunk-gluon/gluon/blob/master/targets/ath79-nand
PS. belle notizie!
The main openwrt attended sysupgrade server has recently been totally
able to build customized libremesh firmware images (it use the openwrt
imagebuilder so watch out for possible small bugs to fix)
The process still doesn't work via 'firmware selector' but one can
formulate a query using the api-gui at
https://sysupgrade.openwrt.org/ui/
There is an example on how to use it in this issue
https://github.com/libremesh/lime-packages/issues/1049 (e.g. one have to
reference all repositories that intend to use)
Remember to include `batctl-default` if you intend to use batman-adv as
it is not correctly selected (and my experience with `batctl-tiny` is
that it doesn't work completely)
From me thanks very much to @aparcar and other folks who contributed to it
On 11/30/23 21:01, Ilario Gelmetti via LibreMesh wrote:
> Thanks Kevin for sharing your experience!!!!
> Some comments in line:
>
> On 11/30/23 12:17, Kevin (UTC+0) via LibreMesh wrote:
>> I used 3 different devices:
>>
>> GL.iNet GL-AR750S ( 128MB Flash! 128MB RAM. 1x2.4GHz 1x5GHz )
>> + Works fine
>> - Doesn't seem to support mesh on 5GHz radio
>
> Mmmh maybe it is because it uses ath10k-ct drivers instead of non-ct
> ones (CandelaTech modified the driver allowing it to be better as AP but
> they removed many other features, like mesh).
>
> @gothos: in the Ansible compiling stuff (this one, I believe
> https://gitlab.com/a-gave/libremesh-ansible-playbooks) can we specify
> that all the ath10k should use the non-ct driver?
>
> For compiling the images used for the network at Wireless BattleMesh v15
> we used this configuration:
> https://github.com/libremesh/network-profiles/blob/master/calafou/outdoor_nongateway/DOTconfig-Plasma_Cloud_PA1200#L10-L11
>
>> - I had to use U-boot to flash the -initramfs-kernel- image first,
>> then sysupgrade to the full image. Going straight from the vendor
>> image to the full image didn't seem to boot correctly.
>> https://openwrt.org/toh/gl.inet/gl-ar750s
>>
>> GL.iNet GL-AR750 ( 16MB Flash. 128MB RAM. 1x2.4GHz 1x5GHz )
>> + Works fine
>> - Doesn't seem to support mesh on 5GHz radio
>> https://openwrt.org/toh/gl.inet/gl-ar750
>
> Very likely the same problem as above.
> Actually, it is surprising that the mesh on the 2.4 GHz interface works.
>
>> GL.iNet GL-MT300N V2 ( 16MB Flash. 128MB RAM. 1x2.4GHz )
>> + Works fine
>> - Only one radio
>> https://openwrt.org/toh/gl.inet/gl-mt300n_v2
>>
>> I used firmware images from https://repo.libremesh.org/selector/ and
>> chose the master-ow23.05.2 option.
>>
>> Internet gateway switchover worked fine: I set four devices in a line
>> A-B-C-D and plugged A into my LAN ethernet and D into my DMZ ethernet.
>> I then connected to the wifi of router B and watched the traceroute to
>> the Internet as I unplugged one cable at a time. The switchover
>> happened within a few seconds of unplugging the cable.
>
> Nice!!!
>
>> There were 2 bugs which caused me trouble:
>> + First boot of the first node gives a blank webpage
>> + First-run wizard doesn't always run, leaving shared password unset
>>
>> Details:
>>
>> + First Boot:
>> The first boot of the first node resulted in a mostly-blank page, with
>> just the node name and a non-functional hamburger menu. Digging into
>> the Javascript console, I found an error:
>> "Uncaught (in promise) TypeError: t.most_active.iface is undefined" in
>> /app/bundle.d2584.js:2
>> Despite that, the node came up fine with default settings, advertising
>> both SSIDs and allowing me to ssh to root@???
>
> Yesss, this is a known issue. It has been fixed in the code of lime-app
> web interface:
> https://github.com/libremesh/lime-app/issues/378
> but the fix has not yet have been included in any release yet.
> The last release is from March 2022
> https://github.com/libremesh/lime-app/releases
> but there is much new code that was not included there.
> We absolutely need a new lime-app release in order to have a new
> LibreMesh release with lime-app (I hope that lime-app developers are
> reading this).
>
>> + First-run wizard
>> Flashing the second node gave a better experience,as (I presume) it
>> detected the first node and was able to calculate the signal strength
>> to the first node. This time the first-boot wizard ran and I was able
>> to set the Network Password. However the 3rd and 4th nodes never ran
>> the first-boot wizard and I can't use the Network Password on those
>> devices.
>
> Wait, what do you mean with "first boot wizard"?
> There is a piece of software, in the lime-packages repository, with that
> exact name, but it is not included in the LibreMesh releases.
> https://github.com/libremesh/lime-packages/tree/master/packages/first-boot-wizard
> Reasons for not including it in the releases are various. From my point
> of view, it has a big bug which is that does work only on dual band
> routers:
> https://github.com/libremesh/lime-packages/issues/661
> and it is designed with a very specific network model in mind (which is
> amazing for many communities, but not for all of them. If you like FBW,
> obviously you can compile images including it).
> So I suppose you refer to the lime-app web interface.
>
>> One other issue I ran into was trying to resolve router names. From a
>> cold boot of all nodes it sometimes takes half an hour before I can
>> reliably ping every router by name. In my test setup above, connecting
>> via WiFi to B, I could connect to the Internet immediately, but
>> pinging router A or D by name only became possible after a few
>> minutes. Router C didn't resolve for 10 mins, but was fine when I
>> tried again after 30 mins.
>
> The IP of each node should be associated to its hostname here:
> https://github.com/libremesh/lime-packages/blob/361645ee5c8ca19a0a60cbea5246708049b582cd/packages/lime-proto-anygw/files/usr/lib/lua/lime/proto/anygw.lua#L96C1-L99
> But then I am not sure which one of the shared-state packages then
> spreads the information to the other nodes.
> Anyway, they run in cron every X minutes, so it is normal that it takes
> time to spread the information.
>
>> I spotted some minor problems with the web app, but I'll submit those
>> as a github issue.
>
> Yes please!
>
>> So I was able to successfully build a network without much trouble,
>> which gives LibreMesh a high rating in my books! Thank you to everyone
>> who made that possible.
>
> Nice :D
>
> Ciao!
> Ilario
>
--
gothos
PGP Key ID: 0x6406B32F2CEC0008
PGP Key server:
https://keys.openpgp.org/
