Timeline for ICMP echo traffic doesn't NEED to be operated on a raw socket any more than UDP or TCP traffic does, so why is it done that way?
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 4 at 7:49 | comment | added | ilkkachu | @penguin359, I wasn't saying a new API would be without any issues any more than any other API. I am saying that mentioning other types of ICMP as an argument against a dedicated ping API is a bit backwards, since it's the traditional way of using raw sockets that exposes all ICMP types to userland, while a dedicated ping API would not allow other types. (Sure, one can move the line from the user/kernel barrier and think of /bin/ping as such an API, but I would say it's relatively hard to use programmatically.) | |
| Mar 4 at 4:36 | comment | added | user10489 | @penguin359 balance kernel API cost of ping vs. not being able to ping in rootless containers.... apparently that was the tipping point. That and a lot of the security complexity of the ping command were no longer needed due to mitigations required to prevent external DoS attacks anyway. | |
| Mar 4 at 4:32 | comment | added | penguin359 | @ilkkachu Every new API added to the kernel adds complexity to the kernel that can't easily be dropped later. The gains for a simple ping API over just calling the ping executable would be minimal for the cost. | |
| Mar 3 at 18:54 | comment | added | Joshua | There actually is a second one. The traceroute program benefits from the option to send ICMP packets rather than UDP packets. | |
| Mar 3 at 17:46 | comment | added | ilkkachu | Normal processes have no business sending most ICMP messages, but how is that a point against a dedicated API for sending pings? With the implementation using raw sockets, the tool itself has the capability to send arbitrary messages, while a dedicated API would likely be implemented on the OS level so that it would only allow sending echo requests, not anything else. | |
| Mar 3 at 12:18 | comment | added | user10489 | The ping command does rate limit ping. Kernel 6.8 has 142 tcpv4 tuning parameters, many of which are related to rate limiting or completely dropping packets in some condition, and 9 are related to icmp. | |
| Mar 3 at 12:15 | comment | added | marcelm | "... possible for an unprivileged process to send a ping, a kernel API [...] would have to be rate limited to prevent harm." - Why? Neither TCP connections nor UDP packets are rate-limited for unprivileged processes. | |
| Mar 3 at 12:08 | comment | added | user10489 | True enough! Answers correct for years suddenly aren't. | |
| Mar 3 at 7:15 | comment | added | Bob | > there's not a lot of reason to reimplement it or import the ping code into the kernel. - For questions of "why does this feature/API not exist", always consider the -100 point hole that potential features start in. Every kernel API is a development and maintenance burden that's nigh-impossible to later remove, so very often the answer to "why not" is just "it isn't worth it", especially if a (mostly) suitable alternative exists. It's telling that once the alternative proved unsuitable for containers, new functionality was added. | |
| Mar 3 at 6:53 | history | edited | user10489 | CC BY-SA 4.0 | added 412 characters in body |
| Mar 3 at 6:32 | history | edited | user10489 | CC BY-SA 4.0 | added 85 characters in body |
| Mar 3 at 6:12 | history | edited | user10489 | CC BY-SA 4.0 | added 54 characters in body |
| Mar 3 at 5:57 | history | edited | user10489 | CC BY-SA 4.0 | added 48 characters in body |
| Mar 3 at 5:45 | history | edited | user10489 | CC BY-SA 4.0 | deleted 45 characters in body |
| Mar 3 at 5:39 | history | edited | user10489 | CC BY-SA 4.0 | deleted 45 characters in body |
| Mar 3 at 5:31 | history | edited | user10489 | CC BY-SA 4.0 | added 1014 characters in body |
| Mar 3 at 5:02 | history | edited | user10489 | CC BY-SA 4.0 | added 10 characters in body |
| Mar 3 at 4:57 | history | answered | user10489 | CC BY-SA 4.0 |