On Thu, Dec 10, 2020 at 10:02 AM Alexander Bluhm <[email protected]>
wrote:
> On Wed, Dec 09, 2020 at 04:55:09PM -0300, K R wrote:
> > pflog0 logs incorrect timestamp on i386. The machine in question is
> > running under QEMU:
>
> Works for me on a i386 xeon machine.
>
Just found a bare metal i386 P4 machine with the same problem:
hw.machine=i386
hw.model=Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel" 686-class)
hw.ncpu=2
hw.vendor=Dell Computer Corporation
hw.product=PowerEdge 850
serv1# tcpdump -c 1 -nl -tt -i pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
2115075927.418786 137.135.249.200.33629 > xxx.xxx.xxx.xxx.23: S
3618214217:3618214217(0) win 64240 <mss
1440,sackOK,timestamp 3082620098 0,nop,wscale 7> (DF)
serv1# date -r 2115075927
Fri Jan 9 01:05:27 GMT 2037
serv1# date
Sun Dec 13 21:54:43 GMT 2020
-Kor
>
> > hw.vendor=QEMU
>
> hw.machine=i386
> hw.model=Intel(R) Xeon(TM) CPU 3.06GHz ("GenuineIntel" 686-class)
> hw.ncpu=4
> hw.vendor=Supermicro .
> hw.product=X5DL8
>
> > # tcpdump -c 1 -nl -tt -q -i pflog0
> > tcpdump: WARNING: snaplen raised from 116 to 160
> > tcpdump: listening on pflog0, link-type PFLOG
> > 2114522159.012334 51.195.88.92.62841 > xxx.xxx.xxx.xxx.5060: udp 331
>
> root@ot2:.../~# date
> Thu Dec 10 13:48:10 CET 2020
> root@ot2:.../~# tcpdump -c 1 -nl -tt -q -i pflog0
> tcpdump: WARNING: snaplen raised from 116 to 160
> tcpdump: listening on pflog0, link-type PFLOG
> 1607604494.828901 10.188.81.21 > 10.188.81.22: icmp: 8 0
> root@ot2:.../~# date -r 1607604494
> Thu Dec 10 13:48:14 CET 2020
> root@ot2:.../~# date
> Thu Dec 10 13:48:22 CET 2020
>
> So what is the difference between your and my setup?
> I would guess it is a OpenBSD on QEMU timekeeping bug.
>
> Could you run this?
>
> root@ot2:.../~# while sleep 1; do date; done
> Thu Dec 10 13:56:47 CET 2020
> Thu Dec 10 13:56:48 CET 2020
> Thu Dec 10 13:56:49 CET 2020
> Thu Dec 10 13:56:50 CET 2020
>
> Does it print one line per second? Does the date output increment
> by one second? Use an independent clock to watch it. Then we see
> if timeouts, clock and real world are in sync.
>
> What does sysctl kern.timecounter say?
>
> bluhm
>
