* [Cerowrt-devel] access to cmsg from go?
@ 2021-06-19 21:59 Dave Taht
2021-06-20 1:59 ` [Cake] " Matt Mathis
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Dave Taht @ 2021-06-19 21:59 UTC (permalink / raw)
To: bloat, Cake List, cerowrt-devel
anyone have any good ideas here? https://github.com/golang/go/issues/46831
--
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
Dave Täht CTO, TekLibre, LLC
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cake] access to cmsg from go?
2021-06-19 21:59 [Cerowrt-devel] access to cmsg from go? Dave Taht
@ 2021-06-20 1:59 ` Matt Mathis
2021-06-20 20:08 ` [Cerowrt-devel] [Bloat] " Hal Murray
[not found] ` <mailman.3123.1624154360.24343.cerowrt-devel@lists.bufferbloat.net>
2021-06-23 19:29 ` [Cerowrt-devel] " Etienne Champetier
2 siblings, 1 reply; 5+ messages in thread
From: Matt Mathis @ 2021-06-20 1:59 UTC (permalink / raw)
To: Dave Taht; +Cc: bloat, Cake List, cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
Is there running code in C?
Thanks,
--MM--
The best way to predict the future is to create it. - Alan Kay
We must not tolerate intolerance;
however our response must be carefully measured:
too strong would be hypocritical and risks spiraling out of
control;
too weak risks being mistaken for tacit approval.
On Sat, Jun 19, 2021 at 2:59 PM Dave Taht <dave.taht@gmail.com> wrote:
> anyone have any good ideas here? https://github.com/golang/go/issues/46831
>
> --
> Latest Podcast:
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
>
> Dave Täht CTO, TekLibre, LLC
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
[-- Attachment #2: Type: text/html, Size: 1732 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cerowrt-devel] [Bloat] [Cake] access to cmsg from go?
2021-06-20 1:59 ` [Cake] " Matt Mathis
@ 2021-06-20 20:08 ` Hal Murray
0 siblings, 0 replies; 5+ messages in thread
From: Hal Murray @ 2021-06-20 20:08 UTC (permalink / raw)
To: Matt Mathis; +Cc: Dave Taht, bloat, Cake List, cerowrt-devel, Hal Murray
> Is there running code in C?
Yes. The NTPsec code is full of #ifdef kludgery.
The C API started with SO_TIMESTAMP for microsecond precision then added
SO_TIMESTAMPNS for nanosecond precision: timeval vs timespec
There is also SO_TIMESTAMPNS vs SCM_TIMESTAMPNS
The basic idea is to use recvmsg rather than recv. In addition to the data
buffer, you feed it another buffer where it can put meta data like timestamps.
Then you have to scan that buffer to find the part you want. Both buffers
are passed to the kernel via a single msghdr parameter (which also has a
pointer for the addr you get via recvfrom).
Details are in man recvmsg and man cmsg
I thought they were reasonably clear.
Without the ifdefs:
You have to start by using setsockopt to turn on SO_TIMESTAMPNS.
setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPNS,
(const void *)&on, sizeof(on)));
The setup code for recvmsg:
struct msghdr msghdr;
struct iovec iovec;
char control[100]; /* FIXME: Need space for time stamp plus overhead
*/
iovec.iov_base = &rb->recv_buffer;
iovec.iov_len = sizeof(rb->recv_buffer);
memset(&msghdr, '\0', sizeof(msghdr));
msghdr.msg_name = &rb->recv_srcadr;
msghdr.msg_namelen = fromlen;
msghdr.msg_iov = &iovec;
msghdr.msg_iovlen = 1;
msghdr.msg_flags = 0;
msghdr.msg_control = (void *)&control;
msghdr.msg_controllen = sizeof(control);
The actual call:
buflen = recvmsg(fd, &msghdr, 0);
The extract code:
struct timespec * tsp;
cmsghdr = CMSG_FIRSTHDR(msghdr);
if (NULL == cmsghdr) {
extra checking because this code is in a subroutine
error
}
if (SCM_TIMESTAMPNS != cmsghdr->cmsg_type) {
There is only one -- no need to loop
error
}
tsp = (struct timespec *)CMSG_DATA(cmsghdr);
Actual code is in:
read_network_packet in ntpd/ntp_io.c
https://gitlab.com/NTPsec/ntpsec/-/blob/master/ntpd/ntp_io.c
and
fetch_packetstamp() in ntpd/ntp_packetstamp.c
https://gitlab.com/NTPsec/ntpsec/-/blob/master/ntpd/ntp_packetstamp.c
--
These are my opinions. I hate spam.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cerowrt-devel] [Cake] access to cmsg from go?
[not found] ` <mailman.3123.1624154360.24343.cerowrt-devel@lists.bufferbloat.net>
@ 2021-06-23 16:09 ` David P. Reed
0 siblings, 0 replies; 5+ messages in thread
From: David P. Reed @ 2021-06-23 16:09 UTC (permalink / raw)
To: Matt Mathis; +Cc: Dave Taht, Cake List, cerowrt-devel, bloat
(They closed the issue on the golang link.)
I'm not a golang user. One language too many for me. It sounds like a library issue.
My suggestion would be to use the openness of open source. Generate a patchset that extends the interface properly. Don't try to "improve" what you don't like - communities like stability and backward compatibility. Explain the added semantics in documentation.
Then, maintain your fork. I don't know how the golang community works with versioning of libraries, but Python, Rust, Haskell, and NodeJS all have ways to let projects use variants of libraries.
Then, submit that patchset upstream to the golang community. Advocate for upstreaming it, and develop a community that uses the patched library. Eventually, you may be able to stop maintaining your variant toolset. Or you will develop an alternat library user base that disagrees with upstream's decisions.
(Analogy, Android's Linux Kernel vs. Linus Torvalds's. Google Android rejects to some extent Linus's crew's unwillingness to accept what Android needs as improvements.)
This is "modern open source community" practice for getting things done. Pragmatic innovations in shared codebases sometimes have to wait for the original egos to die off.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cerowrt-devel] access to cmsg from go?
2021-06-19 21:59 [Cerowrt-devel] access to cmsg from go? Dave Taht
2021-06-20 1:59 ` [Cake] " Matt Mathis
[not found] ` <mailman.3123.1624154360.24343.cerowrt-devel@lists.bufferbloat.net>
@ 2021-06-23 19:29 ` Etienne Champetier
2 siblings, 0 replies; 5+ messages in thread
From: Etienne Champetier @ 2021-06-23 19:29 UTC (permalink / raw)
To: Dave Taht; +Cc: bloat, Cake List, cerowrt-devel
Hello Dave,
Le sam. 19 juin 2021 à 17:59, Dave Taht <dave.taht@gmail.com> a écrit :
>
> anyone have any good ideas here? https://github.com/golang/go/issues/46831
(with the list in cc)
Some googling that might (or not) help:
https://github.com/google/gopacket/blob/master/pcapgo/capture.go
https://github.com/gracig/goping/blob/master/pingers/icmpv4/icmpv4_linux.go#L217
Best
Etienne
>
> --
> Latest Podcast:
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
>
> Dave Täht CTO, TekLibre, LLC
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-06-23 19:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-19 21:59 [Cerowrt-devel] access to cmsg from go? Dave Taht
2021-06-20 1:59 ` [Cake] " Matt Mathis
2021-06-20 20:08 ` [Cerowrt-devel] [Bloat] " Hal Murray
[not found] ` <mailman.3123.1624154360.24343.cerowrt-devel@lists.bufferbloat.net>
2021-06-23 16:09 ` [Cerowrt-devel] " David P. Reed
2021-06-23 19:29 ` [Cerowrt-devel] " Etienne Champetier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox