CQL timestamp dissector displays the wrong timestamp
Summary
(Summarize the bug encountered concisely) From a pcap of a Cassandra 2.1.21 node, the timestamp in the request is being decoded as Jan 5 1970 however the timestamp should be something around 2022-04-12. Whilst it is possible that the driver is sending the wrong value, we think that it is most likely that the dissector in wireshark is wrong.
Steps to reproduce
On the cassandra node:
- tcpdump -w output.pcap Do some queries from another box open pcap in wireshark
What is the current bug behaviour?
Timestamp is shown incorrectly (looks like endianness?) i.e. 1970
What is the expected correct behaviour?
Timestamp is displayed as something approaching the current time (2022-04-12 at time of recording).
Sample capture file
(If possible attach a sample capture file, not screenshot of dissection, showing this issue)
Relevant logs and/or screenshots
Build information
3.6.3 (v3.6.3-0-g6d348e4611e2)
Compiled (64-bit) using Microsoft Visual Studio 2019 (VC++ 14.29, build 30139),
with Qt 5.15.2, with libpcap, with GLib 2.66.4, with zlib 1.2.11, with Lua
5.2.4, with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT
Kerberos, with MaxMind DB resolver, with nghttp2 1.44.0, with brotli, with LZ4,
with Zstandard, with Snappy, with libxml2 2.9.10, with libsmi 0.4.8, with
QtMultimedia, with automatic updates using WinSparkle 0.5.7, with AirPcap, with
SpeexDSP (using bundled resampler), with Minizip.
Running on 64-bit Windows 10 (20H2), build 19042, with Intel(R) Core(TM)
i7-7700T CPU @ 2.90GHz (with SSE4.2), with 16267 MB of physical memory, with
GLib 2.66.4, with Qt 5.15.2, without Npcap or WinPcap, with c-ares 1.17.0, with
GnuTLS 3.6.3, with Gcrypt 1.8.3, with nghttp2 1.44.0, with brotli 1.0.9, with
LZ4 1.9.3, with Zstandard 1.4.0, without AirPcap, with light display mode,
without HiDPI, with LC_TYPE=English_United Kingdom.utf8, binary plugins
supported (21 loaded).
Edited by Rob Emery