What Linux process is responsible for responding to pings?

Question

I have a Linux based process controller that occasionally locks up to the point where you can't ping it (i.e. I can ping it, then it becomes no longer pingable without any modifications to network settings).

I'm curious, what process/system is responsible for actually responding to pings? It appears that this process is crashing.

Answer 1

The kernel network stack is handling ICMP messages, which are those sent by the ping command.

If you do not get replies, besides network problems or filtering, and host based filtering/rate-limiting/black-holing/etc. it means the machine is probably overloaded by something, which can be transient, or the kernel crashed, which is rare but can happen (faulty hardware, etc.), not necessarily because of the ICMP traffic (but trying to overload it with such traffic can be a good test at the beginning of life of a server to see how it sustains things). In the later case of kernel crash you should have ample information in the log files or on the console.

Also note that ping is almost always the wrong tool to check if a service is online or not. For various reasons, but mostly because it does not mimic real application traffic, by definition. For example if you need to check that a webserver is still live, you should instead do an HTTP query to it (TCP port 80 or 443), if you need to check a mailserver you do an SMTP query (TCP port 25), if a DNS server, an UDP and a TCP query to port 53, etc.

Answer 2

There is no userland process responsible for responding to pings. Ping is just a utility to send ICMP echo packets. These are received and process by the kernel's networking stack

Answer 3

The kernel itself (not any user process) is responsible to sending ICMP echo reply messages in response to ICMP echo request messages. So, if a host stops responding to pings, it is usually due to some of the following reasons:

• network connectivity between you and host being pinged might have been severed. It could be due to tons of reasons itself: physical damage to the cables, noise in the case of wireless, broken route tables, you being under DDoS attack, problematic routers/switches in between etc. You'd start troubleshooting in this case by using ethtool(8), iwconfig(8), route(8), ping(8) its router, tcpdump(8) etc. on target host.

• firewall setting on target host (or any router/firewall in between you and target host) may be limiting amount of pings (or amount of traffic traffic). It could also be due to tools like fail2ban(8) firewalling stuff on demand. See iptables(8) to check.

• there has been software/hardware malfunction at target host. Network kernel module on target host might have OOPSed and/or become confused, or even whole kernel might have PANICked. You'll see messages about at in dmesg(8) on target host, or as screen output on physical console (if physical access is impractical, another machine with serial console can help.) If kernel OOPS/PANIC is the problem, newer kernel with better drivers might help, or you could kludge around the system lockups with watchdog(8) and helper drivers. Or you can change hardware parts.

Answer 4

One fun way to convince yourself that the Linux kernel handles it directly is to observe the kernel settings for it with:

tail /proc/sys/net/ipv4/icmp*

which might output something like:

==> /proc/sys/net/ipv4/icmp_echo_enable_probe <==
0
==> /proc/sys/net/ipv4/icmp_echo_ignore_all <==
0
==> /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts <==
1
==> /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr <==
0
==> /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses <==
1
==> /proc/sys/net/ipv4/icmp_msgs_burst <==
50
==> /proc/sys/net/ipv4/icmp_msgs_per_sec <==
1000
==> /proc/sys/net/ipv4/icmp_ratelimit <==
1000
==> /proc/sys/net/ipv4/icmp_ratemask <==
6168

This already indicates that ICMP is handled by the kernel, since /proc/sys is a special filesystem used to configure and inspect kernel state: What is in /dev, /proc and /sys?

Next, if you connect 2 computers on the same LAN behind a typical home modem router, and then you manage to ping from computer A to computer B with something like:

ping 192.168.1.102

you can then go on computer B and turn off ping replies with:

echo 1 | sudo tee /proc/sys/net/ipv4/icmp_echo_ignore_all

and as soon as you do that, ping from computer A will start to fail. And to re-enable:

echo 0 | sudo tee /proc/sys/net/ipv4/icmp_echo_ignore_all

So we were able to directly control ICMP just by talking to the kernel.

References to icmp_echo_ignore_all can be seen in the kernel code pointed to by Ruslan in a comment https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/icmp.c?id=24cac7009cb1b211f1c793ecb6a462c03dc35818#n935

static bool icmp_echo(struct sk_buff *skb)
{
    struct net *net;
net = dev_net(skb_dst(skb)->dev);
if (!net->ipv4.sysctl_icmp_echo_ignore_all) {
    struct icmp_bxm icmp_param;

    icmp_param.data.icmph      = *icmp_hdr(skb);
    icmp_param.data.icmph.type = ICMP_ECHOREPLY;
    icmp_param.skb         = skb;
    icmp_param.offset      = 0;
    icmp_param.data_len    = skb->len;
    icmp_param.head_len    = sizeof(struct icmphdr);
    icmp_reply(&icmp_param, skb);
}
/* should there be an ICMP stat for ignored echos? */
return true;

}

Tested with two Ubuntu 23.10 machines running Linux 6.5.0 connected on a home wireless LAN.