illumos-joyent icon indicating copy to clipboard operation
illumos-joyent copied to clipboard

[lx] iputils ping(1) says the kernel needs a shower

Open rzezeski opened this issue 9 years ago • 12 comments

  • platform: 20151029T053122Z
  • image: custom centos 6.6 image (pretty much the same as official joyent CentOS 6 image)
  • ping version: ping utility, iputils-sss20071127
  • ping src: http://www.skbuff.net/iputils/ (technically I think there are CentOS downstream patches but this should be close enough)

When trying to ping a network for which there is no route, ping complains about the freshness of the kernel. I believe this has to do with incomplete emulation of IP_RECVERR (I didn't take a close look). See the parse_reply() function in the source.

Like issue #87, this doesn't cause ping(1) to actually error but instead causes nagios to trip on stderr (though, in this case, the host is unreachable so it's going to complain anyways). I'm reporting this for the sake of completeness.

[root@c66lx-prod ~]# ping -c 10 -n 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
WARNING: kernel is not very fresh, upgrade is recommended.
From 69.31.94.221: icmp_seq=2 Destination Net Unreachable
From 69.31.94.221: icmp_seq=3 Destination Net Unreachable
^C
--- 10.0.1.1 ping statistics ---
3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2600ms

rzezeski avatar Dec 03 '15 22:12 rzezeski

This issue is also appearing on the current 20151126T062747Z image .

failedrequest avatar Dec 03 '15 22:12 failedrequest

Open as OS-5008

Thanks

pfmooney avatar Dec 04 '15 15:12 pfmooney

Whoa. Nice message, GNU folks. I'm amazed that something as simple as ICMP echo handling would even desire a kernel update.

gdamore avatar Dec 07 '15 20:12 gdamore

IIRC, it's griping about our lack of support for certain sockopts (which were introduced into Linux mainline a long time ago).

pfmooney avatar Dec 07 '15 20:12 pfmooney

IIRC the ~~check_icmp~~ and check_ping from nagios complain about this too. Been a while since I jabbed at that.

sjorge avatar Dec 07 '15 20:12 sjorge

Just tested again:

[hades :: sjorge][~]
[!]$ /usr/lib/nagios/plugins/check_ping -H localhost -w 2,2% -c 3,4%
PING CRITICAL - System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr  System call sent warnings to stderr Packet loss = 100%|rta=3.000000ms;2.000000;3.000000;0.000000 pl=100%;2;4;0

Using latest SmartOS PI, Ubuntu Linux hades 3.16.1 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux

sjorge avatar Dec 07 '15 21:12 sjorge

All On a side note check_icmp works fine as it uses its own internal icmp code . So this affects nagios check_ping and anything else that depend on parsing ping's output or parsing the output another app that uses the socket filters . For example apache2 try's to use http_accept or accf_http can't remember ; but it's missing and generates a similar warning .

On Dec 7, 2015, at 4:05 PM, Jorge Schrauwen [email protected] wrote:

Just tested again:

[hades :: sjorge][~] [!]$ /usr/lib/nagios/plugins/check_ping -H localhost -w 2,2% -c 3,4% PING CRITICAL - System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr Packet loss = 100%|rta=3.000000ms;2.000000;3.000000;0.000000 pl=100%;2;4;0 Using latest SmartOS PI, Ubuntu Linux hades 3.16.1 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux

— Reply to this email directly or view it on GitHub.

failedrequest avatar Dec 07 '15 21:12 failedrequest

This looks to be fixed now!

/usr/lib/nagios/plugins/check_ping -H localhost -p 3 -4 -w 1,1% -c 2,2%
PING OK - Packet loss = 0%, RTA = 0.07 ms|rta=0.068000ms;1.000000;2.000000;0.000000 pl=0%;1;2;0

sjorge avatar Apr 07 '16 18:04 sjorge

now run ping 8.8.8.8 > /dev/null & /usr/lib/nagios/plugins/check_ping -H localhost -p 3 -4 -w 1,1% -c 2,2%

The issue in illumos was noticed when two or more icmp commands were running.

failedrequest avatar Apr 07 '16 19:04 failedrequest

Yep, that fails

WARNING: failed to install socket filter
: Protocol not available
PING WARNING - System call sent warnings to stderr  System call sent warnings to stderr Packet loss = 0%, RTA = 0.06 ms|rta=0.056000ms;1.000000;2.000000;0.000000 pl=0%;1;2;0

sjorge avatar Apr 07 '16 19:04 sjorge

I've got essentially the same problem in a Debian LX branded image running on 20171221T020409Z.

# ping6 google.com
WARNING: your kernel is veeery old. No problems.

Did a bit of digging and it comes from line 1085 of ping6.c in iputils (the version I have is 20121221:

working_recverr = 1;
hold = 1;
if (setsockopt(icmp_sock, SOL_IPV6, IPV6_RECVERR, (char *)&hold, sizeof(hold))) {
	fprintf(stderr, "WARNING: your kernel is veeery old. No problems.\n");
	working_recverr = 0;
}

In man 7 ip the option is listed as IP_RECVERR (since Linux 2.2), which explains the "veeery old" or "kernel is not very fresh" messages. Note that there was a similar issue in WSL before IP_RECVERR was fully implemented/emulated there.

I am only getting the warning from ping6, the equivalent bit of code from ping.c is

hold = 1;
if (setsockopt(icmp_sock, SOL_IP, IP_RECVERR, (char *)&hold, sizeof(hold)))
	fprintf(stderr, "WARNING: your kernel is veeery old. No problems.\n");

so it looks like the support is there for IPv4 sockets but not for IPv6.

I also started looking at this issue because it is causing Icinga ping checks to fail on IPv6.

This is as far as I've looked so far, but I guess the next stage is to start looking for where the IP_RECVERR option was implemented for IPv4 and do something similar for IPv6.

sciguy16 avatar Dec 25 '17 12:12 sciguy16

Another amusing find with this issue, is this bit of code in iputils ping serves no real purpose, other then to try and get you to upgrade to a newer version of linux. On other linux's who use ping derived from other sources , *BSD, busybox etc, this is not an issue.

On Mon, Dec 25, 2017 at 7:58 AM, David Young [email protected] wrote:

I've got essentially the same problem in a Debian LX branded image running on 20171221T020409Z.

ping6 google.com

WARNING: your kernel is veeery old. No problems.

Did a bit of digging and it comes from line 1085 of ping6.c in iputils (the version I have is 20121221 http://www.skbuff.net/iputils/:

working_recverr = 1; hold = 1; if (setsockopt(icmp_sock, SOL_IPV6, IPV6_RECVERR, (char *)&hold, sizeof(hold))) { fprintf(stderr, "WARNING: your kernel is veeery old. No problems.\n"); working_recverr = 0; }

In man 7 ip the option is listed as IP_RECVERR (since Linux 2.2), which explains the "veeery old" or "kernel is not very fresh" messages. Note that there was a similar issue in WSL https://github.com/Microsoft/WSL/issues/710 before IP_RECVERR was fully implemented/emulated there.

I am only getting the warning from ping6, the equivalent bit of code from ping.c is

hold = 1; if (setsockopt(icmp_sock, SOL_IP, IP_RECVERR, (char *)&hold, sizeof(hold))) fprintf(stderr, "WARNING: your kernel is veeery old. No problems.\n");

so it looks like the support is there for IPv4 sockets but not for IPv6.

I also started looking at this issue because it is causing Icinga ping checks to fail on IPv6.

This is as far as I've looked so far, but I guess the next stage is to start looking for where the IP_RECVERR option was implemented for IPv4 and do something similar for IPv6.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/joyent/illumos-joyent/issues/88#issuecomment-353867976, or mute the thread https://github.com/notifications/unsubscribe-auth/ALvEncpo9gnpBY8n-Zj6QFrQiZU8i0Scks5tD5vsgaJpZM4GuauC .

--

Mark Saad Lucera Financial Infrastructures, LLC [email protected] [email protected] https://lucera.com Desk: +1 (646) 893-5110

failedrequest avatar Dec 26 '17 15:12 failedrequest