Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Gomboragchaa
Advisor

Log Time difference

Jump to solution

I have Management R80.10 take 121. Times in logs is one hour late.

I tried sk61941 but no success, enabling NTP didn't help.

When running #hwclock --systohc time is synchronized but not the logs timestamp.

We using few time based rules. Time issue affected rules also.

It looks like there is a bug.

Is there any information if this is bug or maybe I am doing something wrong?

1 Solution

Accepted Solutions
Dror_Aharony
Employee
Employee
16 Replies
_Val_
Admin
Admin

Log time stamps could be affected by log server own timezone. Please make sure both MGMT and GWs are configured the same way and show the same local time and time zone.

Also, why are you using ULAST? ULAT should be good enough.

Gomboragchaa
Advisor

Thank you for reply,

It is stand-alone deployment. I tried with ntp and without ntp. Unfortunately still 1 hour late on log...

ULAST and ULAT is the almost same. It is syncing from official local time server.

Timezone is not important Smiley Happy. We can change it. 

0 Kudos
_Val_
Admin
Admin

Try changing it to ULAT and if this does not help, please open a support request with TAC

0 Kudos
Gomboragchaa
Advisor

I contacted TAC engineer. Then TAC engineer received answer from R&D.

It is expected issue and they haven't any plan to fix next jumbo hotfix. Also they will solve on R80.20.

Unbelievable...

0 Kudos
Tomer_Sole
Employee Alumnus
Employee Alumnus

Hi,

I apologize for the phrasing of the response by our Support.

There are certain fixes we just cannot do for jumbo updates of a version. Jumbo fixes are stability fixes. If there is a bigger risk level involved, we choose to delay the fix and bundle it with a version upgrade, for quality reasons. I hope that you understand.

With the recent change in strategy of issuing a security management version more frequently (see: R80.20.M1 and the next ones) this means more solutions will be on a maintrain release than before.

0 Kudos
_Val_
Admin
Admin

Tomer, could you please advise how to fix or work it around meanwhile?

0 Kudos
Tomer_Sole
Employee Alumnus
Employee Alumnus

Sorry i don't have the details here. It is probably better to ask on that TAC case if there is a workaround that can be done.

0 Kudos
_Val_
Admin
Admin

Okay, I will follow up myself

0 Kudos
rubasjak
Explorer
hello Valeri,
i would like to ask you if there is any new info about this issue. Our customer also has this problem with R80.10 and we would be interested in workaround for now.
Thank you,
JR
0 Kudos
Gomboragchaa
Advisor

Thank you for your information.

That issue should be fine for me. But I spend 2 days on this issue. 

I think Check Point need to release any official statement on every known bug...

JozkoMrkvicka
Leader
Leader

oh, Check Point doesnt have such a resources for that... update it every 30 minutes with new bugs 😮

Just wait for R80.30 and till then enjoy R77.30.

Kind regards,
Jozko Mrkvicka
_Val_
Admin
Admin

At Check Point, we appreciate your opinion. Let me just say that we take quality of our products very seriously. If you have any particular request or suggestion, feel free to contact me directly at any time.

Thank you

Baasanjargal_Ts
Advisor
Is there any way to fix it on R80.10 distributed deployment.? Traffic log shows one hour behind real world time.
0 Kudos
Baasanjargal_Ts
Advisor
Is there any update.?
In R80.10 Distributed deployment, There is one hour variation. Is there any way to fix it.
0 Kudos
Dror_Aharony
Employee
Employee
Dror_Aharony
Employee
Employee

Correction: only fixed to JumboHF ongoing take 245 (not yet the public one):

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

0 Kudos