I was sniffing the traffic the Comet is sending. Turned out, overall reasonable requests except one thing which kinda bothered me: the stun-server is by default the google one (unless you are from China).
I understand that it might be necessary in some cases, but for a usage in a private network it might not be always necessary and there should be an option to turn it off or to set a custom one.
Future versions may include a command to disable requests to the STUN server.
"May" or "will"? GL.iNet going to have some serious issues if they don't start acting more transparently if they expect to be taken seriously as a competitor to the JetKVM for a major deployment.
Future Version need to have it! Did you know, that the Comet makes around 6000 requests per day to the Stun-Server? Did you know it requests the Good-Cloud around 2000 times per day? I don't want my devices to call home without my permission and I don't see any reason for that. It is not a big deal to fix it or make it configurable.
I understand your frustration about their communication, but it's not fair to claim their not transparent. They fixed a lot of issues like a recent one with latency of microphones. GLN is a company and they need to plan their new features/bugfixes so they don't become a loss or interfere with the development of their other products.
And well,. the JetKVM guys haven't managed to finally bring the product to the market and sell it since over a year via Kickstarter. In other words: the comet is a product I can actually purchase, I know THAT and WHEN it will arrive if I order a comet tonight! I know no person personally who purchased a JetKVM, I*ve seen only YouTubers with it so far, doesn't mean, you can't trust them, but I can't rely on promises of a launch and by the way: the JetKVM cost me more thant the Comet, cause they ask for 20 bucks addtionally to the 69 €. For what? The ship from Germany and I live there, for do they take 4 times the shipping costs it should have???
Anyway, it was not supposed to be a rant over the JetKVM, rather than, why do people hype something which isn't officially yet available?
I think you're missing the point. Perhaps you're new here but at no time does GL.iNet ever disclose their SOHO routers are reliant on closed-sourced/proprietary SDKs like Qualcomm's until you start poking around in this forum. They go to great lengths to make great fanfare about running OpenWrt, however. Once you scratch the surface only then does it become apparent in the the glaring oversights, omissions, misconfigurations, choosing to focus on idiotic feature requests instead of addressing their bloated tech stack.
So now they're doing no better when it comes to the KVM side of things. How do you expect to pass a security audit when you can't even control what servers your devices/infra is dependent on? You better hope you can grep for a conf to edit out that STUN string & hope it's not baked into the binaries.
JetKVM is built with Golang & dev support in mind. That alone places it above the Comet... but I'll be damned if the upcoming Comet Pro's hardware isn't worth hacking the hell out of to get it into a usable state.
TL;DR: I'm sorry you bought the Comet v1 but I didn't make you open your wallet.
I looked into the GLKVM repo (which was very late published). It is based on PiKVM and they cofigured the janus part with two stun options if you are based in China (Xiaomi) or anywhere else (Google):
Of course the JetKVM is great, but my point was, it is not availbable. They did a great job so far with the preorders, but they deliver them atm only in batches and I couldn't wait. When the JetKVM finally arrives in stores, I will most likely get a couple of them.
I am confident, that the GLKVMs can be customised, but they haven't released any documentation for developers. We have access to the Shell, but it is worthless at the moment without any further informations.
Well there you go! And it's just a python script, to boot! A quick sed should take care of this: sed -i.stock 's|stun.l.google.com|my.perferred.stun.server.here.net|g' __init__.py
There'll be a __init__.py.stock to roll back to if need be... & assumes PiKVM at least uses BusyBox's ash as its shell a-la OWRT.
That would seem to depend on how much they adulterate the Upstream sources, in this case PiKVM, like they did with OWRT.
I'll probably do the same. I have a few drops that're headless. The Comet Pro would be ill served in such a use case. I'll use it when video pass-through is required.
This post shows how to override the default STUN server with an override .yaml: Comet sending a lot of DNS requests - #10 by fenri69
Worked for me using my own STUN server on a VPS.
