Wireguard doesn´t always startup on coldboot (EA6xxx) - Possible Reason: Busybox invalid NTP Time and Timeout at early stage.

[maverick3005]

Today i had a short power outtage and after reboot, the wireguard Session was down after 1 hour. I have autostart enabled and retry with peer-check set to 5 Minutes. In case of ip6, it is normal, that it mostly needs 2-3 trys in 5 Minutes intervals to have working session.

Is there any other Timeout or a typo in the code, when it needs much more time, so really endless try is always working, without "giving" up after a while ?

With regulary reboot or after an upgrade is made, it always started up - but not always when coldstarted via power on/off.
(is cron not always running at every scenario ?)

[maverick3005]

Add:
I found another Issue when a power surge accoured:

After a hard coldrestart the ntp-time is no longer updated. I saw this 20 Minutes after power was again back. When ntp-settings are reloaded/saved the time is asap updated. That was not the case in earlier versions. It looks like it has todo with the "periodical update", and just the "1 time update" at cold boot time.

Problem case here: The Front-L2 switches needs 2-3 Minutes longer to boot up. FTTH-Gateways/DSL-Router, etc. needs typicly 3-5 Minutes, too. So the router boots to early and still has no valid WAN/vlan available at this moment. This way after a few trys, wan/ntp can´t be updated and the clock goes wrong - which has an impact to the VPN-Protocols - which needs a correct time before they are
starting up!

My solution should be: When a coldstart finished and wan is still in an "early state", ntp should be first try as long as it needs again and again, not just a few times and gives up - and the next try is then hours later - what is defined with "periodic updates".
Eventualy a new Option for the NTP-Menu is an idea: "Force waiting for valid time at initial boot: yes/no" - this way it is basicly trying "forever" until one ntp-server ich really reachable - then change to the periodic setting - which can be an another enhancement more user settable at which steps a refresh is made (like minimum 30 Minutes and up to 24 hours, etc,)

My wireguard was asap working again, just at the moment, the Router got a valid time.

...it´s a unlucky cascading problem...

[maverick3005]

Reading further about busybox implemented ntpd, informations shows, that DNS is resolved ONLY ONCE - and never again. When using only DNS-Addresses from the pools, always the same IPs will be used - unless the daemon is restarted. To overcome this issue i have set 3 static IP addresses of well known servers and one DNS pool-address.

However, the problem is the starting order:

One Option is to delay the start of ntpd until WAN-DHCP is done - but this will not work reliable in all Scenarios. A better option is by using the "hotplug-option": When the Status of the WAN-Interface is changed, like got valid DHCP-Adresses, AND the connections is working, use the hotplug system to restart/cold start the ntpd daemon latest.

Finaly there is just a simple Scenario in many configurations not unusual:

No matter if the Router works as Bordergateway with static-IP, DHCP oder PPPoE via WAN Port or just as "IP-Client" by using only the LAN side with static internal defined Defaut-Gateway & DNS: When one or more L2-Switches are in the System, and between this Distribution-Switches is a longer outtage, reboot or cross connect issue - which is temporary the case after an unexpected power outtage, the Tomato is mostly earlier UP, as many Switches, which need longer boot-times. The Port to the Tomato is at this moment still down, or it is up, but the switches are still in a booting phase. Booth Scenarios resulting in failed ntpd start, because DNS and NTP-Servers reachability is still not working. The "retry/resync" Option on the other side expect a working DNS at the time, the daemon is first started. So we need a more reliable option to make sure, Default-Gateway/Access AND DNS resolving is working before ntpd is really started. Failing IPs from a pool over time can be resolved when we use the ntpd in combination with a cron-job, which stops/starts the daemon user settable more times. Further i found out, when a ONT from a Fiber network is directly connected to the WAN-Port, many ONT-Models have a boot-time of 3-5 Minutes to be fully in Sync with the OLT. When PPPoE comes on top, this delays the process even more. The Result is the same: "Invalid" Time. Some VPN-Tunnels will not be working, because of System-Date 01-01-1970 at this stage.

Practical we need an Option after a coldboot, which checks minimum for 5-10 Minutes for a working Uplink/Reachability & working DNS to resolve all defined ntp-servers. When this is working, usualy the ntpd can runs many months without the need of a restart later. Needless to say, that this check needs to be non-blocking for the rest of the boot-process and should be run in the background.

Open Question: A minimal "real OpenNTP" Package as a replacement Option for ARM-Routers with much more available Flash for AIO Images have the ability to support much more Options, including full ip6 Support. Or some Tomato-Specific Patches for the
Busybox Code to handle the "early unreachable" Problem much better ?

To be clear: The "dynamic" Refresh ONLY works, when at the time of startup ALL Servers are resolvable - and only at this point the IPs are cached for the later "refreshing".

[pedro0311]

Yes, it would be nice to have that option. Anyone interested in PR?

[HommeOursPorc]

FWIW, I've asked Gemini and it says that the problem is in busybox ntpd code:

There are several critical logical flaws in the provided ntpd.c snippet that prevent the daemon from handling failures and executing retries correctly. The issues range from orphaned fallback constants to fatal system calls and unhandled pointer states.
Here is the breakdown of why this implementation fails to retry properly:

1. Unimplemented Backoff Constants
   The developer defined specific backoff parameters to handle timeout scenarios, but failed to actually write the logic to use them.

• The file header clearly defines #define NOREPLY_INTERVAL 512 to cap queries that receive no response, and #define HOSTNAME_INTERVAL 4 to handle failed DNS lookups.
• However, a complete scan of the source reveals that neither NOREPLY_INTERVAL nor HOSTNAME_INTERVAL are ever utilized in the execution paths.
• When a query is successfully pushed to the network, send_query_to_peer schedules the next action using set_next(p, RESPONSE_INTERVAL);, which sets a rigid 16-second timeout.
• Because the 512-second NOREPLY_INTERVAL is completely orphaned from the code, a server that stops responding will bypass the intended backoff mechanism entirely, leading the daemon to hammer the unresponsive peer at incorrect intervals.

2. The DNS Resolution "Blackhole"
   If the initial hostname lookup fails, the peer gets stuck in an unhandled state that skips the internal event timer entirely.

• When a new peer is registered in add_peers, the timer p->next_action_time is initialized to G.cur_time, and the daemon attempts an immediate resolve_peer_hostname(p).
• If resolve_peer_hostname(p) fails, the pointer p->p_lsa remains NULL because the struct was initially zeroed out by xzalloc.
• When the event loop later triggers send_query_to_peer(peer_t *p) to execute the pending action, the function immediately checks if (!p->p_lsa) and aborts with a return;.
• Crucially, returning early skips the set_next() function block at the bottom of send_query_to_peer.
• Because p->next_action_time is never advanced into the future, the timestamp remains permanently stuck in the past. Without logic to call resolve_peer_hostname again, the event loop will trigger this peer instantly and continuously, causing an endless spin instead of actively retrying the DNS resolution.

3. Fatal System Calls on Socket Creation
   The choice of standard BusyBox wrapper functions creates an environment where temporary network disruptions act as fatal process errors.

• When p->p_fd == -1, send_query_to_peer must acquire a fresh socket before it can transmit.
• To do this, it calls xsocket_type and xbind.
• In the BusyBox API, libbb functions prefixed with x are strict wrappers that do not return an error code; they immediately call die() or exit() to terminate the process if the underlying system call fails.
• If a routing interface drops, or if the daemon attempts to bind an address family (like IPv6) that the kernel dynamically loses support for, xsocket_type or xbind will crash the entire daemon.
• This design fundamentally breaks the daemon's ability to reach the graceful fallback logic located further down in the function, where a standard do_sendto(...) == -1 failure safely closes the file descriptor and securely schedules a RETRY_INTERVAL of 32 seconds.

Gemini suggest 2 different approach to fix the problem.

1. Use cru job:
I don't know why Gemini want me to use Linux shell script so much... And this code is probably wrong... But let's focus on the idea. Gemini suggest making a helper script that will check if the time is still set to the default time and if so it will call ntpd_restart. Pretty simple but not a very good solution IMO.

int retry_mins = nvram_get_int("ntp_retry_mins"); /* Grab user option from GUI */

if (retry_mins > 0) {
    char cron_str[128];
    FILE *wd;

    /* 1. Generate a lightweight watchdog script in /tmp */
    if ((wd = fopen("/tmp/ntpd_watchdog.sh", "w")) != NULL) {
        fprintf(wd, "#!/bin/sh\n");
        /* Check if ntpd is dead OR if the router year is still the default 1970/1969 */
        fprintf(wd, "if ! pidof ntpd >/dev/null || [ \"$(date +%%Y)\" -lt 2020 ]; then\n");
        fprintf(wd, "  /sbin/ntpd_restart\n");
        fprintf(wd, "fi\n");
        fclose(wd);
        chmod("/tmp/ntpd_watchdog.sh", 0755);
    }

    /* 2. Schedule the custom cron job */
    snprintf(cron_str, sizeof(cron_str), "*/%d * * * * /tmp/ntpd_watchdog.sh", retry_mins);
    eval("cru", "a", "ntpd_watchdog", cron_str);

} else {
    /* 3. Fallback to the standard daily restart if option is disabled */
    eval("cru", "a", "ntpd_restart", "11 4 * * * /sbin/ntpd_restart");
}

2. check if DNS work first:
If you want to eliminate the problem at the root without needing a GUI option, you can stop FreshTomato from launching ntpd until DNS is actually routing.
Instead of calling _eval(ntpd_argv, NULL, 0, NULL); directly, write a launcher script that runs in the background. This blocks ntpd from starting until nslookup succeeds, bypassing the BusyBox fatal flaw entirely.

/* Inside start_ntpd(), replacing the _eval() call */
FILE *lf;
if ((lf = fopen("/tmp/ntpd_launch.sh", "w")) != NULL) {
    fprintf(lf, "#!/bin/sh\n");
    /* Wait up to 30 seconds for Stubby/DNS to establish */
    fprintf(lf, "for i in 1 2 3 4 5 6; do\n");
    fprintf(lf, "  if nslookup pool.ntp.org >/dev/null 2>&1; then break; fi\n");
    fprintf(lf, "  sleep 5\n");
    fprintf(lf, "done\n");
    
    /* Reconstruct the argv string here and exec it */
    fprintf(lf, "exec /usr/sbin/ntpd ");
    /* ... loop through ntpd_argv to append flags ... */
    fprintf(lf, "\n");
    
    fclose(lf);
    chmod("/tmp/ntpd_launch.sh", 0755);
    
    /* Launch asynchronously so we don't block the rc boot sequence */
    xstart("/tmp/ntpd_launch.sh"); 
}

Again Gemini is focused on helper script/Linux shell script... I prefer the second idea --> if DNS is not up yet, retry until DNS is up.

Just ideas.

[pedro0311]

@maverick3005 : try image after this commit: 21090e9

[pedro0311]

@maverick3005 : Please let me know when you test it.