Manually Set Initial Time for 1st Boot on custom builds?

Hey guys,

The issue I run into, vpn cert creation date does not sit well the cfw build date and I have to wait (up to 10 mins I think) before time syncs and vpn is operable again.

Anyway to adjust the default date and time in a custom build? Is there a file somewhere I can edit?

1 Like

rescheduling or conditionally starting the vpn/creation based on time acquisition would be better imho.

sample function exit if 1 or other from time dependent script
file="${file:-/tmp/state/dnsmasqsec}"
slpWAIT=${slpWAIT:-2}
tries=${tries:-11}

x=0
while [[ "$x" -lt $tries ]]; do
	if [[ -f $file ]] ; then
		$ecmd "checking for $file run: $x [ok]"; sleep 1
		break
	fi
	$ecmd "checking for $file run: $x [no-time]"
	sleep $slpWAIT
	x=$(($x+1))
done; 

if [[ ! -f $file ]] ; then $ecmd " gave up waiting for $file" && return 1; fi
return 0
2 Likes

touch anything in /etc/ in a running device with persistent overlay mounted or look into SOURCE_DATE_EPOCH (as I recall) in the build system.

Waiting for time sync is probably the “right” solution, especially for WireGuard.

5 Likes

Most routers have no realtime clock, so when the router starts, it needs some approximation of the correct time. The files in /etc are used as the reference, and the newest time stamp from there is used.

After flashing and reboot, there are only files from the build date, so the router time starts from the build time.

Like Jeff said, you can set a suitable time during build. By default it is the time of the most recent source commit (to enable reproducibility).

For my own builds I set it to the current time just before the final make. If there is a file "version.date" in the build root dir, that time is used. So I use that mechanism in my build scripts:

Override git/svn timestamp after r48583-48594, set initial clock to now:

date +%s > version.date

That is one way of setting time at build time. But if you flash that after two weeks the router still starts from the date set inside the firmware to two weeks ago (today).
Waiting for correct date before creating certs is likely a better approach. Or, including pre-created certs in the build.

You can also use that version.date approach to ensure that the initial date is inside the validity period of the pre-created cert that you include in the build.

5 Likes