Is there a reason that the Comet is sending a lot of DNS requests? My firewall is allowing them so far but since I don't have this device available in the cloud I'm wondering if their is a way to disable the DNS requests?
Block port on it?
I should have asked what the DNS requests were for? Is it the device checking for firmware updates? If so I want those to go through.
But yes blocking the port is an option.
Are you using Wireshark?
No. Pfsense firewall logs are reporting the traffic.
Nevermind I was hoping to hear something from a moderator or at least report the frequent DNS traffic from the device in hopes to learn a little more about what this device is doing on my network. I will figure it out.
Moderators close this post please.
This is a behavior derived from PIKVM, which requests stun.l.google.com approximately every 15 seconds or so. We inherited this kind of behavior
This is done to ensure that the internal network penetration of webrtc can work properly
My Comet is behind a firewall that captures all traffic and running Firmware Release 1.3.0 with the "Cloud Service" disabled. I see the following DNS requests from the Comet:
* 0.pool.ntp.org. (32)
* 1.pool.ntp.org. (32)
* 2.pool.ntp.org. (32)
* 3.pool.ntp.org. (32)
* ipv4.connman.net. (34)
* ntp.tencent.com. (33)
* stun.l.google.com. (35)
* time.cloudflare.com. (37)
* time.windows.com. (34)
Without access to the time servers, I can't use 2FA to log into Comet's web app but this is okay by me as it's on local network. I will continue to monitor for unexpected traffic from my Comet.
1 Like
We still don't know what requests OP is talking about.
Would be useful information you'd think.
Thank you minmie. This answers my question.
(Updated gramar 
)
Hello, I came here specifically because of the issue with stun.l.google.com, which I understand is used for WebRTC H.264. However, I don’t use WebRTC, and I would really appreciate the ability to stop the KVM from querying this server so I don’t have to block it manually.
I do not allow any Google-related services or tracking on my local network — not even for WebRTC DNS resolution. It would be considerate to stop resolving this server when WebRTC is disabled, or at least provide an option to change the STUN server (without needing to override it manually via terminal). Forcing Google services on users without consent is a serious security concern for me. Thank you.
Edit:
I would much prefer an official option to disable this behavior, rather than having to manually disable the kvmd-janus service (1) via terminal.
This service checks my external IP via STUN to prepare for NAT traversal — even though I’m not using WebRTC. That’s absurd, and for me, a major security concern. I do not share my real IP with anyone unless I explicitly choose to.
Edit 2 (i did some digging):
Despite disabling the kvmd-janus service and confirming no active Python processes, outbound DNS queries to stun.l.google.com continued to appear in dns logs. Investigation revealed that Janus-related configuration files were still present under /etc/kvmd/janus/, specifically referencing a WebSocket transport socket (janus.transport.websockets.jcfg). This suggests that Janus components remain partially integrated into the PiKVM stack, potentially invoked indirectly by kvmd or other system-level triggers. Will need to investigate this, but looks like even when janus is not running, some remnants are still trying to resolve STUN server (1). If this behavior is not patched, I’ll be forced to manually edit the stack or isolate Comet from the local subnet — which introduces more complexity than the device is meant to solve. In that case, I’ll likely switch to a different solution that aligns with my security standards and does not violate EU directives concerning DNS sovereignty and user consent.
add these line into /etc/kvmd/override.yaml then reboot
janus:
stun:
host: stun.miwifi.com
port: 3478
retries: 5
retries_delay: 5.0
timeout: 5.0
Now you can modify stun server and check interval
Thanks, I’ll apply the changes — though it’s not a final solution since they’ll need to be reapplied after every firmware update. Still, it’s a step forward. I’m considering creating my own fork of the firmware with a stronger focus on privacy and security (or some after-install script). Unnecessary DNS calls not only compromise privacy, but also strain system resources and contribute to waste heat, which is something I’d like to minimize. With regards, Martin.
Update:
deployed the overide, rebooted now the client hangs on the boot logo rotating to inifinity :). As i am not now at home, i will need to ssh to it and fix it later.
no. override.yaml will survive after each firmware upgarde
This issue originates from the upstream PIKVM. We are not very keen on modifying its default behavior.