Repeater clocks advancing in exact multiples of 100,663.296 s (6 x 2^24 ms) observed across a regional mesh

Ouverte
  • Quelque chose ne va pas ?
#3,565 1 commentaire 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@akkerkid y travaille déjà.

Depuis le 15/10/2026.

  • #3595 par @akkerkid — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
c
Domaine
embedded-iot, networking

Piste de recherche

Start by tracing the clock-set, RTC, and advert-timestamp paths for millisecond counters and conversions to seconds; the issue does not name files or entry points. Look for 32-bit millisecond or 24-bit tick wrap behavior, then compare the path with the reported 100,663.296-second steps. Done means identifying a trigger or narrowing it down with firmware versions or logs.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

Some MeshCore repeaters' advert timestamps jump forward in steps of exactly 100,663.296 s (6 x 2^24 ms, 0x6000000 ms, about 27.96 h). Nodes therefore sit on a lattice of 0, 28, 56, 84, 112 and 140 h ahead of real time. We could not find the trigger and are asking whether this constant is familiar.

Observation

  • Data: MeshCore adverts collected from many observers across one regional mesh, 15 days of data ending 2026-10-07.
  • Measurement: offset = the node's advert timestamp minus the time the advert was received. The investigation used the receipt time recorded by CoreScope; our own audit view uses the receipt time from our own server.
  • Of 919 repeaters with a small offset, 877 sit exactly on the 28 h lattice; 218 are currently on a non-zero level.
  • In the window we saw 72 forward one-level steps and 7 backward corrections (79 repeaters, 2 room servers and 1 companion stepped). No node stepped twice inside the window.
  • Steps happened at every hour of the day (2 to 8 per day, 15 on 2026-10-04) in every region and at every advert interval (1 to 70 h).
  • Separately, 284 flips to and from the firmware's 2024 reset constant (1715770351) were seen. These are reboots and never coincided with a 28 h step.

Example (node IDs anonymised to the first 4 hex digits)

Each row is a repeater whose median offset over 7 days (as of 2026-10-07) is close to a multiple of 100,663.296 s, and which stepped up one level inside that window.

Node Step detected (UTC) Step size Median offset now Level
6853 2026-10-03 20:51 +1 x 100,663.296 s 301,812 s 3
b5f5 2026-10-06 13:16 +1 x 100,663.296 s 301,892 s 3
eb73 2026-10-02 16:25 +1 x 100,663.296 s 201,205 s 2
4d17 2026-10-04 10:24 +1 x 100,663.296 s 100,581 s 1

The offsets match k x 100,663.296 s to within about 3 minutes. Our detector accepts a step within 600 s of k x 100,663.296 s for k = 1 to 6. The step time is the first advert seen after the jump, so it is an upper bound on when the jump happened. The first two rows are at level 3 although only one step is listed because earlier steps fall before the window.

What we ruled out

  • Observer clocks. A receiver-side clock change would move every node at once. We see single nodes stepping at different times, none twice, around the clock, and the offsets are measured across many observers.
  • The size of the step is not arbitrary: 6 x 2^24 ms = 100,663,296 ms = 100,663.296 s exactly.
  • Reboots. Those show up as the 2024 reset constant instead, never as a 28 h step.

What we could not determine

  • The trigger. Steps are not tied to a time of day, an advert interval, or a region.
  • Firmware versions. We do not have firmware versions for these nodes, so we could not compare affected and unaffected builds or hardware.

Related threads

These came up while searching and do not appear to describe this: MeshCore #2416, #1329 and #1514; MeshCore-WebAgent #302; Attadipa #770.

Ask

  • Is a 32-bit millisecond counter wrap or a 24-bit tick wrap known anywhere in the clock-set, RTC or advert-timestamp path (for example a millisecond value multiplied or shifted into seconds)?
  • If you would like logs or a larger sample of the data, tell us what format helps and we will provide it.
Langage dominant
C
Étoiles
3.9k
Forks
1.5k
Merge moyen
2 j 8 h
PR mergées (30 j)
36

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de meshcore-dev/MeshCore

Toutes les issues de meshcore-dev/MeshCore

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.