要約

  • RIPE Atlasのfirmware 5130は、5120がNTPの時計差ではなく往復時間の半分をoffsetとして報告したと説明する。5120のoffsetは誤りだが、RTTは影響を受けていない。
  • 8月31日03:12 UTCの公開APIでは、Connectedかつ5120のプローブ記録が2,721件、5130が2,350件、Connected全体が14,680件だった。
  • 2,721件は誤結果の件数ではない。一方、NTP結果にはfw、prb_id、時刻があるため、5120行を識別して除外するための結合キーは既に存在する。
  • 必要なのは、影響フィールド、非影響フィールド、実際の期間、処置、後継release、改訂履歴を結ぶ機械可読なerratumである。更新状況の台帳と過去データの品質台帳は別にすべきだ。

一行から分かること、分からないこと

RIPE AtlasのNTP結果フォーマットは、測定値の周囲に出所情報を残している。fwはfirmware、prb_idは送信元プローブ、timestampは結果時刻を示す。resultの中ではoffsetとrttが別の値として置かれ、origin、receive、transmit、finalの四時刻も記録される。

したがって、5130の告知を知っている利用者はfw=5120のoffset結果を除外できる。ホストの個人情報は要らない。5120プローブが生成したpingやtracerouteまで無効とする根拠もない。RIPE NCCは、今回の回帰ではRTTが影響を受けないと明記している。

しかし、その行だけでは訂正の権威が分からない。いつからいつまで除外するのか。再計算してよいのか。どの版の告知に従ったのか。fwはソフトウェアの身元を示すが、後から変わった品質判断までは保持しない。

人が5130のページを先に読めば、queryへ条件を足せる。だが、定期取得するclient、既に凍結された研究snapshot、結果fileだけを受け取ったarchiveは、その文脈を自動では取得しない。stableなerratum IDがなければ、各組織がrelease文を別々に手順書へ写し、同じ警告を採用したかどうかさえ後で照合しにくくなる。

発見入口はproduct、result type、firmwareから検索できる必要がある。利用者にrelease noteの所在を先に知ることを要求すれば、古いdatasetを再利用した時点で同じ見落としが繰り返される。結果から後発の品質状態へ辿れることが重要だ。

5120は「修正済み」の状態から再び開かれた

この欠陥には二段階がある。

issue 130が2025年7月11日に開かれたとき、報告は符号の問題だった。四つのNTP時刻は正しいが、offset計算の順序がRFCと逆で、符号が反転するという内容である。

同年10月29日のsoftware probe 5120はoffset計算の修正を掲げた。このreleaseはsoftware probeだけを対象にした。RIPE NCCのコメントは同日、特定commitで修正したと述べた。

2026年7月23日、5130に向けた試験中にissueは再開された。保守担当者は、前のcommitが直しておらず、むしろ悪化させた可能性があると書いた。提示されたpatchはRFC 5905の式に従い、四つの64-bit固定小数点時刻からRTTとoffsetを別々に求めるものだった。

5130のreleaseは8月12日、5120がoffsetとしてRTTの半分を返したと確定させた。5120のNTP offsetは不正確、RTTは非影響。issueは5130とcommit 197b599a7faa811d97ebd273078be176842264bbで閉じられた。

最初の符号誤りと5120の半RTT回帰は、同じ誤値を言い換えたものではない。過去データを扱う規則は、その結果がどの状態のコードから出たかを区別しなければならない。

接続数は結果数ではない

8月31日のキャッシュを避けたAPI取得では、5120かつstatus=1のプローブが2,721件だった。応答中のstatus名はConnectedである。同時点で5130は2,350件、Connected全体は14,680件だった。5120は全体の約18.5%となる。

この比率を「NTPデータの18.5%が誤り」と読むことはできない。プローブがNTPを実行したか、測定を何件生成したか、複数プローブが同じ運用者かは、この問い合わせでは分からない。各ホストがいつ5120を導入し、いつ5130へ移るかもrelease日とは一致しない。

それでも、5120の告知後も対象versionがConnected状態に大量に残ることは確認できる。ここから得られるのは展開の状態であって、データ被害の分母ではない。

release日を影響期間にしてはいけない

5120の公開日は2025年10月29日、5130は2026年8月12日である。この二日を全プローブ共通の開始・終了時刻にすると、インストールのばらつきを消してしまう。8月31日に5120が2,721件残っていたこと自体が、その単純化を否定する。

機械可読な訂正票は、stable IDとrevisionを持ち、RIPE Atlas NTP schema、firmware 5120、影響を受けるresult[].offset、影響を受けないrttを示す必要がある。そのうえでfw、prb_id、結果識別子、時刻を使ったselector、各流の最初と最後の対象、除外・再計算・置換のどれを求めるか、5130と修正commit、通知経路、更新履歴を結ぶ。

現在の公開情報から安全に選べるのは除外である。「RTTの半分だった」という説明だけで全offsetを一律に算術変換するのは、新しい保証を勝手に作ることになる。error結果、再試行、architecture、version切替の境界を含む正式な再計算契約が必要だ。

firmware移行とデータ訂正を別々に完了させる

移行台帳は、取得時刻とversion別Connected件数を追えばよい。5120が減り5130が増えるなら、現場のsoftware stateが動いている。

訂正台帳は、保存済みの結果がどう扱われるかを追う。プローブが5130になっても、過去の5120行は自動では変わらない。逆に、古い行を正しく除外できても、そのプローブが5120のままなら新しい結果は増え得る。

二つを分けることで、どちらか一方の緑表示を全体の解決と誤認しなくなる。raw行は上書きせず、派生viewにerratum ID、revision、処置、生成時刻を残すべきだ。元の出力を保存することは、誤値を正しいと扱うことではない。何が実際に出力されたかという証拠を守ることである。

5130の説明は率直で、結果のfwは実用的だ。訂正票がその間を結べば、人間向けの注意書きがdatasetの寿命に追いつく。

出典