NTP over LoRa

[mikecarper]

https://github-wiki-see.page/m/hardwario/lora-modem/wiki/Time-Synchronization

Something simple like this. Only serial or gps devices can send these. Probably limit to 1 hop so time drift doesn't get too high
{
"type": "time_sync",
"epoch": 1719082800,
}

[seagull9000]

This may be a silly question but it has been nagging at me for some time ...

.. why can't repeaters use the timestamps in passing messages for time sync?

If we assume that the App device has good time, then I don't see why this wouldn't work. Granted, there may be a few seconds delay when a significant number of multiple hops are involved from when the App timestamps the message and when the repeater receives it.

As in the above post, you could limit the drift by limiting the hops from which a repeater will take the time. This might then cause some remote/intermediate repeaters in a path to never update, though. Maybe make the number of hops for a valid timestamp configurable in those repeater but default to 1 otherwise.

It would avoid the need to flood time sync signals around (which could have the same multi-hop issue anyway).

In case of bad actors, the repeaters could refuse to sync outside a certain range or ensure it gets a number of consistent time stamps before acting on them. They would need to have a base time for an unset clock so this can be used as an exception to this rule.

[lucidnx]

yeah, I'v had same idea. RadioLib can do TX time calculation so FW can be compensating delays. probably it's already happening if you sync time manually.

[zjs81]

Added a pull request using @seagull9000 's suggestion

[n2aws]

@zjs81 great work!

I'd actually like to see this go a step further, probably as another "issue". but, since repeaters will typically be in decent locations, and GPS hardware is so inexpensive now, it'd be awesome if repeater firmwares allowed the device to get time directly from GPS, and then became "stratum 1 timeservers" to the rest of the mesh. This would help alleviate the problem mentioned above about nodes that are many hops away not being synced, because a nearby repeater could just have a GPS module installed... Also, with companion firmware, I know the GPS needs to be re-enabled on each node restart but for repeaters, I think it should default to being on if hardware is found..

Thoughts? Should I open this as a separate issue?

[mikecarper]

Be able to have an ACL of Trusted sources of time with the ability to turn back the clock in the case of the remote trusted node not working correctly is needed. Time sync has to be done with a public key to prevent forgeries; replay attacks can be prevented by having the requesting node send a hash to the trusted source of time and that hash has to be sent back along with the correct time. Using the ACL to sync time should happen 15 minutes after boot so someone setting it up can manually sync before this happens.

On boot wait 30 minutes plus random time (0-60 minutes) before sending out an advert. Have other non repeater nodes keep a list of all known timestamps. If the same timestamp is found then that advert can be ignored.

[Beanow]

This is harder than it might seem. Depending on how accurate you want the time to be.

Using untrusted companion messages as a time source is straight up not a good idea.
You'd make the repeater trivially vulnerable to manipulating it's time, which may case DOS/security vulns.
So you need trust.

But how're you going to find a trustworthy source, ideally at a consistent 0 hops and latency, for all those repeaters out there?

Even if you have a direct neighbor with GPS reference, your neighbor would need to take special care to prioritize the response differently from a normal message queue, adding another DOS problem to that neighbor.

Maybe you could listen for a direct neighbor, that you know has GPS time, and sync your clock to it's advert if it's 0 hop.
But I still wouldn't trust it as even remotely accurate. This might be good for "within a few seconds".
But why settle for that if you can cheaply get a repeater with GPS and get "within a few nanoseconds."?