[Feature Request] Use system clock instead of companion clock for outgoing packet timestamps #171

New Issue

2026-10-05T02:01:46+02:00

adam commented

2026-10-05 02:01:46 +02:00

Currently, all messages sent via RemoteTerminal are using the companion's clock as source for the packet timestamp.

In Liam's Android App it is possible to use the client clock instead - aka Android device clock, to be found in experimental radio settings.

=> would be great if RemoteTerminal would offer the same as an option because in many cases the system clock of the device running RemoteTerminal usually can be trusted more because it's ntp-synced - opposed to the companion which - as in my case - may have no rtc nor gps at all.

Additionally this will protect from clock poisoning via received packets having bad timestamps because Meshcore companion firmware may automatically sync companion's clock based on incoming packet timestamps and currently there is no way to disable that feature.

Edit: not sure anymore if all of this is true.... what appeared to be poisoned packets changing companion clock turned out to be an issue on the sender-with-wrong-clock's side....

Currently, all messages sent via RemoteTerminal are using the companion's clock as source for the packet timestamp. In Liam's Android App it is possible to use the client clock instead - aka Android device clock, to be found in experimental radio settings. => would be great if RemoteTerminal would offer the same as an option because in many cases the system clock of the device running RemoteTerminal usually can be trusted more because it's ntp-synced - opposed to the companion which - as in my case - may have no rtc nor gps at all. Additionally this will protect from clock poisoning via received packets having bad timestamps because Meshcore companion firmware may automatically sync companion's clock based on incoming packet timestamps and currently there is no way to disable that feature. Edit: not sure anymore if all of this is true.... what appeared to be poisoned packets changing companion clock turned out to be an issue on the sender-with-wrong-clock's side....

adam closed this issue

2026-10-05 02:01:46 +02:00

adam commented

2026-10-05 02:01:47 +02:00

We always use the host clock for outbound message timestamping 🙂 We don't expose it as an option as we always assume that host time is WAY more reliable than a little dinky RTC that can't even go backwards haha.

We always use the host clock for outbound message timestamping 🙂 We don't expose it as an option as we always assume that host time is WAY more reliable than a little dinky RTC that can't even go backwards haha.

adam commented

2026-10-05 02:01:47 +02:00

Ok, great! That's my preferred option. Thanks for clarifying.

Ok, great! That's my preferred option. Thanks for clarifying.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Remote-Terminal-for-MeshCore#171