Open PacmanForever opened 3 weeks ago
If the dhcp server on the server which you are monitoring from has gone, would this not mean that UK cannot send notifications out too?
I think a better monitor would be to use the existing push monitor and send checks to a remote UK-instance. This way, your setup is much simpler and less error prawn.
Examples how to build push moitors are here: https://github.com/TUM-Dev/NavigaTUM/issues/1584
The UK machine can have a static IP (which is best for servers) or be inside a docker (which should also have a static ip).
DHCP is a network service that is not required by all devices, it can be very interesting to know if it is functional as AdGuard does:
From what I see, Uptime-Kuma doesnβt currently support monitoring UDP ports (67 for DHCP), which would be useful for checking DHCP availability. Right now, the only UDP monitor available is DNS, which makes sense since monitoring UDP services differs from TCP monitoring.
I tested an nmap command against a Windows DHCP server which provided some useful results.
nmap -sU -p 67 "dhcp-server-address"
This shows the port as "open|filtered," indicating a potential DHCP service response. I stopped the DHCP server and the response changed to a closed state.
You could set up a script (using Bash on Linux or PowerShell on Windows) to run nmap periodically via cron or a scheduled task. The script could then use a push monitor in Uptime-Kuma to send notifications based on the results. Alternatively, you could create a script that monitors the actual DHCP service directly on the host machine and then push results to Uptime-Kuma.
Adding direct DHCP monitoring to Uptime-Kuma might be complex. For Uptime-Kuma to actively request an IP address, a virtual network adapter might need to be built into the application as it would need to send broadcast messages with a virtual mac, which could require substantial development.
I'm not sure this feature will ever be added, but a script should work just fine.
Edit - (Also - regarding your comment "so there must be a way to be able to say which network you want to scan." This isn't possible. A device isn't going to be able to "test" the full functionality of a DHCP server outside of its broadcast domain, but I think you may have been referring to docker networking anyway - with that, I wonder if it's even possible to do this within a container. A client device is sending unicast traffic when attempting to retrieve a DHCP address which I'm not even sure could be accomplished within a docker container.)
π I have found these related issues/pull requests
I have not found a possible previous issue or change request.
π·οΈ Feature Request Type
New monitor
π Feature description
As a user I would like to have a monitor that verifies that the DHCP server is enabled and working properly.
βοΈ Solution
In principle it would be to search if there is a DHCP server on the same network where the application machine is running, but it must be borne in mind that it can be in a docker container, so there must be a way to be able to say which network you want to scan.
β Alternatives
No response
π Additional Context
No response