Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

complete SO_TIMESTAMPNS to SO_TIMESTAMP fallback #375

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

auerswal
Copy link
Collaborator

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.

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 schweikert#374 by @payload.
@coveralls
Copy link

Coverage Status

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

@gsnw-sebast
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

When falling back to SO_TIMESTAMP reply timestamp is probably not working
3 participants