mirror of
https://github.com/jetkvm/kvm.git
synced 2026-03-02 22:58:00 -05:00
DNS Spam Issue #54
Labels
No labels
component/keyboard-layout
component: cloud
component: device screen
component: extensions
component: hid/keyboard
component: hid/mouse
component: network
component: timesync
component: ui
component: updater
component: usb
component: usb/hid
component: usb/storage
component: video
component: webrtc
component: webserver
need-more-details
status: working-in-progress
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/kvm#54
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ShowSysDan on GitHub (Jan 13, 2025).
Originally assigned to: @ym on GitHub.
I run a network that doesn't have internet with a Mikrotik router in the middle. the inline image below is what I found after a day or two of running JetKVM. The JetKVM device is the .177 making requests to port 53 on the router gateway.
The active connections in on the bottom left of the image, usually we are between 300-500 active connections through the firewall, 25-27k of DNS requests from one little device seems a bit much.
For now I disabled the switch port the JetKVM is connected to and all of those 25k connections cleared out as they timed out.
I understand the device calls home to update firmware, so it would be nice to either just give up if it can't reach out after a bit, or if there was a setting to tell the device that it can't possibly reach out so don't even try.
@exegeteio commented on GitHub (Jan 25, 2025):
@ShowSysDan I saw a similar problem, but all of the requests were NTP related. Can you confirm if you saw the same behavior?
@kashalls commented on GitHub (Jan 29, 2025):
Is this a clean session (where you logged in and are just sitting infront of a screen?) or have you used the kvm a little bit?
Sitting at
/locally, I see the normal MDNS, SRTCP, STUN and other traffic on my local ethernet. Same thing for remote cloud.@yferszt commented on GitHub (Jan 29, 2025):
I have observed that just having the JetKVM connected to the network is enough to have the DNS spam issue. Just verified it.
Setup: Isolated VLAN without access to DNS or Internet.
@kashalls commented on GitHub (Jan 29, 2025):
That seems like a setup issue then... Considering that it should only be using the IP provided by the DHCP Server (which looks like its your own router).
Codebase wise, this lines up with what the kvm tries to do and register with the cloud service by default. A better behavior would be to only start up if configured with a cloud address.
See: https://github.com/jetkvm/kvm/blob/main/cloud.go#L121C25-L121C29, and the auto-updater + oidc.
@Nevexo commented on GitHub (Jan 29, 2025):
https://github.com/jetkvm/kvm/pull/27
@yferszt commented on GitHub (Jan 29, 2025):
I am not sure what you mean with that. The JetKVM spams my own gateway with DNS queries.
Configuration:
JetKVM uses DHCP and gets 192.168.192.100
I did not configure any cloud services on the JetKVM.
Gateway: 192.168.192.1
Additionaly I think that the NTP is hardcoded in the JetKVM. In my opinion JetKVM should have 2 modes. Mode 1 is getting all settings from DHCP. Mode 2 shoud let us specify all network parameters.
@Nevexo commented on GitHub (Jan 29, 2025):
Yeah lots of discussion around this, it'll get some form of manual network config options soon, and it certainly shouldn't have the NTP servers hardcoded like it does.
@yferszt commented on GitHub (Jan 29, 2025):
That would be great.
@kashalls commented on GitHub (Jan 29, 2025):
Your default deny rule prevents any DNS from being resolved, at all. That's all I meant by it.
@yferszt commented on GitHub (Jan 29, 2025):
Yes, this is how I test new devices on my network. Block all and see how they behave and where they try to go.
@apalrd commented on GitHub (Feb 12, 2025):
I think we should reduce the sleep time down from 1 hour to something in the range of 5 seconds. The time task isn't dependent on the network being 'up', so the first attempt will always fail. If we delay 1 hour on failure, we will never get time for the first hour.
Failure can also be due to any number of network reasons and not necessarily the network blocking the request.
@dontcrash commented on GitHub (Jul 21, 2025):
This was closed complete, but wondering if there has been a regression.
App: 0.4.6
System: 0.2.5
@ym