Wrong timestamp in Packet Capture Output?

Sergei_Shablovsky

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… ;)

stephenw10

Are the timestamps in UTC?

Sergei_Shablovsky

@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:

UTC is a datetime value that uses the ISO 8601 basic form yyyymmddT hhmmss+|– hhmm or the ISO 8601 extended form yyyy-mm-ddT hh:mm:ss+|– hh:mm.

Am I right?

dennypage

@Sergei_Shablovsky

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.

Sergei_Shablovsky

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???

dennypage

@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.

Sergei_Shablovsky

@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.

Already done.

Really, am I ”FIRST who see, care and wrote” and hundreds of thousands SysAdmins not bother by this?

stephenw10

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.

Sergei_Shablovsky

@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:)

stephenw10

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.

johnpoz

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..

Sergei_Shablovsky

This post is deleted!

Sergei_Shablovsky

This post is deleted!

Sergei_Shablovsky

@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

????

Sergei_Shablovsky

@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 it

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..

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).

stephenw10

This should be a feature request. The ability to use local timestamps seems like a useful addition. It's not a bug though.

Sergei_Shablovsky

@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.