Repeater clocks advancing in exact multiples of 100,663.296 s (6 x 2^24 ms) observed across a regional mesh
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- c
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- C
- 星标
- 3.9k
- 派生
- 1.5k
- 平均合并
- 18 小时 59 分钟
- 30 天内合并 PR
- 28
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
meshcore-dev/MeshCore 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 63/100
meshcore-dev/MeshCore#3622 ·
维护者通常 1 天内回复
-
[Feature Request] Set Australia (Mid) Preset to automatically enable 2 byte default path hash size未关闭
难度 2/5 1-3 小时 新手友好度 62/100
meshcore-dev/MeshCore#3571 · 5 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
meshcore-dev/MeshCore#3567 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
meshcore-dev/MeshCore#3549 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
meshcore-dev/MeshCore#3513 ·
维护者通常 1 天内回复
查看 meshcore-dev/MeshCore 的全部 Issue
相似的 Issue
-
mewencode: base256[] and base128[] are indexed out of bounds by a non-ASCII octet可能已有人在做 @kazu-yamamoto 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
kazu-yamamoto/Mew#276 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 91/100
FujiNetWIFI/fujinet-firmware#2045 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
[Performance]: Qwen-Image-2.1 CPU-only on i5-10500H (6C AVX2, 32 GB): 512x512 in 7.7 min at 8 steps未关闭
难度 1/5 1 小时以内 新手友好度 84/100
维护者通常 1 天内回复
-
area:gates area:gfx found-by:critic kind:gate-defect
难度 2/5 1-3 小时 新手友好度 78/100
InauguralSystems/EigenScript#1825 ·
维护者通常 1 天内回复