[NWA130BE] - NTP sync delayed

Options
2»

All Replies

  • Zyxel_Judy
    Zyxel_Judy Posts: 2,683 image  Zyxel Employee
    Zyxel Certified Network Engineer Level 2 - Nebula Zyxel Certified Network Engineer Level 2 - Switch Zyxel Certified Network Engineer Level 2 - Security Zyxel Certified Network Engineer Level 1 - Nebula
    Options

    Hi @Maverick87 ,

    Thank you for the detailed explanation — that helps clarify the severity of this request. Accurate time for connect/disconnect logging and debugging is a valid and common use case.

    To clarify our earlier reply: we're not disputing that this behavior needs improvement. Asking about your use case was meant to help us prioritize and frame this internally, not to downplay the impact.

    We agree the current 6-hour fixed retry, without a shorter retry, isn't ideal. We do have backup NTP sources configured (time.apple.com → time.cloudflare.com → time.windows.com), but in your scenario, since the firewall hasn't finished booting and there's no internet access yet, these backup sources aren't reachable either — so they don't help in this case.

    To sum up, we've already submitted your request, along with the scenario and reasoning, to our internal team for further discussion. In the meantime, if you'd like to keep your current setup, you can click the "Sync Now" button to manually trigger the time sync.

    Zyxel_Judy

  • Maverick87
    Maverick87 Posts: 359 image  Master Member
    Zyxel Certified Network Administrator - WLAN Zyxel Certified Network Administrator - Nebula Zyxel Certified Network Administrator - Security Zyxel Certified Sales Associate
    edited August 27
    Options

    Hi @Zyxel_Judy,

    Sorry if I wasn't able to explain myself clearly.
    Thank you so much for submitting the new bugfix request already.

    And please, if you have any news about the fixing, tell me and keep me updated so I can maybe get the weekly update and try the new release.

    Also, it appears this is actually a bug in the newly released feature.
    For this reason, it shouldn't be resubmitted as a new feature for a vote, but rather simply fixed.

    Thank you

  • Zyxel_Judy
    Zyxel_Judy Posts: 2,683 image  Zyxel Employee
    Zyxel Certified Network Engineer Level 2 - Nebula Zyxel Certified Network Engineer Level 2 - Switch Zyxel Certified Network Engineer Level 2 - Security Zyxel Certified Network Engineer Level 1 - Nebula
    Options

    Hi @Maverick87 ,

    For a standalone AP, Internet or NTP connectivity may not always be available. Based on this consideration, the current design uses a longer retry interval after an NTP synchronization failure. At this time, no change to the current retry behavior is planned.

    We understand your concern regarding accurate system time for log review and troubleshooting, and we've noted the proposed fixed-interval and variable-interval retry mechanisms as feedback for future consideration.

    By the way, we'd like to clarify: the option to use an internal NTP server on the network is not new to 7.40 — it's a feature that's been available for a while, and you had used it before as well. And the 6-hour retry behavior after a failed sync isn't a behavior tied to the 7.40 release specifically.

    Zyxel_Judy

  • Maverick87
    Maverick87 Posts: 359 image  Master Member
    Zyxel Certified Network Administrator - WLAN Zyxel Certified Network Administrator - Nebula Zyxel Certified Network Administrator - Security Zyxel Certified Sales Associate
    Options

    Hi @Zyxel_Judy,

    Yes, I know, the problem I reported a while ago was that if a local NTP wasn't available at the time of the request, the AP would no longer retry the local one, but would retry information from a public NTP (effectively ignoring the manually entered NTP).

    So, in the past, I opened a ticket because the AP wouldn't retry the local one. That said, when this problem arose, retries to public NTPs were more frequent (I think every 10/20 seconds).

    And here some screenshot:

    image.png image.png

    As you can see, the retry on public NTP server was around 10/20 seconds, also with different public server.

    At the time, my request was to retry not only the public NTPs, but also the local NTP manually entered in the field (since after the first retry, it was ignored).

    Now, this behavior has been fixed; the NTP used is exclusively the one entered in the form, but at the same time, the retry time in the event of a failure has been deliberately increased (there was never any mention of retry problems).

    This is why I'm reporting it as a bug today and as something that should be fixed as soon as possible (I repeat, with the old firmware the retries were much closer together).

    Thank you