starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

No option for UDP port check #5

New issue

Closed

opened 2026-02-28 01:31:26 -05:00 by deekerman · 21 comments

deekerman commented

2026-02-28 01:31:26 -05:00

Owner

Originally created by @0mni on GitHub (Jul 11, 2021).

Would love to have a UDP port check.

Originally created by @0mni on GitHub (Jul 11, 2021). Would love to have a UDP port check.

deekerman

2026-02-28 01:31:26 -05:00

closed this issue
added the
wontfix
label

deekerman commented

2026-02-28 01:31:31 -05:00

Author

Owner

@louislam commented on GitHub (Jul 11, 2021):

I cannot find a suitable node.js library can do that. I guess UDP port checking is not possible technically.

@louislam commented on GitHub (Jul 11, 2021): I cannot find a suitable node.js library can do that. I guess UDP port checking is not possible technically.

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@0mni commented on GitHub (Jul 12, 2021):

I did some checking on how statping is able to check, it seems to follow the same process as UDP, will do some quick tests.

Also did some quick googling, its not always possible apparently, can get false positives depending on how the firewall is configured.

https://stackoverflow.com/questions/9265669/how-to-test-a-remote-udp-port/9265820#9265820

@0mni commented on GitHub (Jul 12, 2021): I did some checking on how statping is able to check, it seems to follow the same process as UDP, will do some quick tests. Also did some quick googling, its not always possible apparently, can get false positives depending on how the firewall is configured. https://stackoverflow.com/questions/9265669/how-to-test-a-remote-udp-port/9265820#9265820

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@0mni commented on GitHub (Jul 12, 2021):

I just checked on my statping server, the check it does, does not work at all ... took down openvpn and it didn't register a change at all.

@0mni commented on GitHub (Jul 12, 2021): I just checked on my statping server, the check it does, does not work at all ... took down openvpn and it didn't register a change at all.

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@louislam commented on GitHub (Jul 12, 2021):

I just checked on my statping server, the check it does, does not work at all ... took down openvpn and it didn't register a change at all.

Yes, UDP monitoring is not 100% reliable according to your stackoverflow link and my research. So I marked this issue as "wontfix"

@louislam commented on GitHub (Jul 12, 2021): > I just checked on my statping server, the check it does, does not work at all ... took down openvpn and it didn't register a change at all. Yes, UDP monitoring is not 100% reliable according to your stackoverflow link and my research. So I marked this issue as "wontfix"

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@0mni commented on GitHub (Jul 12, 2021):

Yah, probably not worth spending time on it, but will keep it in the back of my mind, maybe a solution will present it self for specific services, such as Openvpn?

@0mni commented on GitHub (Jul 12, 2021): Yah, probably not worth spending time on it, but will keep it in the back of my mind, maybe a solution will present it self for specific services, such as Openvpn?

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@choffmeister commented on GitHub (Oct 12, 2021):

@louislam I just found this thread. Since I would like to check my teamspeak server (which is UDP), I would be highly interested in this. Looks like since NodeJS 16 (maybe even earlier) there is UDP connectivity available: https://nodejs.org/api/dgram.html.

Maybe this changes nothing, because UDP checking being unreliable is still the main reason to not do it. Just wanted to point out, that now there is an UDP API for NodeJS.

@choffmeister commented on GitHub (Oct 12, 2021): @louislam I just found this thread. Since I would like to check my teamspeak server (which is UDP), I would be highly interested in this. Looks like since NodeJS 16 (maybe even earlier) there is UDP connectivity available: https://nodejs.org/api/dgram.html. Maybe this changes nothing, because UDP checking being unreliable is still the main reason to not do it. Just wanted to point out, that now there is an UDP API for NodeJS.

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@louislam commented on GitHub (Oct 12, 2021):

@louislam I just found this thread. Since I would like to check my teamspeak server (which is UDP), I would be highly interested in this. Looks like since NodeJS 16 (maybe even earlier) there is UDP connectivity available: https://nodejs.org/api/dgram.html.

Maybe this changes nothing, because UDP checking being unreliable is still the main reason to not do it. Just wanted to point out, that now there is an UDP API for NodeJS.

Not true, UDP was supported in Node.js 0.x.

The problem is that UDP server can ignore Uptime Kuma's request like the picture of above meme. Uptime Kuma never know what should be sent in order to get a response from a UDP server.

@louislam commented on GitHub (Oct 12, 2021): > @louislam I just found this thread. Since I would like to check my teamspeak server (which is UDP), I would be highly interested in this. Looks like since NodeJS 16 (maybe even earlier) there is UDP connectivity available: https://nodejs.org/api/dgram.html. > > Maybe this changes nothing, because UDP checking being unreliable is still the main reason to not do it. Just wanted to point out, that now there is an UDP API for NodeJS. Not true, UDP was supported in Node.js 0.x. <img width="300" src="https://user-images.githubusercontent.com/1336778/136912486-5248e42f-2ff7-434f-aab9-566fd1190b55.png" alt> The problem is that UDP server can ignore Uptime Kuma's request like the picture of above meme. Uptime Kuma never know what should be sent in order to get a response from a UDP server.

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@choffmeister commented on GitHub (Oct 12, 2021):

Ah, then I misread your comment

I cannot find a suitable node.js library can do that. I guess UDP port checking is not possible technically.

I understood, that there is no UDP API. But you meant there is no way to check if an UDP packet arrived. My bad 😄

@choffmeister commented on GitHub (Oct 12, 2021): Ah, then I misread your comment > I cannot find a suitable node.js library can do that. I guess UDP port checking is not possible technically. I understood, that there is no UDP API. But you meant there is no way to check if an UDP packet arrived. My bad :smile:

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@Medath commented on GitHub (Jan 3, 2022):

Measuring the uptime of (some) UDP based services is definitely possible, but it's not as simple as just picking a hostname and a port.

What's necessary is the ability to specify a hardcoded UDP payload that should be sent in the packet. If we receive a response to that packet it means the service is up, if there was no response after a timeout it's down. Similar to the HTTPS Keyword monitor the UDP monitor could also check for specific byte sequences in the response.

Using Teamspeak3 as example, sending \x54\x53\x33\x49\x4e\x49\x54\x31\x00\x65\x00\x00\x88\x0e\xdc\x3a\xe6\x00\x61\xd3\x7f\x2c\x2b\x73\x10\xd8\x00\x00\x00\x00\x00\x00\x00\x00 to a Teamspeak3 server will cause a response immediately. I took that byte sequence from a Wireshark capture when connecting to a Teamspeak3 server. This approach works for many game servers too.

It wouldn't be very clean and it wouldn't cover all UDP based applications, but it would be nice to have

@Medath commented on GitHub (Jan 3, 2022): Measuring the uptime of (some) UDP based services is definitely possible, but it's not as simple as just picking a hostname and a port. What's necessary is the ability to specify a hardcoded UDP payload that should be sent in the packet. If we receive a response to that packet it means the service is up, if there was no response after a timeout it's down. Similar to the HTTPS Keyword monitor the UDP monitor could also check for specific byte sequences in the response. Using Teamspeak3 as example, sending `\x54\x53\x33\x49\x4e\x49\x54\x31\x00\x65\x00\x00\x88\x0e\xdc\x3a\xe6\x00\x61\xd3\x7f\x2c\x2b\x73\x10\xd8\x00\x00\x00\x00\x00\x00\x00\x00` to a Teamspeak3 server will cause a response immediately. I took that byte sequence from a Wireshark capture when connecting to a Teamspeak3 server. This approach works for many game servers too. It wouldn't be very clean and it wouldn't cover *all* UDP based applications, but it would be nice to have

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@khord commented on GitHub (Jan 13, 2022):

How about netcat?

https://www.npmjs.com/package/netcat

❯ nc -vu vpn.example.com 1194
Connection to vpn.example.com 1194 port [udp/openvpn] succeeded!

@khord commented on GitHub (Jan 13, 2022): How about netcat? https://www.npmjs.com/package/netcat ``` ❯ nc -vu vpn.example.com 1194 Connection to vpn.example.com 1194 port [udp/openvpn] succeeded! ```

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@Medath commented on GitHub (Jan 13, 2022):

netcat can indeed in some cases detect if something is not listening on a udp port.

Depending on the system configuration, some end systems respond with an icmp packet if they receive a udp packet on an unavailable port to signal an error. If this happens, netcat just exits with no output and it can be safely interpreted as a service being down.
However, many systems are configured not to send these icmp error messages. In that case netcat will just always say the connection succeeded, even when nothing is actually listening on that port. nc -vu example.com 1 will "succeed" just like nc -vu example.com 12345. Even when your server is entirely offline or doesn't exist, netcat will say the connection succeeded nc -vu 192.123.123.123 1234.

@Medath commented on GitHub (Jan 13, 2022): netcat can indeed in some cases detect if something is not listening on a udp port. Depending on the system configuration, some end systems respond with an icmp packet if they receive a udp packet on an unavailable port to signal an error. If this happens, netcat just exits with no output and it can be safely interpreted as a service being down. However, many systems are configured not to send these icmp error messages. In that case netcat will just always say the connection succeeded, even when nothing is actually listening on that port. `nc -vu example.com 1` will "succeed" just like `nc -vu example.com 12345`. Even when your server is entirely offline or doesn't exist, netcat will say the connection succeeded `nc -vu 192.123.123.123 1234`.

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@MadWalnut commented on GitHub (May 25, 2022):

@choffmeister Since TeamSpeak has been mentioned in this issue I wanted to share my workaround. Instead of checking the main TS3 port I setup Uptime Kuma to check the ServerQuery ports on 10011 or 10022. These are TCP. Of course those have to be open on the firewall, but maybe it works for you.

@MadWalnut commented on GitHub (May 25, 2022): @choffmeister Since TeamSpeak has been mentioned in this issue I wanted to share my workaround. Instead of checking the main TS3 port I setup Uptime Kuma to check the ServerQuery ports on 10011 or 10022. These are TCP. Of course those have to be open on the firewall, but maybe it works for you.

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@hexxone commented on GitHub (Sep 24, 2023):

FYI, if the ServerQuery ports are not available (in my case), you might have luck with the "FileTransfer" Port 30033 instead (which is also TCP). In the ts3 docs it is listed as "required", so most servers should technically expose it.
Cheers.

@hexxone commented on GitHub (Sep 24, 2023): FYI, if the ServerQuery ports are not available (in my case), you might have luck with the "FileTransfer" Port `30033` instead (which is also TCP). In the ts3 docs it is listed as "required", so most servers should technically expose it. Cheers.

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@FrancYescO commented on GitHub (Jan 25, 2024):

What about to implement something like
https://serverfault.com/a/470065

basically for UDP servers that (should...) give specific/predicible response when a specific payload sent?

@FrancYescO commented on GitHub (Jan 25, 2024): What about to implement something like https://serverfault.com/a/470065 basically for UDP servers that (should...) give specific/predicible response when a specific payload sent?

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@addohm commented on GitHub (Feb 28, 2024):

I'd also really like to see this implemented.

@addohm commented on GitHub (Feb 28, 2024): I'd also really like to see this implemented.

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 28, 2024):

The problem is that UDP server can ignore Uptime Kuma's request like the picture of above meme. Uptime Kuma never know what should be sent in order to get a response from a UDP server.

@addohm
I don't see how what you want is technically possible.
What you likely want is really custom
=> using the push monitor is likely a better usecase.

If it can be demonstrated that our assumptions about UDP not being a reliable monitor are wrong, we can talk about how. Currently, I don't see how any protocol via UDP can meet the reliability needs of an uptime monitor. (how would we know something is DOWN? UDP does not have packets that need to be send back like TCP..)

@CommanderStorm commented on GitHub (Feb 28, 2024): > <img alt="" width="300" src="https://user-images.githubusercontent.com/1336778/136912486-5248e42f-2ff7-434f-aab9-566fd1190b55.png"> > > The problem is that UDP server can ignore Uptime Kuma's request like the picture of above meme. Uptime Kuma never know what should be sent in order to get a response from a UDP server. @addohm I don't see how what you want is technically possible. What you likely want is really custom => using the push monitor is likely a better usecase. If it can be demonstrated that our assumptions about UDP not being a reliable monitor are wrong, we can talk about how. Currently, I don't see how any protocol via UDP can meet the reliability needs of an uptime monitor. (how would we know something is `DOWN`? UDP does not have packets that need to be send back like TCP..)

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@FrancYescO commented on GitHub (Feb 28, 2024):

@CommanderStorm like in my example, there are services (and we want to monitor services not the "naked" UDP protocol...) that give some kind of reply (see OpenVPN example..)

If sometime the ack from the service is lost due to the unreliable UDP protocol is up to the user to adjust the already-here retry parameters

ie. Also DNS monitor is using UDP Transport but we have a specific monitor for it...

@FrancYescO commented on GitHub (Feb 28, 2024): @CommanderStorm like in my example, there are services (and we want to monitor services not the "naked" UDP protocol...) that give some kind of reply (see OpenVPN example..) If sometime the ack from the service is lost due to the unreliable UDP protocol is up to the user to adjust the already-here retry parameters ie. Also DNS monitor is using UDP Transport but we have a specific monitor for it...

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@chakflying commented on GitHub (Feb 28, 2024):

Then you would implement a monitor specifically for those services, instead of just UDP.

A UDP monitor is basically meaningless, since there is nothing to monitor.

@chakflying commented on GitHub (Feb 28, 2024): Then you would implement a monitor specifically for those services, instead of just UDP. A UDP monitor is basically meaningless, since there is nothing to monitor.

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@krot4u commented on GitHub (Nov 10, 2024):

And no one nows about Gatus?
The UDP check works fine there...
Whould like to have it in Uptime Kume

@krot4u commented on GitHub (Nov 10, 2024): And no one nows about [Gatus](https://github.com/TwiN/gatus)? The UDP check works fine there... Whould like to have it in Uptime Kume

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Nov 11, 2024):

https://github.com/TwiN/gatus/blob/master/client%2Fclient.go#L88-L95

This is how they monitor UDP
=> they don't monitor UDP, but rather look at if the socket they try to connect to accepts their connection as far as I can see

@CommanderStorm commented on GitHub (Nov 11, 2024): https://github.com/TwiN/gatus/blob/master/client%2Fclient.go#L88-L95 This is how they monitor UDP => they don't monitor UDP, but rather look at if the socket they try to connect to accepts their connection as far as I can see

deekerman commented

2026-02-28 01:31:33 -05:00

Author

Owner

@jordantrizz commented on GitHub (Nov 25, 2024):

https://github.com/TwiN/gatus/blob/master/client%2Fclient.go#L88-L95

This is how they monitor UDP => they don't monitor UDP, but rather look at if the socket they try to connect to accepts their connection as far as I can see

Wouldn't that be enough?

@jordantrizz commented on GitHub (Nov 25, 2024): > https://github.com/TwiN/gatus/blob/master/client%2Fclient.go#L88-L95 > > This is how they monitor UDP => they don't monitor UDP, but rather look at if the socket they try to connect to accepts their connection as far as I can see Wouldn't that be enough?

deekerman referenced this issue

2026-02-28 01:50:34 -05:00

Lost every config during update #558

deekerman referenced this issue

2026-02-28 03:07:25 -05:00

Some URL show down after updated to v1.23.4 #2792