Support for firmware 4.0 and 4.1

Hi Guys any news on when we can use goodcloud for managing remote routers rubbing 4.0 and 4.1 and if that is not on the table for now for someone who isn’t very much a techy what can i do to manage them from a different geographic region.
Thank you

What model of device do you have? 4.x firmware for AXT1800 and AX1800 is already supported on GoodCloud. 4.1 firmware may have some bugs that will be fixed this month.

I have both devices but the main issue is have is when i updated the MT-1300 to 4.1 its always showing offline unless i am physically on the same network
Any help to get that back up and running would be appreciated
Thank you

Did you go back and reauthorize GoodCloud in the GL.iNet UI? Found mine was off after upgrade.

1 Like

I did that and also did an unbind and rebind along with removing it off good cloud and back on again but no cigar … it can see the IP address of the device just not being connected to the system even though it is online
BR

What is the status of Goodcloud admin console and ssh access support for 4.x firmware?

Like the OP I’m still unable to ssh or access the admin console still, using Goodcloud for my AX1800 on 4.1

Is this a known issue and is there an ETA on a fix?

Goodcloud SSH has always worked for me in 4.x. It can tack a couple of tries to connect because of the distance and timing out. I also find that a restart is needed after setting up the routers goodcloud connection

This issue should have been fixed. Is there any indication on the page when access fails?

This is one of a number of known issues with goodcloud connections. We plan to rebuild this feature in version 4.3 to fix them.

Yes; when ssh session is attempted from Goodcloud, the new browser tab pops up with text “Loading…”.
Within 1 sec, the new tab closes and on original Goodcloud page a popup at the top of the page appears with Failed to Connect.

When trying to do the same with the webadmin console, the same thing happens, however the error message is different, instead it shows “Request Timed Out”, however both of these popups occur within 1-2secs of attempting the connection.

I have tried to clean the slate by:
Unbinding the router from Goodcloud, and disabling Goodcloud on the router.
Confirming the router has been removed from the Goodcloud dashboard, and logging out of Goodcloud.
Rebooting the router, then reenabling Goodcloud and reenabling both ssh and webadmin.
Adding the device back into Goodcloud, and confirming the icons for ssh and webadmin appear.
Rebooting the router again for good measure
Attempting ssh and webadmin from Goodcloud; still with the same failed result.

Running the 4.1 firmware on the AX1800

  • Openwrt Version

OpenWrt 21.02-SNAPSHOT r16399+157-c67509efd7

  • Kernel Version

4.4.60

Any advice?

Do you have VPN enabled?
Can you check the logs on the firmware?

Hello,

Same issue here with AXT-1800 and AX-1800 (release 4.1 stable).

On the Slate, I see a huge amount of this error in the logs:

Sat Jan 21 20:45:26 2023 daemon.err mqtt[22503]: Connect failed, rc -1
Sat Jan 21 20:45:26 2023 daemon.err mqtt[22503]: === === ===> disconnect handle

I tried to unbind the Slate, but no matter what I do, it always says that the router is bound, even though I deleted it from the GoodCloud dashboard.

No VPN running, ADguard also switched off in case.
Enabling SSH for Goodcloud on the router shows

But subsequently refreshing Goodcloud, SSH icon appears, clicking the icon fails immediately as before.
Refresh the logs on the router; No additional entries in the logs on the router. No Errors.

I noticed the router must be connected to Goodcloud when you click the Unbind from the Router interface. Otherwise if you unbind the router while not connected to Goodcloud it does nothing.
Im not seeing a lot of errors in mine, perhaps need to up the logging level?
Just checked logging level in Luci, and already set to Debug, so if there were any errors I should be seeing them.

Indeed, with GoodCloud enabled, I can unbind the device.
So, I’ve done the following steps:

  • Unbind the device (with GoodCloud activated). The device disappears from GoodCloud dashboard.
  • Deactivate GoodCloud.
  • Reboot.
  • Reactivate GoodCloud.
  • Add the device again in the GoodCloud dashboard.

With all these steps done, I can now access Slate and Flint SSH & WebUI through GoodCloud.
Strangely, I have to try two times before it works, the first time I click to access the WebUI, I get a Request timed out message.

Tried your steps:
Unbinding/Rebinding seems to make no difference for me; still the same behaviour as above.
Are you also getting Failed to Connect message when connecting via SSH from Goodcloud?

Interestingly I found this on the forums; seems like I’m not the 1st person to have experienced this - is it possibly a Goodcloud account issue?
Appears the OP in this thread had help from Gl.inet staff to fix, so wondering if this might be related also.

I just tried SSH again, it worked, but I had to try three times, the first two were showing a Failed to Connect message.

I don’t know how the connection is made between the device and GoodCloud, is there some sort of tunnelling that needs to be set up before being able to access SSH or WebUI ?

I saw these entries in the log after accessing the router on the Dashboard:

Sun Jan 22 13:38:37 2023 daemon.debug rtty: (main.c:276) rtty version 8.0.1
Sun Jan 22 13:38:37 2023 daemon.debug rtty: (main.c:145) config: term Enabled
Sun Jan 22 13:38:37 2023 daemon.debug rtty: (main.c:146) config: http Enabled
Sun Jan 22 13:38:38 2023 daemon.debug rtty: (rtty.c:629) connected to server
Sun Jan 22 13:38:38 2023 daemon.debug rtty: (rtty.c:433) register success

There was a bug in the SSH service for a short time which prevented it from being used with slightly higher latency. But these have been fixed.

Can you see any error about rtty in System Logs when this happens?

When I spam the Webadmin console button in Goodcloud; I eventually get the following rtty messages in the SysLog:
Mon Jan 23 13:19:01 2023 daemon.debug rtty: (main.c:276) rtty version 8.0.1
Mon Jan 23 13:19:01 2023 daemon.debug rtty: (main.c:145) config: term Enabled
Mon Jan 23 13:19:01 2023 daemon.debug rtty: (main.c:146) config: http Enabled
Mon Jan 23 13:19:01 2023 daemon.debug rtty: (rtty.c:629) connected to server
Mon Jan 23 13:19:02 2023 daemon.debug rtty: (rtty.c:433) register success

However in Goodcloud this is still failing to set up the connection, and the Request Timed Out popup message displays every time.

It appears the router at least thinks its made a connection judging by these log entries, but it seems this is falling over at the Goodcloud end. Why the router reports success and Goodcloud reports Request Timed Out is a mystery to me.

When doing the same with SSH button in the Goodcloud interface, no rtty log entries appear in the SysLog, only when performing multiple connection attempts to webadmin do these messages appear. Attempting SSH connection still produces the Failed to Connect popup which is different error to webadmin.

After 10 minutes I get the following message that rtty has timed out
Mon Jan 23 13:29:01 2023 daemon.err rtty: (rtty.c:660) long long inactive for 10 minutes, now exit.

Seems Goodcloud is reporting the http connection as failing, even though the router reports successful connection.

NOTE: Im now off-site, so I am accessing router logs connecting to WG VPN that I’ve enabled. I thought I’d mention this as @yuxin.zou you asked this question re VPN before so I thought I’d mention this has changed in terms of the usecase (obviously I have no other way to manage the router remotely now other than VPN in, as I’d be reluctant to leave other ports open naturally). Obviously this has made no difference in the behaviour I’m seeing however.