Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Repeater: CLI reply to 'setperm <key> 0' is lost when the removed ACL entry sits before the requester (stale ClientInfo* after array shift)

オープン 初心者向け
  • 何か問題がありますか？
#3,513 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
77/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
c
領域
backend, embedded-iot

調査の方向性

examples/simple_repeater/MyMesh.cpp の onPeerDataRecv() 付近と src/helpers/ClientACL.cpp の applyPermissions() 付近を読みます。setperm 0 が ACL を圧縮する一方、応答ではまだ要求元のポインタが使用されるigueたを追跡します。応答のルーティングに使う要求元の情報を保持し、その後に、要求元より前、要求元より後、および要求元自体のエントリを削除しても、CLI 応答が引き続き管理者に送信されることを確認します。

索引モデルが issue の本文から書いたものです。

説明

Summary

On a repeater, setperm <prefix> 0 (revoke) often gets no CLI reply although the entry is removed. Cause: MyMesh::onPeerDataRecv() keeps a ClientInfo* into the ACL array across handleCommand(), and the revoke path compacts that array in place, so the reply is addressed/routed with another client's data.

Where

examples/simple_repeater/MyMesh.cpp (tag repeater-v1.17.1; main @ e94125987e is identical):

  • L670 — requester resolved by index before the command runs: ClientInfo* client = acl.getClientByIdx(i);
  • L739 — handleCommand(...) runs setperm → ClientACL::applyPermissions()
  • L751-L757 — the same client pointer is used afterwards: createDatagram(..., client->id, ...), client->out_path_len, client->out_path

src/helpers/ClientACL.cpp L123-L132 — guest/revoke branch shifts the fixed array down in place:

num_clients--;
int i = c - clients;
while (i < num_clients) {
  clients[i] = clients[i + 1];
  i++;
}

If the removed row's index is ≤ the requester's own index, client now points at the next client's data, so the OK goes to the wrong destination hash/path and the admin never sees it. If the removed row sits after the requester, nothing moves under the pointer and the reply arrives. Edge case: when the requester occupies the last populated slot, its old slot is not overwritten (stale copy of itself), so the reply still arrives.

Same code in v1.15.0, v1.16.0, v1.17.0 and v1.17.1 (only line numbers differ in MyMesh.cpp).

Reproduce (observed on a stock repeater, v1.17.0-727fc05)
  1. Log in as admin A. Make sure a client B sits before A in the ACL and another client C sits after A (e.g. add B, remove and re-add A with a password login, then add C with setperm <C> 1).
  2. setperm <B-prefix> 0 → no reply. Repeat the same command → Err - invalid params (B is already gone, so the first command did work).
  3. setperm <C-prefix> 0 → OK as expected.
  4. setperm <A-prefix> 0 (self-revoke) with another client after A → no reply either.
Expected

The CLI reply always goes to the admin who sent the command.

Suggested fix

Smallest change: before handleCommand(), copy what the reply needs (the requester's id, out_path, out_path_len) into locals and use those afterwards instead of client->.... Alternatives: look the requester up again by pubkey after the command, or defer the array compaction (mark permissions = 0 and compact later).

Clients can currently only treat a missing reply to setperm … 0 as "unconfirmed" and re-read the list with REQ_TYPE_GET_ACCESS_LIST.

主要言語
C
スター
3.9k
フォーク
1.5k
平均マージ
18時間 59分
マージ済み PR（30日）
28

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

meshcore-dev/MeshCore のほかの issue

meshcore-dev/MeshCore の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。