Re: [lime] Test results master-ow23.05.2

Delete this message

Reply to this message
Autore: Ilario Gelmetti
Data:  
To: libremesh
Oggetto: Re: [lime] Test results master-ow23.05.2
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

--
Ilario
iochesonome@???
ilario@???