starred/uptime-kuma

Fork 0

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

[Ping] fails if you choose a ping paket size below 16 bytes #2471

New issue

Open

opened 2026-02-28 02:55:51 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-28 02:55:51 -05:00

Owner

Originally created by @GoodSoulGermany on GitHub (Aug 14, 2023).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

Description

When I set the ping paketsize below 16 bytes pinging fails and shows host offline.

👟 Reproduction steps

Set ping paketsize below 16 bytes.

👀 Expected behavior

A ping paketsize of 1 byte should work.

😓 Actual Behavior

Ping fails, shows host "offline" with the next ping.

When you use 16 bytes for ping it works. Below that number it will always 100% fails.

Why can I go below 16 bytes when Uptime Kuma can handle it?
Why can't Uptime Kuma handle bytes below 16 byte?

https://github.com/louislam/uptime-kuma/assets/4119560/b4e1f0cb-4b00-4164-9709-bffaa5600da1

🐻 Uptime-Kuma Version

1.21.1

💻 Operating System and Arch

Ubuntu 22.10

🌐 Browser

Chrome, Firefox, Edge, Vivaldi, Opera One - ANY browser

🐋 Docker Version

Docker version 20.10.21, build 20.10.21-0ubuntu1~22.10.2

🟩 NodeJS Version

Unknown (build in Docker)

📝 Relevant log output

No log available (running in docker).

Originally created by @GoodSoulGermany on GitHub (Aug 14, 2023). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description When I set the ping paketsize below 16 bytes pinging fails and shows host offline. ### 👟 Reproduction steps Set ping paketsize below 16 bytes. ### 👀 Expected behavior A ping paketsize of 1 byte should work. ### 😓 Actual Behavior Ping fails, shows host "offline" with the next ping. When you use 16 bytes for ping it works. Below that number it will always 100% fails. Why can I go below 16 bytes when Uptime Kuma can handle it? Why can't Uptime Kuma handle bytes below 16 byte? https://github.com/louislam/uptime-kuma/assets/4119560/b4e1f0cb-4b00-4164-9709-bffaa5600da1 ### 🐻 Uptime-Kuma Version 1.21.1 ### 💻 Operating System and Arch Ubuntu 22.10 ### 🌐 Browser Chrome, Firefox, Edge, Vivaldi, Opera One - ANY browser ### 🐋 Docker Version Docker version 20.10.21, build 20.10.21-0ubuntu1~22.10.2 ### 🟩 NodeJS Version Unknown (build in Docker) ### 📝 Relevant log output ```shell No log available (running in docker). ```

deekerman added the

bug

A:monitor

type:enhance-existing

good first issue

blocked-upstream

labels

2026-02-28 02:55:51 -05:00

deekerman commented

2026-02-28 02:55:55 -05:00

Author

Owner

@louislam commented on GitHub (Aug 14, 2023):

Did some research on this.

The message is actually a successful message.

Now I try to compare the ping result.

Raw ping command test:

56-byte's output (ping -c 1 rs-debian):

PING rs-debian.pig-yo.ts.net (100.92.145.130) 56(84) bytes of data.
64 bytes from rs-debian.pig-yo.ts.net (100.92.145.130): icmp_seq=1 ttl=63 time=14.9 ms

--- rs-debian.pig-yo.ts.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

1-byte's output (ping -c 1 -s 1 rs-debian):

PING rs-debian.pig-yo.ts.net (100.92.145.130) 1(29) bytes of data.
9 bytes from rs-debian.pig-yo.ts.net (100.92.145.130): icmp_seq=1 ttl=63

--- rs-debian.pig-yo.ts.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

There is no time info in the 1-byte's output. According to https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/ping.1M.html:

If packet-size is smaller than 16 bytes, there is not enough room for timing information. In that case, the round-trip times are not displayed.

So I think it maybe a parsing issue of node-ping.
https://github.com/louislam/node-ping/blob/master/lib/parser/linux.js

I think the better handling should be, returning the successful result, but with -1/undefined ping time value when <16 package size.

@louislam commented on GitHub (Aug 14, 2023): Did some research on this. The message is actually a successful message. ![image](https://github.com/louislam/uptime-kuma/assets/1336778/685ef7c4-7ee1-4ef0-9269-544ed0d456be) Now I try to compare the ping result. #### Raw ping command test: 56-byte's output (`ping -c 1 rs-debian`): ``` PING rs-debian.pig-yo.ts.net (100.92.145.130) 56(84) bytes of data. 64 bytes from rs-debian.pig-yo.ts.net (100.92.145.130): icmp_seq=1 ttl=63 time=14.9 ms --- rs-debian.pig-yo.ts.net ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms ``` 1-byte's output (`ping -c 1 -s 1 rs-debian`): ``` PING rs-debian.pig-yo.ts.net (100.92.145.130) 1(29) bytes of data. 9 bytes from rs-debian.pig-yo.ts.net (100.92.145.130): icmp_seq=1 ttl=63 --- rs-debian.pig-yo.ts.net ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms ``` There is no time info in the 1-byte's output. According to https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/ping.1M.html: > If packet-size is smaller than 16 bytes, there is not enough room for timing information. In that case, the round-trip times are not displayed. So I think it maybe a parsing issue of `node-ping`. https://github.com/louislam/node-ping/blob/master/lib/parser/linux.js I think the better handling should be, returning the successful result, but with -1/undefined ping time value when <16 package size.

deekerman commented

2026-02-28 02:55:56 -05:00

Author

Owner

@chakflying commented on GitHub (Aug 14, 2023):

Or just set a minimum value of 16 bytes. I think very few people know this (I didn't) and it would be equally confusing for people to set it to 1 byte and don't understand why the ping value is broken.

@chakflying commented on GitHub (Aug 14, 2023): Or just set a minimum value of 16 bytes. I think very few people know this (I didn't) and it would be equally confusing for people to set it to 1 byte and don't understand why the ping value is broken.

deekerman commented

2026-02-28 02:55:56 -05:00

Author

Owner

@louislam commented on GitHub (Aug 15, 2023):

Or just set a minimum value of 16 bytes. I think very few people know this (I didn't) and it would be equally confusing for people to set it to 1 byte and don't understand why the ping value is broken.

The weird thing is the 16-byte limit doesn't apply to Windows.

@louislam commented on GitHub (Aug 15, 2023): > Or just set a minimum value of 16 bytes. I think very few people know this (I didn't) and it would be equally confusing for people to set it to 1 byte and don't understand why the ping value is broken. The weird thing is the 16-byte limit doesn't apply to Windows. ![image](https://github.com/louislam/uptime-kuma/assets/1336778/abffdc3e-87c4-47b6-b01c-2fbfa9136709)

deekerman commented

2026-02-28 02:55:56 -05:00

Author

Owner

@chakflying commented on GitHub (Aug 16, 2023):

I checked with Wireshark and the packet looks the same as on Linux. I think the only difference for a larger packet is that the "Timestamp" and "Timestamp Reply" fields are included, which can be used to eliminate the server processing time from the calculated ping. But servers may not implement these fields anyway because of security reasons.

@chakflying commented on GitHub (Aug 16, 2023): I checked with Wireshark and the packet looks the same as on Linux. I think the only difference for a larger packet is that the "Timestamp" and "Timestamp Reply" fields are included, which can be used to eliminate the server processing time from the calculated ping. But servers [may not implement ](https://networkengineering.stackexchange.com/questions/50511/when-is-timestamp-and-timestamp-reply-are-used-in-icmp-protocol) these fields anyway because of security reasons.

deekerman commented

2026-02-28 02:55:56 -05:00

Author

Owner

@neelbhanushali commented on GitHub (Feb 12, 2024):

@louislam @CommanderStorm

Should I go ahead with implementing a minimum limit of 16 bytes on frontend as mentioned here

Or just set a minimum value of 16 bytes. I think very few people know this (I didn't) and it would be equally confusing for people to set it to 1 byte and don't understand why the ping value is broken.

Or modify node-ping?

So I think it maybe a parsing issue of node-ping. https://github.com/louislam/node-ping/blob/master/lib/parser/linux.js

I think the better handling should be, returning the successful result, but with -1/undefined ping time value when <16 package size.

@neelbhanushali commented on GitHub (Feb 12, 2024): @louislam @CommanderStorm Should I go ahead with implementing a minimum limit of 16 bytes on frontend as mentioned here > Or just set a minimum value of 16 bytes. I think very few people know this (I didn't) and it would be equally confusing for people to set it to 1 byte and don't understand why the ping value is broken. Or modify node-ping? > So I think it maybe a parsing issue of `node-ping`. https://github.com/louislam/node-ping/blob/master/lib/parser/linux.js > > I think the better handling should be, returning the successful result, but with -1/undefined ping time value when <16 package size.

deekerman commented

2026-02-28 02:55:56 -05:00

Author

Owner

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

Given that "fixing it in the dependency" would essentially return invalid ping results
=> be confusing to our users
I think setting a minimum value on our side is a better choice.

Ignoring that this error is platform dependent¹ and adding an help text (the minimum of 16 packets is an upstream limitation of ping and exists to make sure that the results are statistically significant) seems like a good choice.
Cc @chakflying for a second opinion

I don't fully see a reason why lowering this parameter this far is better, but maybe @GoodSoulGermany has one ↩︎

@CommanderStorm commented on GitHub (Feb 12, 2024): Given that "fixing it in the dependency" would essentially return invalid ping results => be confusing to our users I think setting a minimum value on our side is a better choice. Ignoring that this error is platform dependent[^1] and adding an help text (`the minimum of 16 packets is an upstream limitation of ping and exists to make sure that the results are statistically significant`) seems like a good choice. Cc @chakflying for a second opinion [^1]: I don't fully see a reason why lowering this parameter this far is better, but maybe @GoodSoulGermany has one

deekerman commented

2026-02-28 02:55:56 -05:00

Author

Owner

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

Authoritarian Approach:

Limit the input field in front-end to a minimum of 16.
Add logic in back-end to clamp values < 16 when running ping (optionally on Linux only)

Non-authoritarian Approach:

Display help text when user inputted value < 16.
Fix logic in node-ping such that it would not fail to parse if the time value is not present. Just return null for the ping for display.

Both are fine by me. Note that for the help text, I don't think it has anything to do with statistical significance. If I were to write it it would just be "packet size < 16 does not produce round-trip times on Linux".

@chakflying commented on GitHub (Feb 14, 2024): Authoritarian Approach: - Limit the input field in front-end to a minimum of 16. - Add logic in back-end to clamp values < 16 when running ping (optionally on Linux only) Non-authoritarian Approach: - Display help text when user inputted value < 16. - Fix logic in `node-ping` such that it would not fail to parse if the time value is not present. Just return null for the ping for display. Both are fine by me. Note that for the help text, I don't think it has anything to do with statistical significance. If I were to write it it would just be "packet size < 16 does not produce round-trip times on Linux".