lkml.org 
[lkml]   [2020]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC] y2038: HCI_TIME_STAMP with time64
On Fri, Jan 10, 2020 at 4:44 PM Marcel Holtmann <marcel@holtmann.org> wrote:
> > I noticed earlier this week that the HCI_CMSG_TSTAMP/HCI_TIME_STAMP
> > interface has no time64 equivalent, as we apparently missed that when
> > converting the normal socket timestamps to support both time32 and time64
> > variants of the sockopt and cmsg data.
...
> > When using HCI_TIME_STAMP on a 32-bit system with a time64
> > libc, users will interpret the { s32 tv_sec; s32 tv_usec } layout of
> > the kernel as { s64 tv_sec; ... }, which puts complete garbage
> > into the timestamp regardless of whether this code runs before or
> > after y2038. From looking at codesearch.debian.org, I found two
> > users of this: libpcap and hcidump. There are probably others that
> > are not part of Debian.
...
> > 3. Add support for the normal SO_TIMESTAMPNS_NEW sockopt in
> > HCI, providing timestamps in the unambiguous { long long tv_sec;
> > long long tv_nsec; } format to user space, and change applications
> > to use that if supported by the kernel.
>
> I have added SO_TIMESTAMP* to every Bluetooth socket a while back. And that should be used by the majority of the tools. One exception might by hcidump which has been replaced by btmon already anyway.
>
> So I would not bother with HCI_TIME_STAMP fixing. We can do 2) if someone really still wants to use that socket option. However I am under the impression that 3) should be already possible.

Ok, excellent, I had not realized this works already.

I have now also checked
https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-bt-monitor-linux.c
which uses SO_TIMESTAMP and then should work. I guess this is similar
to what btmon does.

For libpcap that leaves
https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-bt-linux.c#L358

which needs a fairly simply fix on 32-bit architectures to copy the
two 32-bit fields
into the longer pkth.ts fields individually rather than using a memcpy.
I've added Guy Harris to Cc, he seems to be the maintainer for this file
according to the git history.

The same change is needed for
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/tools/hcidump.c#n233
if there are any remaining users. I can send you a patch if you want.

Arnd

\
 
 \ /
  Last update: 2020-01-10 17:08    [W:0.107 / U:15.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site