Wrong timestamp in Packet Capture Output?
-
Hi pfSense Gurus!
I have wrong timestamp in “ Packet Capture Output” (pcap auto scroll view, the “Diagnostic / Packet Capture” main menu) : exactly 2 hours back shift from system time.
How to fix this?
P.S.
pfSense 2.7.2-RELEASE on bare metal server, System time are correct, timestamps in ALL other logs (syslogd) are correct, NTP are correct, no any NTP servers specified in DHCP per interface, and a reboot not help… ;) -
Are the timestamps in UTC?
-
@stephenw10 said in Wrong timestamp in Packet Capture Output:
Are the timestamps in UTC?
03:11:48.793028 ……..
If I understand correctly, this is not ITC ISO8601 basics, nor ISO8601 extended format:
Am I right?
-
The timestamps are in UTC (Coordinated Universal Time). UTC is a time zone, not a time format. It has no relation to ISO 8601.
Your timezone is 2 hours ahead of UTC. This map may help.
-
Find thru the BIOS that hardware clock on a motherboard have a shift -2h.
(How and when that happened- do not know, this are 1-year old setup and client have no monitoring & alerting system…)After adjust settings to real local time and cold reboot (after this cold reboot motherboard clock are on correct local time, ) pfSense started and in Dashboard system time and in NTP widget time are correct
BUT when trying to Packet Capture (on any interface),- timestamp are again shifted back -2h.
How to check config file of pcap in trying to find source of the problem?
Any other suggestions and thoughts?
P.S.
Hm, unexpected behavior of server: BIOS TIME shifts back -2h from correct after some time, but no any “Automatic Time Adjustment” by NTP in BIOS or BMC controller…
How this possible??? -
@Sergei_Shablovsky said in Wrong timestamp in Packet Capture Output:
Find thru the BIOS that hardware clock on a motherboard have a shift -2h.
(How and when that happened- do not know, this are 1-year old setup and client have no monitoring & alerting system…)After adjust settings to real local time and cold reboot (after this cold reboot motherboard clock are on correct local time, ) pfSense started and in Dashboard system time and in NTP widget time are correct
BIOS setting doesn't matter at all. The hardware clock should/will always be in UTC. As soon as you run some form of time sync (such as NTP) on the system, the hardware clock will be set according to UTC.
For the time being, you will have to work with UTC. Longer term, you could make a feature request to have tcpdump be run with TZ set in the environment.
-
@dennypage said in Wrong timestamp in Packet Capture Output:
@Sergei_Shablovsky said in Wrong timestamp in Packet Capture Output:
Find thru the BIOS that hardware clock on a motherboard have a shift -2h.
(How and when that happened- do not know, this are 1-year old setup and client have no monitoring & alerting system…)After adjust settings to real local time and cold reboot (after this cold reboot motherboard clock are on correct local time, ) pfSense started and in Dashboard system time and in NTP widget time are correct
BIOS setting doesn't matter at all. The hardware clock should/will always be in UTC. As soon as you run some form of time sync (such as NTP) on the system, the hardware clock will be set according to UTC.
Ok, Thank You for detailed explanation.
For the time being, you will have to work with UTC. Longer term,
So, if I understood You correctly, this is not misconfiguration from “my side”? Please confirm…
you could make a feature request to have tcpdump be run with TZ set in the environment.
Really, am I ”FIRST who see, care and wrote” and hundreds of thousands SysAdmins not bother by this?
-
If you are managing firewalls in different timezones and trying to compare pcaps it's usually better to have everything in UTC. Personally I've always expected it to be in UTC so it never worried me.
-
@stephenw10 said in Wrong timestamp in Packet Capture Output:
If you are managing firewalls in different timezones and trying to compare pcaps it's usually better to have everything in UTC. Personally I've always expected it to be in UTC so it never worried me.
Hm… I am confused a little bit: I need LOGS and PCAPS data in one format (because log analyzers like Splunk, and monitoring like Prometheus need correct timestamp for alerting) why calculate all this in my head?
Please explain Your reply a little bit more:)
-
If you have pcaps from firewalls all over the world you need them all in one time format if you want to compare them. UTC is chosen by tcpdump for that reason.
-
Yeah most everyone knows this right.. For example if I take a pcap on pfsense, it shows the time in utc.. But if I open that up in say wireshark.. And I have it show time.. It would show me the time based on my machine I am running wireshark on TZ..
Why your not seeing lots of threads asking about this - is I would of thought everyone knew this ;) hehehe Well anyone that works with pcaps normally.
When your working with devices all over the world, or even just a large enough country (with multiple zones).. Having stuff like this in common tz is the way to go.. if someone sent me a pcap, I would assume its in utc..
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
This post is deleted! -
This post is deleted! -
@stephenw10 said in [CLOSED] Wrong timestamp in Packet Capture Output?:
If you have pcaps from firewalls all over the world you need them all in one time format if you want to compare them. UTC is chosen by tcpdump for that reason.
From my point of view we all go off-topic: instead of having ALL logs in System in one format we start discussing why we have different format for each set of logs.
This is common sense, and logically right: HAVING ALL LOGS INSIDE OF SYSTEM IN ONE FORMAT.
This not only means less parsing in 3-rd tools (whatever Splunk, Prometheus, etc…), but less time spend by SysAdmins to solving problems.
WHY I need to have
in most of all logs (syslog format, RFC 5424 + RFC 3339)
2024-01-30 14:54:11.177673+02:00
in OS Account Changes
2024-01-28 15:43:2
in Packet Capture
13:01:06.991876????
-
@johnpoz said in [CLOSED] Wrong timestamp in Packet Capture Output?:
Yeah most everyone knows this right.. For example if I take a pcap on pfsense, it shows the time in utc.. But if I open that up in say wireshark.. And I have it show time.. It would show me the time based on my machine I am running wireshark on TZ..
From developers point of view:
If You decide to show pcap results inside the WebGUI of pfSense - than logically right to show in the same format as the all other logs!
If You decide to just making pcap file for future import to WireShark, - logically right just making the .pcap file and dynamically making the link to download / copy to buffer itWhy your not seeing lots of threads asking about this - is I would of thought everyone knew this ;) hehehe Well anyone that works with pcaps normally.
When your working with devices all over the world, or even just a large enough country (with multiple zones).. Having stuff like this in common tz is the way to go.. if someone sent me a pcap, I would assume its in utc..
Thank You for detailed explanation: I clearly understanding Your point of view.
But WHY I need to see ON-SCREEN pcap in other format than whole system ???
If I using WireShark no matter what are on screen, I just import file by ssh or copy from screen whole pcap. And than switching back and forth between WireShark and pfSense on-screen logs.
But here I asking about WHY I need to have
in most of all logs (syslog format, RFC 5424 + RFC 3339)
2024-01-30 14:54:11.177673+02:00
in OS Account Changes
2024-01-28 15:43:2
in Packet Capture
13:01:06.991876????
If work with logs on screen, everyone need to see standardized data to be able understanding when something happened and how this “happened” impact on other processes.
Why I need to look at 3-4 different formats?
Because someone in pfSense dev group (with all my honors!) have too much work to change 2 strings in code? (That not something difficult, just change the format of output). -
This should be a feature request. The ability to use local timestamps seems like a useful addition. It's not a bug though.
-
@stephenw10 said in Wrong timestamp in Packet Capture Output?:
This should be a feature request. The ability to use local timestamps seems like a useful addition.
Totally agree!
Already created yesterday.It's not a bug though.
Of course, just developers have not polished this many years ago.
