How to interpret node observations in the future.

[roberthadow]

This morning, my client.meshtastic.org/nodes view came up with the connected device at the top. It reported in 57 seconds ago. Completely normal. The time (date) and time zone on that device are apparently correct. It has firmware v 2.7.20.

The next 17 entries have their last observation in the future. After that, the list is normal. Some nodes were observed a couple of minutes ago, some a few days ago.

I truly was hoping to write a script that would capture stock prices, package a message, and --send it to me. ;^)

This being unlikely, I was hoping to know what might cause time and date calculations to deliver these anomalous results.

[roberthadow]

For those of you who believe my microwave forever flashes midnight --

[danditomaso]

@roberthadow I don't understand what the issue is in the interests of summarizing the nose last hesrd info. The display of last heard will show "heard X minutes/days ago". What are you requesting?

[roberthadow]

Hello @danditomaso --

Take a peak at the screen grab. It predicts that A658 WILL HEAR other nodes tomorrow. It is very specific. It predicts that E794 will be heard 22 hours from now.

The calculation is straightforward. TIMEsince = DATEcurrent - DATEobserved {where DATE is the UNIX integer value}

Unfortunately, this calculation is delivering spurious results. In the same way that solution of the kinematic problem of "How long will it take a ball currently at rest to fall 10 m?" produces two solutions, one of which is negative and has no physical significance, a display of "heard X minutes/days ago" where X is negative has no meaning in a universe that is not entirely deterministic.

[danditomaso]

Hello @danditomaso --

Take a peak at the screen grab. It predicts that A658 WILL HEAR other nodes tomorrow. It is very specific. It predicts that E794 will be heard 22 hours from now.

The calculation is straightforward. TIMEsince = DATEcurrent - DATEobserved {where DATE is the UNIX integer value}

Unfortunately, this calculation is delivering spurious results. In the same way that solution of the kinematic problem of "How long will it take a ball currently at rest to fall 10 m?" produces two solutions, one of which is negative and has no physical significance, a display of "heard X minutes/days ago" where X is negative has no meaning in a universe that is not entirely deterministic.

Thanks for the explanation. Tag me in your PR with the fixes and I'll make sure to review it.

[b8b8]

Hello @danditomaso --

Take a peak at the screen grab. It predicts that A658 WILL HEAR other nodes tomorrow. It is very specific. It predicts that E794 will be heard 22 hours from now.

The calculation is straightforward. TIMEsince = DATEcurrent - DATEobserved {where DATE is the UNIX integer value}

Unfortunately, this calculation is delivering spurious results. In the same way that solution of the kinematic problem of "How long will it take a ball currently at rest to fall 10 m?" produces two solutions, one of which is negative and has no physical significance, a display of "heard X minutes/days ago" where X is negative has no meaning in a universe that is not entirely deterministic.

In the case of our mesh we had these future node issues as well. We tracked down the offending node and even though that node had hardware GPS attached, it was providing future dated position packets to the mesh, and then causing other nearby nodes with no GPS or NTP to set the bad time. Rebooting the offending GPS nodes solved our problem, though there are still a few other nodes on the mesh with the old offending time. Strange that a GPS node could provide future time.

[roberthadow]

Hello @b8b8 --

Well that's scary! Aside from an aluminum ion clock, GPS provides the most accurate time available to everyone. It's usually accurate within 10-30 nanoseconds.

If a time error in one node can propagate to other nodes, it's a serious security flaw. There's no limit to the trouble an intruder can cause if he has control of a system clock.

Clearly someone anticipated and enabled this error. When a "time since" calculation includes code to report "tomorrow" or "in X hours" instead of failing, you have to wonder...

You are lucky. You had control of the offending node. I don't know which node was so affected. I only control my own nodes.

[b8b8]

Hello @b8b8 --

Well that's scary! Aside from an aluminum ion clock, GPS provides the most accurate time available to everyone. It's usually accurate within 10-30 nanoseconds.

If a time error in one node can propagate to other nodes, it's a serious security flaw. There's no limit to the trouble an intruder can cause if he has control of a system clock.

Clearly someone anticipated and enabled this error. When a "time since" calculation includes code to report "tomorrow" or "in X hours" instead of failing, you have to wonder...

You are lucky. You had control of the offending node. I don't know which node was so affected. I only control my own nodes.

I wouldnt really call its security issue as it pertains to Meshtastic. Time is essentially meaningless to the function of the mesh, position packets being one of the only things being affected and using the GPS/RTC time.