netdev - Re: Problem with frame time stamping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 13 Nov 2007 15:46:09 +0100
From:	"Antoine Zen-Ruffinen" <antoine.zen@...il.com>
To:	"Eric Dumazet" <dada1@...mosbay.com>
Cc:	netdev@...r.kernel.org, linux-net@...r.kernel.org,
	netfilter-devel@...r.kernel.org, patrik.arlos@....se
Subject: Re: Problem with frame time stamping

ok, I now understood where my error was.  It was a mismatch between my
old kernel headers and my new kernel that I am running !!!! Pretty
stupid !

Tank's you for your time, you learn me some stuff, I appreciate it.

Antoine

2007/11/13, Eric Dumazet <dada1@...mosbay.com>:
> Antoine Zen-Ruffinen a écrit :
> > THIS is what I did at the beginning. But is seem me to be some thing
> > wrong. So I put a static value in skb->tstamp  instead of
> > ktime_get_real() for debug purpose. And I was still becoming the
> > amount of second, microsecond since 1970. We are back to my initial
> > mail ! The value of skb->tsamp doesn't seems to be returned by
> > ioctl().
> >
> OK Antoine.
>
> Yes, 'struct timeval' is as you discovered, ie relative to *something*,
> a given event in the past. (in your case, CLOCK_REALTIME Epoch : January
> 1th 1970)
>
> It is even documented (man gettimeofday)
>
> DESCRIPTION
>        The  gettimeofday() function shall obtain the current time,
> expressed as seconds and microseconds since the Epoch, and store it in the
>        timeval structure pointed to by tp.
>
> For timespec STAMPNS, see clock_gettime() description.
>
> clock_gettime(CLOCK_REALTIME, &ts);
>
> If in your driver you stick in tstamp.tv64 a value like 0x00010002, then
> the result of ioctl(SIOCGSTAMP) will be :
> tv.tv_sec = 0   (so yes, January 1th 1970)
> tv.tv_usec = 65   (because 0x10002/1000 = 65)
>
> Not counting the fact that .tv64 should not be directly set, unless for
> 0 value, because it is not portable.
>
>
>
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html