complete SO_TIMESTAMPNS to SO_TIMESTAMP fallback

[auerswal]

Commit e866063 added a fallback from setting the socket option SO_TIMESTAMPNS to setting the socket option SO_TIMESTAMP if the nanosecond timestamp option could not be set. But it did not add code to also look for the control message related to SO_TIMESTAMP. Thus microsecond timestamps were requested, but not read.

This commit adds the missing code to read microsecond timestamp control messages.

The problem was reported in GitHub issue #374 by @payload.

[coveralls]

coverage: 87.679% (+0.08%) from 87.602%
when pulling fdd5dee on auerswal:issue374
into cb83286 on schweikert:develop.

[gsnw-sebast]

Not sure, but the actual ticket had the problem, the binary was built with HAVE_SO_TIMESTAMPNS but the system itself could not use SO_TIMESTAMPNS. So not sure about the implications of timeval_ns() if it is still present in SCM_TIMESTAMP.

[auerswal]

According to man 7 socket, the two socket options SO_TIMESTAMP and SO_TIMESTAMPNS result in the creation of different control messages:

• Setting SO_TIMESTAMP results in control messages of type SCM_TIMESTAMP with the data in struct timeval format for microsecond resolution.
• Setting SO_TIMESTAMPNS results in control messages of type SCM_TIMESTAMPNS with the data in struct timespec format for nanosecond resolution.

Since only one of the two socket options is set for each socket, only one type of control messages is created for packets received on the respective socket.

According to the online man page, "A socket cannot mix SO_TIMESTAMP and SO_TIMESTAMPNS: the two modes are mutually exclusive."

I have tested this on GNU/Linux, where both SO_TIMESTAMPNS and SO_TIMESTAMP work, by adding debugging output to the CMSG related code and changing the preference of the two socket options:

• When SO_TIMESTAMPNS is tried first, this succeeds, and only SCM_TIMESTAMPNS type control messages are created.
• When SO_TIMESTAMP is tried first, this succeeds, and only SCM_TIMESTAMP type control messages are created.

I have then changed the code to prefer SO_TIMESTAMP for IPv4 and SO_TIMESTAMPNS for IPv6 and used a dual-stack target host: fping -mAne target.example. This showed SCM_TIMESTAMP for IPv4 and SCM_TIMESTAMPNS for IPv6, and similar elapsed times for both address families, as expected.

As such I think that the code in this pull request works as intended and is required to make use of the fallback to SO_TIMESTAMP.

[gsnw-sebast]

Thank you for your detailed reply. I have tested it and it looks good