Home / server / Questions / 744958
Accepted
Bittrance
Asked: 2015-12-24 03:45:46 +0800 CST

ntpd gets "connect: invalid argument" on 0.0.0.2

  • 772

It appears the reply for pool.ntp.org changed recently. This is making my CentosOS 6 ntp servers unhappy. 

$ host pool.ntp.org
pool.ntp.org has address 0.0.0.2
pool.ntp.org has address 83.209.8.142
pool.ntp.org has address 130.236.254.17
pool.ntp.org has address 195.178.181.98

$ /usr/lib64/nagios/plugins/check_ntp_time -H pool.ntp.org
can't create socket connection#

$ strace -f /usr/lib64/nagios/plugins/check_ntp_time -H pool.ntp.org
...
connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("83.209.8.142")}, 16) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("130.236.254.17")}, 16) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("195.178.181.98")}, 16) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("83.209.8.142")}, 16) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("0.0.0.2")}, 16) = -1 EINVAL (Invalid argument)
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6571c5b000
write(1, "can't create socket connection", 30can't create socket connection) = 30
exit_group(3)                           = ?
+++ exited with 3 +++

It appears that there is general agreement on this, as modern Ubuntu says:

$ ping 0.0.0.2
connect: Invalid argument

I thought 0.0.0.2 is a valid IP?

UPDATE

The issue is indeed periodic and has been going on for several days (since 2015-12-20 according to my nagios):

[12:40] host pool.ntp.org
pool.ntp.org has address 194.71.144.71
pool.ntp.org has address 79.136.86.176
pool.ntp.org has address 83.209.8.142
pool.ntp.org has address 178.73.198.130
[13:09] host pool.ntp.org
pool.ntp.org has address 194.71.144.71
pool.ntp.org has address 0.0.0.2
pool.ntp.org has address 178.73.198.130
pool.ntp.org has address 192.36.143.130

I suppose there is a ranking battle of some sort going on.

UPDATE 2

For those interested, this issue occurs when DNS RRs for pool.ntp.org is queried from Sweden.

ip-address

3 Answers

  1. Best Answer

    All of 0.0.0.0/8 is reserved, so that definitely isn't a valid IP for an ntp server. You can check the IANA registry for more information.

    You should file a few bug reports. One against pool.ntp.org, because they should be verifying the validity of IP addresses before allowing them into the pool. And one against check_ntp_time, because it shouldn't die even if an invalid address shows up. Instead it should try the three valid IP addresses it got.

    • 12

  2. Of the four servers you list, three are in the pool and have valid server monitoring pages:

    http://www.pool.ntp.org/scores/83.209.8.142

    http://www.pool.ntp.org/scores/130.236.254.17

    http://www.pool.ntp.org/scores/195.178.181.98

    The other, illegal, one, does not:

    http://www.pool.ntp.org/scores/0.0.0.2

    As kasperd notes, the RRs returned on that A record are round-robin load-balanced, so we cannot tell whether your upstream DNS was lying to you, or an illegal address temporarily made it into the pool. I know from experience as a pool admin that one's server has to be highly-available, and thus well-scored by the monitoring system, to be included in the pool. So I personally doubt that an unreachable address could make it into the pool, and suspect that this was an upstream DNS glitch. But unless you can reliably reproduce the result, I doubt we'll ever know.

    It occurs to me that if pool.ntp.org used DNSSEC signatures, we would immediately be able to tell if this was a cache poisoning issue, or a crap-in-the-pool issue. If I have a few spare minutes, I might raise the issue on the pool servers' admins' list.

    Edit: I have raised the issue on the admins list, and have already had one independent confirmation that this address does seem to be making it into the pool, even though it clearly shouldn't. Watch this space, I guess.

    Edit 2: apparently, this was a genuine bug and it has now been fixed. I agree with kasperd that it's worth chasing the plugin's authors to make the plugin more robust to crap in the pool.

    • 10

  3. 0.0.0.2 is "valid" per se but may only be used as a source address according to RFC1700 hence you cannot ping it.

    • 1