Goodcloud crashing not working on 4.48 X3000 custom build

Router
1

Hi,

I have a custom build of 4.4.8 using the glbuilder repo. It all works well apart from goodcloud. When I enable it via the admin panel, I do not see the device show up on the good cloud web panel, even after adding it manually. I see these crashes in the logs:

Tue May 21 13:46:38 2024 daemon.err eco: (...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud: 30) ...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud:683: bad argument #1 to 'bor' (number expected, got nil)
Tue May 21 13:46:43 2024 daemon.err eco: (...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud: 30) ...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud:683: bad argument #1 to 'bor' (number expected, got nil)
Tue May 21 13:47:11 2024 daemon.err eco: (...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud: 30) ...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud:683: bad argument #1 to 'bor' (number expected, got nil)
Tue May 21 13:47:16 2024 daemon.err eco: (...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud: 30) ...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud:683: bad argument #1 to 'bor' (number expected, got nil)
Tue May 21 13:47:21 2024 daemon.err eco: (...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud: 30) ...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud:683: bad argument #1 to 'bor' (number expected, got nil)
Tue May 21 13:47:26 2024 daemon.err eco: (...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud: 30) ...kg-aarch64_cortex-a53/gl-sdk4-cloud/usr/bin/gl-cloud:683: bad argument #1 to 'bor' (number expected, got nil)
Tue May 21 13:47:26 2024 daemon.info procd: Instance gl-cloud::instance1 s in a crash loop 6 crashes, 0 seconds since last crash

However Goodcloud works if I use stock 4.4.8 firmware. Both seem to have the exact same version of the glcloud package.

Here is the file I use in /etc/uci-defaults to configure good cloud on first run for the custom firmware:

#!/bin/sh

uci set glconfig.brand=service

uci commit glconfig

uci set gl-cloud.@cloud[0].enable="1"
uci set gl-cloud.@cloud[0].server="gslb-eu.goodcloud.xyz"

uci commit gl-cloud

uci set rtty.general.ssh_en="1"
uci set rtty.general.web_en="1"

uci commit rtty

/etc/init.d/gl-cloud restart
2

Maybe you can try to use the original version of gl-cloud?

/etc/init.d/gl-cloud stop && rm /usr/bin/gl-cloud && wget https://github.com/Admonstrator/glinet.forum/raw/main/upload/gl-cloud -O /usr/bin/gl-cloud && /etc/init.d/gl-cloud start
3

Thank you, I tried that version you posted.

There are no longer crash reports in the logs, however when I add the device it only shows as offline with very old information in GoodCloud from when I had stock firmware installed. Things I tried with no effect:

  • Deleting and re-adding the device in Goodcloud.
  • Reactivating the device in Goodcloud
  • Rebooting the device
4

I tried something else after this: reinstalling via opkg:

opkg update
opkg remove gl-sdk4-ui-cloud
opkg remove gl-sdk4-cloud
opkg install gl-sdk4-cloud
opkg install gl-sdk4-ui-cloud

Here's the new error i get in the logs:

Tue May 21 14:43:12 2024 daemon.debug eco: (/usr/bin/gl-cloud:186) fetch server:	https://gslb-eu.goodcloud.xyz/gslb/getbucket?deviceType=1&mac=xxxxxxxxx&sn=xxxxxxxxx&ddns=xxxxx&timestamp=1716302592&sign=xxxxxxxx
Tue May 21 14:43:12 2024 daemon.err eco: (/usr/bin/gl-cloud:211) fetch server fail:-5	tls device info invalid
Tue May 21 14:43:12 2024 daemon.err eco: (/usr/bin/gl-cloud:396) reconnect mqtt in 5s...
5

2 idea about this:

  1. You may need to rebind the device.
  2. The device authenticates using a certificate stored in the factory partition. If your firmware did not handle this, you may lost your access to GoodCloud because of this.
1 Like
6

What do you mean by rebinding? Reactivating the device in Goodcloud or deleting and re-adding does not solve the issue.

Where is the certificate kept on the factory partition?

7

Can't tell, depends on the device. I don't own a X3000, sorry :frowning:
You can run blkid -t PARTLABEL="factory" -o device to find the partition.

8

I use glbuilder to compile x30004.4.8, and cloud can connect normally. Have you updated the cloud version or its dependent packages?
image

build_dir/imagebuilder-x3000-4.4.8/packages/gl-sdk4-cloud_git-2023.235.39299-78fa26f-1_aarch64_cortex-a53.ipk
9

The 2nd error up there (TLS) is after updating via opkg. The first error (bad argument) is after a fresh install. A fresh install provides the same versions you are seeing:

# opkg list-installed | grep cloud
gl-sdk4-cloud - git-2023.235.39299-78fa26f-1
gl-sdk4-ui-cloud - git-2024.066.22731-4722fee-1

the versions of the dependencies:

libc - 1.1.24-3
lua-eco-mqtt - 68708f08-1
lua-eco-log - 68708f08-1
lua-eco-ubus - 68708f08-1
lua-eco-http - 68708f08-1
lua-eco-ubus - 68708f08-1
gl-sdk4-utils - git-2023.172.35274-5f48e7c-1
libubox20210516 - 2021-05-16-b14c4688-2
libopenssl1.1 - 1.1.1q-1

The nature of the argument suggests that the gl-cloud binary is expecting a conjuration value somewhere that it's not getting somehow.

10

The bug with gl-cloud was introduced with the newest beta of MT6000, maybe this source is one of the parts of your firmware as well.

11

This is for 4.4.8:

lua-eco-mqtt - 2023-08-07-19a6555b-1
lua-eco-log - 2023-08-07-19a6555b-1
lua-eco-ubus - 2023-08-07-19a6555b-1
lua-eco-http - 2023-08-07-19a6555b-1

I agree with admon's view,GitHub - gl-inet/gl-feeds at common .You seem to be using the latest feeds, which have compatibility issues with older versions of cloud.

12

Thanks, this was resolved with a

make imagebuilder/clean
make

and the correct Lua dependencies were installed