Thread - LastCommTime and Timestamp

[ryanbryngelson]

In the THCI response to a GetNeighborInfo request, what time base does the field LastCommTime have?  For instance, when I power cycle a device and begin reading neighbor info, some neighbors come back with a LastCommTime of greater than 4200.

I see in thci.c LastCommTime is defined as...

lastCommTime = ((uint32_t)TmrMicrosecondsToSeconds(TMR_GetTimestamp()) - pThrNeighbor->timestamp);

Is pThrNeighbor->timestamp restored from non-volatile memory?  I'm trying to figure out LastCommTime for a neighbor comes back as a large number when the device has only been powered up for less than 60 seconds.

How does the field Timeout relate to LastCommTime?  Let's consider a REED device, will a neighbor ever drop off the list?  For instance, let say we have tree devices, X, Y, and Z.  All three are REEDs (they all are routers) and X is the leader.  X can directly communicate with Y, Y can directly communicate to Z, and X can communicate to Z via Y.

X  -->  Y  -->  Z

In my experience, X shows Z as a neighbor even though it can't directly communicate to it.  The reading the neighbor info out of X, Z's LastCommTime continues to grow and the Timeout is 0.

Any help in understanding the LastCommTime and Timeout fields with respect to neighbors would be appreciated.

Thanks,

Ryan

[anthony_huereca]

Hi,

  The large LastTime values are likely caused by stale neighbor entries, and will be fixed in the next release. The last time value is the difference between current timestamp and the timestamp of the last MLE packet received from that neighbor. In the neighbor table we only store the last communication timestamp and after a NVM restore all timestamps are restored to 0 as there is no other way of recreating the timestamp information.

The timeout value has multiple uses. It is used to store the timeout of a child (default 240s) and also used as a timestamp when performing a link sync with that neighbor. It is normal to have neighbors with 0 as they are other routers and for them the timeout field has no meaning.

-Anthony 

[anthony_huereca]

Hi,

  Yes, the neighbor table can be restored from NVM which is what I think is causing those long LastComm time values. I'll work to get some more details on that and the timeout value.

-Anthony