Two comets same network glkvm.local?

KVM
1

Recieved my comet, and am experiencing some issues:
Binded to the app, when I try to launch it fails to connect at 70% and just times out. Is this because I'm under the same LAN? Some setting I'm not considering?

Was able to upgrade the firmware by going to glkvm.local though. Now, I want to have two comets in the same LAN, connected to two computers. Any way to change its default URL to something different? How would I know which glkvm.local to connect to? / should I just rely on the IP?

Lastly, can I just install the GLKVM app in any computer and remote log in to the comet without tailscale?.
Thanks,

2

the APP conection is still at 70% after the upgrade？
For now maybe IP access is better way.
the last question is Yes. we have embed Wireguard inside the KVM app

3

Huzzah, the Windows version of GLKVM works...

The opposite of huzzah... literally the ONLY thing the GLKVM app seems to be doing is talking to the astrocloud/goodcloud API to get a list of devices associated with the logged in account.

It uses that to the connect via HTTPS directly to the KVM's web interface... and it proxies that and does nothing else.

At this point my take is that I'll be better of just using a browser to connect directly to my KVM device/s.

The GLKVM app doesn't work on MacOS, and doesn't really make using the KVM based GUI into the device any better or easier.

Also worth noting... you can only be logged in via one GLKVM app at a time. If you login from a different system the other instance/s of the app will disconnect and logout.

1 Like
4

After checking what's happening on the network,

  1. Discovery of KVM devices relies on Multicast DNS (MDNS). If your router does not filter MDNS they will be discoverable in the same VLAN/network, and if your router supports this between routed networks then KVM devices will be discoverable regardless of whether or not you're in the same VLAN and network.

e.g. a DNS PTR query for _glinet._tcp._local to 224.0.0.251 can be sent by the GLKVM app

e.g. KVM devices reply to queries for _glinet._tcp._local with a series of answers which includes TXT, SRV, A and NSEC records. Two names are involved, e.g . GL-RM1-0ab._glinet.local and glkvm-N.local where N seems to be dynamically assigned somehow. The TXT response in particular includes fields for mn, t, G, p, v (protocol version? e.g. 0.1.0), devid, mac, and inited (boolean, indicates initialisation state?). The SRV record refers to the other name, e.g. the SRV record for GL-RM1-0ab._glinet.local points to glkvm-2.local with priority=0, weight=0 and port=443.

KVM devices may also send unsolicited answers for MDNS queries for the name _glinet._tcp._local.

I have three devices though, and after adding all three to the GLVM app successfully one is still showing as discoverable... this is also the only one is responding to MDNS queries.

It seems as though after initial setup they're actually supposed to stop responding to MDNS perhaps?

  1. The GLKVM app is requesting DNS answers for m-kvm-api.astrowarp.net which CNAME's to a GoodCloud AWS ELB, e.g.

m-kvm-api.astrowarp.net: type CNAME, class IN, cname goodcloud-ingress-production-382809285.us-east-1.elb.amazonaws.com

That name resolves to IPv4 addresses only, there are no IPv6/AAAA records associated.

user@box ~ % dig A goodcloud-ingress-production-382809285.us-east-1.elb.amazonaws.com +short 35.153.90.71 54.86.85.179 user@box ~ % dig AAAA goodcloud-ingress-production-382809285.us-east-1.elb.amazonaws.com +short user@box ~ %
I'm have both IPv4 and IPv6 in my network so I was wondering if this was an issue. But given the above this doesn't seem to be an issue.

  1. I cannot see the GLKVM app attempting to directly connect to the KVM units I have AT ALL.

There is completely zero network traffic directly to the KVM devices even though GLKVM app is aware of their internal IP's.

It ONLY ever seems to use MDNS, and talk to the astrocloud/goodcloud API endpoint, and then does nothing useful at all.

No other real network activity comes out of the GLKVM app when trying to open a remote GUI window to it, this includes before and after it stalls at 70% when trying to load something in that window.

I'm on MacOS, the GLKVM app reports it's version to be V1.0.0 Release 1. That is the latest version available via the Apple app store.

I'm about to try the Windows version of the GLKVM app, but don't have high hopes it'll be any different.

2 Likes
5

I'm seeing the same thing with the GLKVM app failing to connect properly and stalling at 70%.

Access via the HTTPS web interface on each KVM works fine though.

I have three in the same LAN without issue, you should probably configure your router to give them static IP's and if possible unique hostnames, e.g. glkvm1.local, glkvm2.local etc. Most routers support something like that these days.

2 Likes
8

Do you have a way to install the official wireguard client in your Window PC? You can use the wg command to view the client wireguard configuration. When glkvm is stuck at 70%, can you check the glkvm tunnel IP and directly access tunnel IP in the browser?

If you don't know how to do the above steps or still cannot access the tunnel IP in the browser. Please follow the steps below to provide us with the logs of the client and kvm device. Once we receive the data, we will quickly help you locate and solve the issue.

Step 1: Enable Debug Logging on the KVM Device

:white_check_mark: What to do:

  1. Try opening your kvm web page in your browser:

Log into your router’s admin page and check your KVM device's local IP address (for example: 192.168.28.124 ).

image
image1049Ă—361 20.9 KB

  1. Enter that IP in your browser, log in using your password, then click “Access” to open the terminal.

image
image373Ă—1034 28.3 KB

  1. In the terminal, copy and paste this command and press Enter:

sed -i 's/"log_level":"[^"]*"/"log_level":"DEBUG"/' /etc/glinet/gl-cloud.conf

:bulb: Tip: This enables debugging logs. It won’t affect how the device works.

image
image744Ă—255 3.36 KB

Step 2: Install WireGuard on Your PC (for connection analysis)

  1. Visit the official download page:：Installation - WireGuard

image
image1536Ă—696 66.4 KB

  1. Click the Windows version to install.

:jigsaw: We’ll use this tool to check your connection status later.

Step 3: Reproduce the device Issue and Collect Info

:rotating_light: Important:

Open the remote desktop again and wait for the issue to happen. Only continue with the steps below after the issue occurs.

If you find that your client is stuck at 70%, please keep the stuck status and follow the steps below to export the logs.

:pushpin: Part A: Collect Information from the KVM Device

  1. In the KVM terminal, run the following commands one by one and take a screenshot of each output:
wg show

image
image731Ă—440 14.1 KB

  1. Then generate a log file by running command:

logread | grep gl-p2p-daemon > /userdata/media/gl-p2p-daemon.txt

image

  1. Go back to the main web page and download the gl-p2p-daemon.txt file.

image
image747Ă—533 36.8 KB

:pushpin: Part B: Collect Information from Your Windows PC

  1. On Your Windows PC，press the Win key, type cmd , then right-click and Run as administrator.

image
image768Ă—719 59.7 KB

  1. In the Command Prompt, enter:
wg show

image
image648Ă—462 17 KB

  1. Take a screenshot of the output.

  2. Then go to the log folder (depending on your username and install location):

C:\Users\<YourUsername>\AppData\Local\Temp\GLKVM\log

Example: C:\Users\Admin\AppData\Local\Temp\GLKVM\log

image
image827Ă—272 11 KB

Look for a file named something like glkvm_log.txt and save it.

If the file doesn’t exist, no problem — you can skip it.

:white_check_mark: Final Step: Send These Files to us

Please send us the following:

  • The screenshot of wg show output from your PC

  • The glkvm_log.txt file (if available)

  • The screenshot of wg show from the KVM terminal

  • The gl-p2p-daemon.txt log file from the KVM device

Once we receive the information, we’ll help you resolve the issue as soon as possible.
Thank you for your support and cooperation!

9

For the last question:

  1. If you have a public IP address, you can access it by forwarding the comet 443 port to the public network.
  2. If you don't have a public IP address, you need to purchase a VPS to build an internal network penetration service, such as frp, or use an open-source and free one, like ngrok

However, all of the above require that the network where comet is located is NAT1. Otherwise you can only access the website but video stream

10

The IP might be better if you reserved ip addresses based on mac address. Otherwise a hosts file entry could do. Kinda have to remember hosts l.