Bug on LOM Date and Time

[israelfds95]

During a recent deployment of a clusterXL 19100, I encountered an unexpected issue with the LOM (Lights-Out Management) Date and Time configuration on two different gateways.

Before investigating further, we verified that the issue was not related to NTP connectivity:

• The LOM management IP had connectivity to the customer's internal NTP servers.
• We also confirmed successful communication with external NTP servers that we tested.
• Despite this, the issue remained regardless of whether the time was configured manually or synchronized through NTP.

Observed behavior

• Saving the time manually (without NTP) does not work correctly.
• Automatic synchronization using either a local or external NTP not update the time
• Every time the configuration is saved, the LOM clock automatically advances by 3 hours.

For example, if the correct local time was 09:10, after saving the configuration the LOM would display approximately 12:10. Saving the configuration again would increase it by another three hours, and the behavior would continue with every save.

Troubleshooting performed

The issue was reproduced on two different gateways.

Both gateways were initially running LOM firmware 7.17.1. As part of the troubleshooting process, I upgraded both to the recommended LOM firmware 7.19.2, but the behavior remained exactly the same.

Additional observations

To rule out configuration issues, I also tested multiple time zone settings, including:

• America/Sao_Paulo
• America/Fortaleza
• GMT-3

I also tested both manual time configuration and synchronization with the following external NTP servers:

• ntp.checkpoint.com
• ntp2.checkpoint.com

The behavior remained exactly the same in every scenario.

What made this issue particularly unusual is that every time the configuration was saved, the LOM clock advanced by another three hours, regardless of the selected time zone or whether NTP was enabled.

Example:

Actual Local Time	Action	LOM Time After Saving
09:10	First Save	12:10
12:10	Change Time Zone (America/Sao_Paulo) + Save	15:15
15:15	Change Time Zone (America/Fortaleza) + Save	18:20
18:20	Change Time Zone (GMT-3) + Save	21:30
21:30	Configure Check Point NTP + Save	01:31 (next day)

Additionally, all timestamps in the LOM event logs matched the incorrect LOM system time, confirming that the issue affected the LOM clock itself rather than only the web interface.

Workaround

As a temporary workaround, I manually configured the LOM clock to 3 hours behind the correct local time before saving the configuration.

After saving:

• The displayed time became correct.
• Re-enabling NTP synchronization kept the correct time.
  
  The screenshot below illustrates the workaround. Although the correct local time was 09:22, I manually configured the LOM clock to 06:22. After clicking Save, the LOM automatically added three hours, resulting in the correct displayed time (09:22), even with NTP enabled
  
  
  
  

Although I found a workaround, I opened a TAC case to investigate the root cause and determine whether this is a known issue or a software bug.

Once TAC provides a definitive answer, I'll update this post with their findings so others who encounter the same issue can benefit from it.

Has anyone else experienced this behavior or found a permanent solution?

[Lesley]

Are you sure that the bios clock, system firewalls and timezone are configured the same as the lom. Aswell the time source 

The time settings for LOM are automatically synchronized with the Security Gateway operating system (on 21000 appliances) or the BIOS (on 5000, 6000, 7000, 13000, 15000, 16000, 23000, 26000, 28000, and Smart-1 appliances) when the appliance is turned on.

You can also manually enter the date and time settings, or configure the settings for an NTP server to automatically update them.

[Zolo]

Hi,

Do you have any new information from TAC?

[israelfds95]

Unfortunately not; I explained the situation several times in the support ticket, but they didn't provide a solution.

[Chris_Atkinson]

Hello - Could you please escalate the SR and share the SR# via DM?

[Bob_Zimmerman]

This behavior is definitely a bug in the LOM software. It suggests to me the clock is written to the RTC as local time (no time zone conversion), but read as UTC and converted to local time.

If you set the time zone to UTC-1, does it step one hour at a time?

[iurysantanachkp]

That’s great!

[CaseyB]

Was any more progress ever made with TAC on this?

Our LOM is running 7.18.1 with no time issues, I upgraded to v7.19.2 AND v7.19.3, both of them are broken for time.

Looking at the log entries:

• The highlighted entry is NTP checking-in after the reboot downgrade back to 7.18.1
• None of the upgrades to 7.19.X had an NTP check-in after reboot
• I also could not get an NTP check-in to happen toggling NTP on / off

LOM-ntp.png

[israelfds95]

Unfortunately, TAC didn't provide a solution; they opened a task with R&D for an internal investigation. Since I didn't receive a response and managed to resolve the issue using the workaround I mentioned, I closed the ticket with TAC. If you have opened a ticket, please share any new information or updates here.