openwrt

OpenSSHの「長いパスワードで入れる」脆弱性、Alpineなどmusl環境のどこが影響を受けるか 11月5日の深夜、「Alpine Linux で257〜1024文字（告知の単位ではバイト）の何かを打てば root が取れる」という投稿が流れてきて、私も一瞬手が止まりました。 ただ、条件を読んでいくと、当てはまる環境はかなり絞られます。 一方で、当てはまる環境では、パスワードを知らなくても1回の接続で入られます。 Alpine は、コンテナ、クラウドの VM、小さな物理機器と、使われる場所が幅広いディストリビューションです。 また、影響は Alpine に限らず、同じ musl libc を使う OpenWrt などにも及びえます。 当初は自前の環境を確かめるために AI を使用し整理したのですが、少し加工すれば記事になりそうだったので、Alpine の使われ方と Alpine 以外の環境に分けて、どこに当てはまるのかを一次情報の範囲で確認したものを共有します。 ! 2026年11月6日時点で、Alpine Linux の告知とダウンロードページ、クラウドイメージのページ、OpenSSH 10.6p2 のリリースノート、oss-security への投稿、Docker Hub、sshd_config(5)、発見者のページ（sshhole.com）、Threat Landscape、Cycode、Check Point、Detectify の解説、NVD、musl のメーリングリスト、sshd(8)、各ディストリビューションの OpenSSH のパッケージ定義と配布フィードを確認した範囲の情報です。 CVE 番号は、Alpine の告知の時点では振られていませんでしたが、その後 CVE-2026-123158 が割り当てられ、NVD が11月5日（UTC）に公開しています（CVSS 3.1 の基本値は 8.1）。 「私の見立てでは」と書いた箇所は、出典のない私の推測です。 ＊マサカリは歓迎します^^;コメントで教えてください。 話題になった投稿 発端の投稿は、2026年11月5日 23:48（日本時間）の International Cyber Digest のものです。 x.com On Alpine Linux, type 257 to 1024 characters of anything and you get root. （Alpine Linux で、257〜1024文字の何かを打つと root が取れる。） 同じ日に Alpine Linux が出した告知を読むと、成り立つにはいくつもの条件が要り、「Alpine を使っていれば誰でも root を取られる」わけではありません。 何が起きるのか（概要） musl libc の crypt() は、256バイトを超えるパスワードを受け取ると、エラーの印として * という文字列を返します。 - は、パスワードを設定していないアカウントの /etc/shadow のパスワード欄に入りうる値と同じです。 PAM を通さない sshd は、パスワードを持たないアカウントでも、別のアカウントのハッシュの先頭（方式とソルト）を借りて crypt() を呼び、結果をパスワード欄と比べます。 そのため、crypt() の結果とパスワード欄が一致したと判断し、ログインを通します。 長さの範囲は、Alpine の告知では257〜1024バイト、NVD の説明では256〜1024文字と書かれています。 OpenSSH は 10.6p2 で sshd の側に回避策を入れ、Alpine は各リリースに修正済みのパッケージを出しています。 musl の側は、musl の不具合ではなく呼び出し側の誤った使い方だという立場です。 Alpine の告知は、影響を受ける条件を次の4つとしています。 PAM を通さない sshd：Alpine の openssh-server パッケージ（PAM なしでビルド）、または openssh-server-pam を UsePAM no で使っている パスワード認証が有効：PasswordAuthentication が yes（OpenSSH の既定値） パスワード欄が * のアカウント：鍵だけで使うアカウントなど、パスワードを設定していないアカウントがある（musl-nscd 経由のディレクトリサービスのユーザーも含む） パスワードを持つ別のアカウント：$5$ か $6$ のハッシュを持つアカウントが1つ以上ある 告知はさらに、攻撃者が SSH のポートに届くことと、パスワード欄が * のアカウントの名前を知っていることを前提にしています。 ! で「ロック」されたアカウントは対象外です。 Check Point は自社の検証で、sshd がソルトを借りる先のアカウントはハッシュを持つだけでは足りず、有効なアカウントである必要があったとしています。 確かめる側は、告知どおり $5$ か $6$ のハッシュがあれば当てはまるものとして扱うのが安全です。 狙われるのは、公開鍵認証方式だけで使っているアカウントです。 「このユーザーはkeyでしか入らないから安全」と考えていても、他ユーザ向けの sshd パスワード認証が有効なままなら、そのアカウントが入口になります。 以下の節では、Alpine の告知を正として、条件を次の3点にまとめて使われ方ごとに当てはめます。 PAM を通さない sshd が動いているか パスワード認証が有効か - のアカウントと、パスワードを持つアカウントが同居しているか（3つ目と4つ目の条件） Alpine が使われている場所 Alpine のダウンロードページでは、用途ごとに複数の版が配られています。 主なものは次のとおりです。 版 ダウンロードページの説明 主な使われ方 Mini root filesystem For use in containers and minimal chroots. コンテナのベースイメージ Standard Alpine as it was intended. Just enough to get you started. 物理サーバー、手で構築する機械 Extended Most common used packages included. Suitable for routers and servers. Runs from RAM. ルーター、自宅や社内の小さなサーバー Virtual Optimized for virtual systems. 手で構築する VM Raspberry Pi First generation Pis including Zero/W (armhf). Pi 2 to Pi 3+ generations (armv7). Pi 3 to Pi 5 generations (aarch64). シングルボードコンピューター Generic U-Boot Includes the U-Boot bootloader. U-Boot で起動する ARM の機器 Xen Use for Xen Dom0. Xen のホスト このほか、クラウド向けのイメージ（AWS、Azure、GCP、Oracle Cloud、NoCloud ほか）が別のページで配られています。 クラウドイメージの初期設定の仕組みは、Tiny Cloud と cloud-init の2種類です。 Docker Hub の公式の alpine イメージは、「only 5 MB in size」をうたう最小のイメージです。 Alpine の使われ方ごとの影響 使われ方ごとに条件を当てはめると、次のようになります。 使われ方 PAM なしの sshd パスワード認証 - とパスワードの同居 判断 公式の Docker イメージを使うコンテナ 入っていない 該当なし 該当なし 影響なし sshd を足したコンテナ（CI ランナー、開発用コンテナ、踏み台） 動いている イメージの作り方次第 イメージの作り方次第 条件がそろえば影響あり クラウドイメージ（cloud-init） 動いている 既定は no パスワード認証が no のため判断に関係しない 既定のままなら影響なし クラウドイメージ（Tiny Cloud、3.18.11〜3.24.3。11月6日時点で配られている公式イメージはすべてこの範囲） 動いている 有効 パスワードを1つ設定すると同居する 運用の途中で影響ありになる 手で構築した VM、物理サーバー、Raspberry Pi 入れていれば動いている 既定は有効 鍵だけのユーザーをどう作ったか次第 条件がそろえば影響あり 行ごとの補足と、Alpine を土台にしたイメージの扱いは次のとおりです。 公式の Docker イメージを使うコンテナ 公式の alpine イメージには sshd が入っていません。 アプリケーションを動かすためのベースイメージとして使っている限り、Alpine の告知の「Docker and other container users that do not run sshd in the container（コンテナ内で sshd を動かさない Docker などの利用者）」に当たり、影響を受けません。 sshd を足したコンテナ CI ランナー、開発用のコンテナ、踏み台のように、Alpine のイメージに openssh-server を足して SSH で入れるようにしたコンテナは、条件がそろう可能性があります。 こうしたイメージは製作者ごとに作り方が違います。 影響があるかどうかは、パスワード認証を残しているかと、鍵だけのユーザーとパスワードを持つユーザーが同居しているかで決まります。 Threat Landscape は、Alpine などを土台にしたコンテナイメージや CI ランナーに、パスワード欄が * の root やサービス用のアカウントが残っていて、sshd ではパスワード認証が有効なままの構成が多いとしています（組み込み機器やエッジの機器も挙げています）。 一方で、Cycode は、SSH サーバーを動かす公開のイメージを調べ、Gitea、Gogs、Jenkins の SSH エージェント、linuxserver の openssh-server（PASSWORD_ACCESS=true にしない限り）などの広く使われるイメージは、パスワードでのログインを止めているとしています。 どの程度の割合が当てはまるかを示す数字は、私が確認した範囲にはありません。 自分で作ったイメージや、外から取ってきた SSH 付きのイメージは、1つずつ確かめる必要があります。 クラウドイメージ Alpine のクラウドイメージは、ログインするユーザーが alpine に決まっていて、クラウドに登録した SSH の公開鍵がこのユーザーに入ります。 初期設定の仕組みによって、影響が分かれます。 cloud-init のイメージは、Alpine の告知によれば、cloud-init が PasswordAuthentication no を書き込むため影響を受けません。 私の見立てでは、user-data や後からの変更でパスワード認証を有効に戻していれば、この限りではありません。 Tiny Cloud のイメージを使う場合は、私の見立てでは、出典で確かめられる中で最も条件がそろいやすくなります。 Alpine の告知によれば、3.18.11 から 3.24.3 までの Tiny Cloud のイメージ（qcow2、VHD、AMI の形式）は、パスワード欄が * で、パスワードなしの doas を許可した alpine ユーザーが入った状態で配布されています。 初回起動の時点では安全です。 管理者がコンソール用のパスワードを設定したり、user-data でパスワード付きのユーザーを足したりして、パスワードを持つアカウントが1つでもできた時点で条件がそろいます。 攻撃者は、名前の決まった alpine ユーザーとして入り、doas で root になれます。 パスワードを設定した人は、別のアカウントに穴を開けたとは普通思いません... 公式の告知では、3.21.10、3.22.8、3.23.8、3.24.4 以降から作ったイメージには修正済みのパッケージが入るとしています。 ただし、11月6日時点でクラウドイメージのページに載っている版は 3.24.3、3.23.7、3.22.7、3.21.9 の4つで、修正済みの版から作った公式イメージはまだ配られていません。 起動済みのインスタンスに加えて、これから起動するインスタンスも、起動した直後に、apk upgrade -U -a と sshd の再起動か、パスワード認証の停止が要ります。 どちらのイメージかは、インスタンスの中で apk info -e tiny-cloud cloud-init を実行すると分かります。 tiny-cloud と出れば Tiny Cloud のイメージです。 分からないときは、Tiny Cloud のイメージとして扱って検証してください。 自前で構築した VM、物理サーバー、Raspberry Pi Standard や Extended、Virtual、Raspberry Pi の版から手で構築した機械は、影響を受けるかどうかが管理者の作り方で決まります。 Alpine の告知は、パスワードなしで adduser したユーザーや、usermod -p '*' でパスワード欄を * にした鍵だけのユーザーを、対象のアカウントに挙げています。 ただし、Alpine の adduser を担う busybox のソースを読むと、adduser -D はパスワード欄に * ではなく !（ロック）を書きます。 告知によれば ! のアカウントは鍵でも入れないため、鍵で使えている鍵だけのユーザーは、作った後に欄が書き換えられています。 - に書き換えたユーザーと、パスワードを設定したユーザーが同じ機械にいて、パスワード認証が有効なら当てはまります。 自分の機械のアカウントが * かどうかは、「まず確かめること」の節の awk で確かめてください。 導入の途中で root にパスワードを設定した機械では、root がパスワードを持つアカウントになります。 私の見立てでは、この機械にパスワード欄が * の鍵だけのユーザーを1人足すと、それだけで条件がそろいます。 root そのものの扱いは、どこから作った環境かで分かれます。 Alpine の告知によれば、3.16 ごろから基本のイメージで root のパスワード欄が * になっています。 rootfs を作るスクリプト（genrootfs.sh）が root の欄を * に書き換えているため、少なくともコンテナ向けの最小の rootfs はこれに当たります。 この場合も、OpenSSH の PermitRootLogin の既定値は prohibit-password なので、PermitRootLogin yes を設定していない限り、root にパスワードでは入られません。 ISO から手で入れた機械では、root のパスワード欄は空で作られ、導入の途中でパスワードを設定していればハッシュになります。 ISO から入れた機械では、どちらの場合も root は * ではないので、root そのものは入口になりません。 root に直接入られなくても、doas や sudo で root になれるユーザーに入られれば同じことになります。 逆に、入られたユーザーに doas や sudo の権限が無ければ、攻撃者ができることは、そのユーザーの権限の範囲にとどまります。 Extended の版は、ダウンロードページで「ルーターとサーバー向け」とされています。 私の見立てでは、社内や自宅のネットワークに置いた小さなルーターや機器は、確かめる対象から漏れやすい機器です。 Alpine を土台にしたコンテナイメージ Alpine を土台にして作られたイメージ（言語やミドルウェアのイメージの alpine の版など）は、中身が Alpine なので、ここまでの行と同じ扱いです。 sshd を足していなければ影響を受けず、足していれば「sshd を足したコンテナ」の行に当たります。 Alpine 以外の環境 条件の土台は「musl libc」と「PAM を通さない OpenSSH」の組み合わせで、Alpine に固有のものではありません。 発見者のページは、musl を使う例として Alpine のほかに OpenWrt、Buildroot、Yocto を挙げています。 一方で、glibc のディストリビューション（Debian、Ubuntu、Fedora など）、PAM を通す構成、Dropbear、OpenBSD は影響を受けないとしています。 musl を使うディストリビューションでも、OpenSSH を PAM 付きで出していれば、既定のままなら当てはまりません。 各ディストリビューションの OpenSSH のパッケージ定義を確かめた結果は次のとおりです。 環境 OpenSSH のパッケージ 判断 OpenWrt openssh-server は PAM なしで、パスワード認証は既定の yes のまま。openssh-server-pam は UsePAM yes と PasswordAuthentication no を設定する 既定の Dropbear のままなら影響なし。openssh-server に入れ替え、24.10 以降で root にパスワードを設定していれば条件がそろう（表の後の OpenWrt の段落） Buildroot、Yocto で作った機器 musl を使うか、PAM を使うかがビルドの構成で決まる 構成を確かめるまで分からない Void Linux（musl の版） PAM 付きでビルドし、既定の sshd_config を UsePAM yes にしている 既定のままなら影響なし。UsePAM no に変えていれば当てはまりうる。パッケージ定義は 10.6p2 に更新済み Gentoo（musl のプロファイル） pam の USE フラグ（Linux のプロファイルの既定で有効）が有効なら、UsePAM yes と PasswordAuthentication no を設定する 既定のままなら影響なし。pam を外してビルドしていれば当てはまりうる。10.6p2 の ebuild あり Chimera Linux PAM 付きでビルドし、UsePAM の既定値を yes に変えている 既定のままなら影響なし。パッケージ定義は 10.6p2 に更新済み postmarketOS Alpine のパッケージを使う Alpine と同じ手順で確かめる Debian、Ubuntu、Fedora などの glibc の系統 該当なし 影響なし 表の OpenWrt、Void Linux、Gentoo、Chimera Linux の行は、出典の記事ではなく、私が各ディストリビューションのパッケージ定義を読んで確かめた内容です。 postmarketOS の行と、OpenWrt の既定の SSH サーバーが Dropbear であることは、私の補足で、パッケージ定義では確かめていません。 OpenWrt は、OpenSSH に入れ替えた機器で条件がそろいやすい構成です。 OpenWrt のリリース版（23.05〜25.12）の出荷時の /etc/shadow には、パスワード欄が * の daemon、ftp、network、nobody のアカウントがあります。 また、24.10 以降の busybox はパスワードを SHA-256（$5$）で保存する設定のため、利用者が root にパスワードを設定すると、パスワードを持つアカウントの条件も満たします。 23.05 の busybox は MD5（$1$）で保存する設定で、MD5 のハッシュは告知の条件（$5$ か $6$）に当たりません。 ただし、23.05 から 24.10 以降に設定を引き継いで更新した機器では、パスワードを変えた時点で $5$ になります。 機器の上で、次のコマンドでハッシュの先頭を確かめてください。 パスワードを持つアカウントと、ハッシュの先頭3文字（$1$ は MD5、$5$ は SHA-256、$6$ は SHA-512） awk -F: '$2 ~ /^\$/ { print $1, substr($2, 1, 3) }' /etc/shadow 告知の4つ目の条件に照らすと、$5$ か $6$ が出れば当たり、$1$ だけなら当たりません。 4つのアカウントのシェルは /bin/false なので、入られてもシェルは取られません。 ただし、OpenWrt の openssh-server は sshd_config のポート転送の設定を書き換えておらず、OpenSSH の既定の許可のままです。 私の見立てでは、ログインが通ること自体が、SSH のポート転送でルーターの内側のサービスに届く足がかりになりえます。 OpenWrt の修正は、11月6日時点のパッケージ定義で確かめると、master と 25.12 のブランチが OpenSSH 10.6p2 に上がっています。 24.10 と 23.05 のブランチは、版の番号を 9.9p2 と 9.8p1 に据え置いています。 2026年11月5日（UTC）に 10.6p2 の修正を移植したパッチが入り、リリース番号が 1 から 2 に上がりました。 機器で表示される修正済みの版は、25.12 が 10.6_p2-r1、24.10 が 9.9_p2-r2、23.05 が 9.8p1-2 以降です。 版は opkg list-installed | grep openssh-server（25.12 は apk list -I 'openssh-server*'）で確かめられます。 ただし、11月6日時点のリリース用の配布フィード（x86_64 で確認）には、修正済みの版がまだ入っていません。 23.05 は 9.8p1-1、24.10 は 9.9_p2-r1、25.12 は 10.6_p1-r2 のままです。 openssh-server（PAM なし）を使っている OpenWrt の機器は、いまのところ更新では塞げないため、PasswordAuthentication no を設定し、/etc/init.d/sshd restart で再起動して塞いでください。 root にパスワードでログインしている機器では、設定の前に鍵で入れることを確かめてください（「塞ぎ方」の節の締め出しの項）。 入られたかどうかは、OpenWrt では logread | grep 'Accepted password for' で確かめます。 私の見立てでは、OpenWrt の既定のログは機器のメモリに置かれ、再起動で消えるため、記録が無いことは入られていない根拠になりません。 私の見立てでは、Alpine 以外でいちばん気にすべきなのは、OpenWrt や Buildroot、Yocto で作られたルーターや組み込み機器です。 こうした機器は、作った会社や人しか構成を知らず、利用者が中で何が動いているかを確かめにくいためです。 PasswordAuthentication no を設定できる機器なら、提供元の更新を待たずに塞げます。 自分で構成を確かめられない機器は、提供元にこの脆弱性への対応状況を問い合わせてください。 優先して棚卸しする環境 ここまでをまとめると、私の見立てでは、先に確かめる価値が高いのは次の4つです。 外から SSH で入れる Alpine の機械：攻撃者がポートに届く。名前の決まったユーザー（クラウドイメージの alpine など）や鍵だけのデプロイ用ユーザーが入口になる Tiny Cloud の Alpine のインスタンス：運用の途中でパスワードを1つ設定しただけで条件がそろい、doas で root まで届く musl の小さな機器（OpenWrt のルーター、Buildroot や Yocto の組み込み機器）：利用者が構成を確かめにくい 自分で Alpine を入れた小さな機械（Raspberry Pi、自宅や社内のルーター）：作った本人も存在を忘れやすく、棚卸しから漏れやすい 逆に、公式の Docker イメージをアプリケーションの土台に使っているだけのコンテナ、cloud-init のイメージを既定のまま使っている VM、glibc のディストリビューションのサーバーは、優先度を下げてかまいません。 まず確かめること Alpine の機械で該当するかどうかを確かめる手順は、公開されている条件の順番と同じです。 次のコマンドで確認してください。 どのコマンドも設定と状態を読むだけです（-T の実行と /etc/shadow の読み取りには root の権限が要ります）。 sshd が動いているか、どのバイナリか openssh-server-pam は /usr/sbin/sshd.pam、openssh-server-krb5 は /usr/sbin/sshd.krb5（どちらも PAM 付き。判断は UsePAM の値による） ps -o pid,args | grep '[s]shd' 入っている sshd のパッケージと版 apk list -I 'openssh-server*' PAM、パスワード認証、root のログインの設定 上で出たバイナリのパスで実行する。-f が付いていれば同じ -f を付ける /usr/sbin/sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) ' パスワード欄が * のアカウントの有無を確認 awk -F: '$2 == "*" { print $1 }' /etc/shadow パスワードを持つアカウントと、ハッシュの種類を特定（先頭3文字が $5$ か $6$ なら4つ目の条件に当たる） awk -F: '$2 ~ /^\$/ { print $1, substr($2, 1, 3) }' /etc/shadow 次の3つがすべて当てはまれば、影響があるものとして扱ってください。 PAM を通さない：-T の結果に usepam の行が出ない（PAM なしのビルド）か、usepam no が出る パスワード認証が有効：passwordauthentication yes が出る アカウントの同居：* のアカウントと、パスワードを持つアカウントがどちらも1つ以上ある 入っている版が修正済みでも、更新の後に sshd を再起動していなければ、動いている sshd は古いままです。 修正済みの版は「塞ぎ方」の節に並べています。 -T が読むのは設定ファイルで、動いている sshd の状態ではない点にも注意が要ります。 -T が何も出さないときは、実行自体が失敗しています。 awk で root が * と出ても、root にパスワードで入れるのは -T の結果が permitrootlogin yes のときだけです（root の扱いは「自前で構築した VM、物理サーバー、Raspberry Pi」の節）。 sshd_config に Match ブロックがある環境や、ディレクトリサービスのユーザーがいる環境では、上のコマンドだけで判断しないでください。 塞ぎ方 Alpine の告知が示す塞ぎ方は2つで、どちらか一方で穴は塞がります。 パッケージを更新して sshd を再起動する：apk upgrade -U -a の後に rc-service sshd restart。パッケージを更新しただけでは、動いている sshd は入れ替わらない パスワード認証を止める：PasswordAuthentication no を設定し、sshd を再起動する 修正済みのパッケージは、edge が 10.6_p2-r0、3.24 が 10.3_p1-r2、3.23 が 10.2_p1-r1、3.22 が 10.0_p1-r11、3.21 が 9.9_p2-r1 です。 3.21 は2026年11月1日にサポートが切れましたが、Alpine は 3.16 までの各リリースにも修正済みのパッケージを出しています（版の番号は告知の表にあります）。 3.16 より前のリリースには、修正済みのパッケージがありません。 Cycode は、3.16 より前の Alpine のイメージは同社のラボで悪用できたとしており、こうしたイメージで塞ぐ手段はパスワード認証を止めることだけです。 sshd を足したコンテナは、更新したパッケージでイメージを再構築し、コンテナを作り直してください。 パスワード認証を止めるときは、次の点に注意が要ります。 書き足す位置：sshd の設定は、同じ項目なら最初に読まれた値が使われる。既存の PasswordAuthentication yes の後ろに no を書き足しても効かない。告知に、Match ブロックの中まで書き換える手順が載っている 締め出し：パスワードでしかログインしていないアカウントは入れなくなる。作業前に自分のアカウントが鍵で入れることを確かめ、新しいログインを試し終えるまで作業中の接続を切らない コンソールのパスワード：シリアルコンソールに入るためにパスワードを設定すると、Tiny Cloud のイメージでは条件がそろう。コンソール用のパスワードは、更新かパスワード認証の停止が効いたことを確かめた後に設定する 確かめ方：変えた後に、動いている sshd のバイナリで（-f が付いていれば同じ -f を付けて）-T | grep -i passwordauthentication を実行し、passwordauthentication no が出ることを確かめる。-T は Match ブロックの中を評価しないので、Match がある環境は sshd -T -C user=<ユーザー名>,host=<ホスト名>,addr=<接続元のアドレス> で条件ごとに確かめる 入られたかどうか 発見者のページは「as far as anyone knows, nobody noticed（知られている限り、誰も気づかなかった）」と書いています。 同じページによれば、問題は2016年から存在していました。 11月5日 15:30（CET）時点で、Detectify は悪用の公開報告を把握していないとしています。 NVD に載った CISA の評価（SSVC）では、悪用の状況は「poc」（概念実証がある段階）です。 残念ながら、誰も気づいていないからといって、誰も使っていないとは言えません。 Alpine の告知は、/var/log/messages で、パスワードを持たないアカウント（alpine、root、鍵だけのユーザー）に対する Accepted password for の行を探すよう案内しています。 ここでの root は、パスワード欄が * の場合に限ります。 「まず確かめること」の節の awk でパスワード欄が * と出たアカウントが、探す対象です。 私の見立てでは、コンテナの場合、sshd を -e 付きで動かしていれば docker logs などコンテナの出力に記録が出ます。 syslog も -e も無い構成では記録が残らないため、ログからは入られていないとは言えません。 告知はあわせて、外部に公開しているサーバーでは doas の利用、最近作られたユーザーとファイル、authorized_keys を見直すよう求めています。 ログインがあったことを否定できなければ、侵害されたものとして扱うことも求めています。 出典 Security advisory: openssh-server password authentication bypass（Alpine Linux、2026-11-05） Downloads（Alpine Linux） Cloud Images（Alpine Linux） alpine（Docker Hub の公式イメージ） OpenSSH Release Notes（OpenSSH 10.6p2、2026-11-05） "sshole": password authentication bypass: OpenSSH + musl libc（oss-security、2026-11-05） sshhole（発見者 Özgün Kültekin 氏のページ） sshhole: OpenSSH musl Password Bypass on Alpine and OpenWrt（Threat Landscape、2026-11-05） CVE-2026-123158（NVD） Advisory for OpenSSH+musl users（musl のメーリングリスト、2026-11-05） sshole (CVE-2026-123158): OpenSSH Auth Bypass on Alpine（Cycode） A Critical SSH Password Bypass Hits musl-Based Linux（Check Point） Critical vulnerability: OpenSSH authentication bypass on Alpine Linux（Detectify） sshd_config(5)（OpenBSD manual pages） sshd(8)（OpenBSD manual pages、-T と -C） OpenWrt packages の net/openssh/Makefile（master、openwrt-25.12、openwrt-24.10、openwrt-23.05 の各ブランチ） OpenWrt packages の openwrt-24.10 の net/openssh/patches（0001-avoid-password-authn-bypass.patch） OpenWrt packages の openwrt-23.05 の net/openssh/patches（0001-avoid-password-authn-bypass.patch） void-packages の srcpkgs/openssh（template と patches/sshd_config.patch） Gentoo の net-misc/openssh の ebuild Gentoo の profiles/default/linux/make.defaults Chimera Linux cports の main/openssh OpenWrt の package/base-files/files/etc/shadow（23.05、24.10、25.12 の各ブランチ） OpenWrt の include/package-defaults.mk（版の表記） OpenWrt のリリース用の配布フィード（packages-23.05、packages-24.10、packages-25.12 の x86_64） OpenWrt 24.10 の package/utils/busybox/Config-defaults.in OpenWrt 25.12 の package/utils/busybox/Config-defaults.in OpenWrt 23.05 の package/utils/busybox/Config-defaults.in OpenWrt 25.12 の config/Config-build.in（USE_APK の既定値） OpenWrt packages の openwrt-24.10 のコミット 4d71f28247（backport security mitigation from 10.6p2） OpenWrt packages の openwrt-23.05 のコミット f36055baca（backport security mitigation from 10.6p2） busybox の loginutils/adduser.c（adduser -D が書くパスワード欄） Alpine aports の scripts/genrootfs.sh と main/alpine-baselayout Alpine のパッケージ一覧（tiny-cloud） International Cyber Digest の投稿（2026-11-05）

openwrt#26473 IX2106をOpenWRTに対応させるの面白い取り組みだな。1つ前のIX2105は一時期使っていたが、公式サポートが終了しているので非常に安く出回っており有線ルーターとして復活できるなら復活できそう。スペックも半分だけど

Building an OpenWrt product? Don't overlook board-level support. The Wallys DR5018S, based on Qualcomm IPQ5018, is now supported upstream in OpenWrt. GitHub: github.com/openwrt/openwrt/commit/0dd6f3b28353f71… #OpenWrt #EmbeddedLinux

4ヶ月前に作成した openwrt/odhcpd へのプルリクがようやく取り込まれた。odhcpd が暴走して特定コアのCPU使用率が100%になってしまう問題に遭遇していたらこれで解消されるはず（masterブランチに取り込まれただけなのでパッケージに反映されるのはもう少し先だけど）。 odhcpd#403

Хотел просто скачать ISO, в итоге написал эксплойт для ядра Моя точка доступа TP-Link EAP770 v1 портачит загрузки по Wi-Fi, а производитель прекратил обслуживание этой модели ещё до того, как я вообще достал её из коробки. Решение проблемы — прописать два нуля в sysfs. Вот только командная оболочка TP-Link не даёт этого сделать, и мне пришлось писать эксплойт для своего же @#$%&! устройства. Постоянный обрыв длительных загрузок В августе 2023 года я прикупил новёхонькую точку доступа стандарта Wi-Fi 7 — TP-Link EAP770. Подключение через неё слегка глючило, видео периодически подтупливало, но меня это не особо беспокоило. Тогда я основное время работал за машиной, подключенной по Ethernet. Если же мне нужно было куда-то отлучиться, то я по Wi-Fi синхронизировал свой домашний каталог (~) с ноутбуком через rsync и брал ноут с собой. Вот как раз при этой передаче и начали возникать косяки с файлами больше нескольких ГБ. SSH ругался на ошибки целостности (MAC), поэтому я какое-то время искал проблемы в rsync и SSH. В остальном всё работало, а смена параметров rsync ситуацию то улучшала, то ухудшала. Wireshark показывал ноль битых контрольных сумм и ноль повторных передач, а одиночный UDP-поток из случайных байтов доходил абсолютно чистым. Я верил, что TCP непременно доставит правильные байты — ведь он, чёрт возьми, для этого и создавался. Собственно, потому я был уверен, что косяк где-то в rsync или SSH. В итоге я написал для rsync обёртку, чтобы автоматически повторять передачи, и забил. Позже я наладил трафик внутри домашней сети через Tailscale, и повторные попытки стали не нужны. WireGuard просто дропает пакет, если его аутентификация проваливается — TCP внутри туннеля видит потерю пакета и повторяет отправку. Поскольку передача заработала исправно, я снова успокоился. Отсутствие обновлений прошивки Как я уже писал, у меня точка доступа EAP770(EU) v1.0. Это модель на базе процессора Qualcomm IPQ9574 под управлением Linux 5.4.164 и с прошивкой 1.0.0 Build 20230605 Rel. 71641. С этой прошивкой устройство шло с завода, и, похоже, с того момента в TP-Link о нём напрочь забыли :) Я эту штуку купил в августе 2023 года, а стандарт Wi-Fi 7 окончательно утвердили только в сентябре 2024-го. У неё нет сертификации Wi-Fi Alliance, и её покупка была явно глупым решением. НИКОГДА НЕ ПОКУПАЙТЕ ТЕХНИКУ, ПОКА СТАНДАРТЫ НЕ БУДУТ УТВЕРЖДЕНЫ, А САМИ УСТРОЙСТВА НЕ ПРОЙДУТ СЕРТИФИКАЦИЮ. В 2025 году я заметил, что пока все устройства спокойно себе обновляются, это чудо продолжает сидеть на своей старой прошивке. В июне того же года я обратился в поддержку, так как на сайте смог найти только v2. Как ни странно, в базе данных у них первой версии тоже не оказалось, и они попросили меня выслать фото самого устройства и его упаковки. Ну а потом прислали вот что: Поддержка модели EAP770 Version 1 завершена. Это устройство ещё может быть в наличии у некоторых ритейлеров, но обновлений прошивки для него больше не выпускается. КЛАСС. Поиск причины повреждения данных В 2026 году я решил перейти на NixOS и обнаружил, что при скачивании файла на 128 МБ из бинарного кэша Nix через Fastly по протоколу HTTP/2 постоянно возникала ошибка. При этом тот же файл спокойно скачивался по протоколу HTTP/1.1. Мне до сих пор невдомёк, чем помогал HTTP/1.1. Могу лишь предположить, что по HTTP/2 данные просто передавались быстрее. Команда git clone тоже выдавала ошибку, а HTTPS-соединения разрывались с сообщением bad record mac. Плюс в марте попытка скачать ISO-образ NixOS через wget завершилась ошибкой TLS: 2026-03-05 12:37:18 (31.6 MB/s) - Read error at byte 2722477636/3683778560 (error:0A000119:SSL routines::decryption failed or bad record mac; error:0A000139:SSL routines::record layer failure). Retrying.sourcecraft.dev Я вручную переключился на HTTP/1.1 и снова забил. В сентябре я превратил свою рабочую станцию в сборочную ферму, а сам пересел за ноутбук, который подключается к сети по Wi-Fi. При этом каждый день где-то в районе 11:00 Wi-Fi стабильно отваливался — аккурат перед дежурным созвоном. Пронаблюдав эту ситуацию несколько дней подряд, я решил снова вскрыть этот ящик Пандоры и засел за поиск причины, позвав на помощь Opus 5.5. Спойлер: причиной отвалов оказался другой баг. Я обвешал BPF-зондами Qualcomm-драйвер на ноутбуке и запустил утилиту apstats на точке доступа с правами root. Баг таился в закрытой прошивке самой Wi-Fi карты ноутбука; подробности читайте в апдейте в самом низу. Я пробовал включать и отключать Wi-Fi 7, отключал GRO на клиенте и даже заменил Wi-Fi адаптер MediaTek в моём Framework 16 на модель от Qualcomm. Новый адаптер и отключение GRO вроде как слегка улучшили ситуацию, но в корне проблему не решили. С помощью tcpdump я перехватил провалившуюся операцию скачивания и нашёл TCP-сегмент из 1440 байт, в котором было повреждено 64 байта подряд, но контрольная сумма при этом оставалась верной. Показатель TcpInCsumErrors держался на нуле. Протокол TCP принял этот сегмент как правильный и передал его на уровень TLS, который отклонил запись с ошибкой bad record mac. Повреждённая запись не расшифровывалась, поэтому сравнить испорченные байты с ожидаемой полезной нагрузкой я не мог. Тогда я решил потестить передачу сырых данных по TCP между ПК с проводным подключением и ноутбуком с Wi-Fi. Выяснилось, что порча происходила только при одновременной работе нескольких TCP-потоков и только в направлении LAN -> Wi-Fi. Тест выявил три повреждённых блока по 64 байта в 8192 МиБ переданных данных, и каждый из этих блоков начинался с нулей. Правильная контрольная сумма в повреждённом сегменте означала, что после повреждения её кто-то вычислил повторно. Значит, теперь нужно было понять, что именно на этом маршруте перезаписывает заголовки TCP. После замены платы MediaTek на Qualcomm проблема осталась, то есть дело не в ноутбуке. На проводных клиентах всё было чисто, а код целостности CCMP MIC на «битых» пакетах оставался корректным — значит, дело было не в кабеле и не в помехах радиоэфира. Оставался только мост между Ethernet и Wi-Fi внутри самой точки доступа. 64 байта — это как раз размер строки кэша в ядрах процессора IPQ9574, что явно указывало на баг кэша или DMA, а не на перевёрнутый бит. Единственный же компонент на этом пути, который одновременно и ускоряет трафик моста, и пересчитывает контрольные суммы — это подсистема аппаратной разгрузки Qualcomm SFE/PPE offload. Две команды записи, требующие root Изучив исходники драйвера, я предположил, что SFE/PPE можно отключить с помощью двух следующих настроек: echo 0 > /sys/sfe/l2_feature echo 0 > /sys/sfe/ppe_rfs_featuresourcecraft.dev В оба этих файла sysfs разрешена запись только из-под root, но SSH-оболочка в TP-Link запускается как uid 1 вообще без системных прав. В GUI для этого тоже настройки нет. Официального образа прошивки для первой версии, который можно было бы пропатчить и накатить, в свободном доступе тоже не существовало, а прошивка от v2 предназначена для совсем другого железа. Я попытался залить EAP773(EU)_V1_1.0.14 от родственной модели EAP773, но устройство её отклонило. А более новые релизы прошивок для v2 вообще зашифрованы. Если рассматривать прямую прошивку чипа, то потребуется специальная прищепка (flash clip) для программатора. Но мне не хотелось заморачиваться её поиском, как и превратить эту чёртову точку доступа в кирпич. Тратить лишние 200 баксов на замену девайса только потому, что в TP-Link не стали заморачиваться его поддержкой после продажи, я тоже не собирался. Устройство работает у меня дома, я точно знаю, какую настройку нужно подкрутить, но софт этого не позволяет. Но стоит отдать должное TP-Link: систему они укрепили хорошо. Я не нашёл ни одного вектора уязвимости в их бинарниках: они повсюду используют белые списки и загружают для ядра только необходимые модули. Так что халявы в духе ; echo 0 > /sys/sfe/ppe_rfs_feature мне не светило. Единственным путём внутрь оставалось само ядро. Призвав на помощь Opus 4.8, я связал в цепочку уязвимость CVE-2022-0185 и манипуляцию с буфером пайпа. CVE-2022-0185 заключается в целочисленном переполнении вниз в функции legacy_parse_param(), доступной из непривилегированного пространства имён пользователей. Эта уязвимость позволяет при записи переполнить 4-килобайтный slab-объект. А манипуляции с буфером пайпа, в свою очередь, превращают это переполнение в возможность произвольной записи в память. В открытом доступе уже были подробные разборы и примеры эксплуатации (PoC) этих уязвимостей. При этом эксплойт должен был оставить точку доступа в рабочем режиме, так как после перезагрузки сломанный offload включается обратно. Переполнение оставляет 4-килобайтный slab в таком состоянии, когда вторая попытка уводит ядро в панику, так что на одну загрузку роутера попытка тоже одна. Я дал Opus описание базовых примитивов и поручил дорабатывать эксплойт до тех пор, пока он не заработает стабильно. Описание эксплойтаПоскольку исходников GPL для версии v1 производитель не выложил, я взял ближайший опубликованный код от модели EAP783. Конфигурация её ядра отличалась от конфигурации в /proc/config.gz моей точки доступа чисто косметически тремя строками. В итоге я собрал с этим конфигом тестовый стенд в QEMU, наладил работу цепочки уязвимостей сначала на нём и только потом перешёл к реальному устройству. В ядре отсутствует механизм KASLR, поэтому адреса в памяти между перезагрузками не меняются. Но вот таблицу символов kallsyms производитель обнулил, так что мне всё равно пришлось вычислять адреса во время работы системы. В сборке для QEMU ядро загружалось по физическому адресу 0x40080000, но на самом устройстве оно разворачивалось по адресу 0x42080000, из-за чего все расчёты смещались на 0x2000000. Правильный базовый адрес я в итоге нашёл в переменной конфигурации сборки в исходниках EAP783. И даже после его исправления выяснилось, что секции ядра .text, .rodata и .data на устройстве сместились каждая на свою величину относительно сборки QEMU. Так что нельзя было просто прибавить одно общее смещение ко всем адресам. Механизм работы: Через unshare изолировать процесс в отдельное пространство имён, чтобы получить доступ к функции fsopen и вызвать переполнение вниз. Дефрагментировать 4-килобайтный slab с помощью пары сотен аллокаций одного размера, после чего выстроить созданные объекты в памяти так, чтобы источник переполнения, целевой ключ, сообщение SysV и кольцевые буферы пайпа оказались вплотную друг к другу. Вызвать переполнение, выходящее в область метаданных ключа, и увеличить значение поля его длины. Теперь чтение этого ключа будет приводить к утечке данных соседних объектов, включая поле buf[0].ops пайпа, где содержится адрес anon_pipe_buf_ops. Перенаправить буфер одного пайпа на страницу кольцевого буфера другого, а затем подделать в этом втором кольце запись, используя утёкший ранее указатель ops. Функция pipe_buf_can_merge() проверяет совпадение этих указателей, поэтому операция совмещённой записи через поддельную запись позволяет добраться до любой физической страницы, включая область образа ядра. Просканировать секцию .data в поиске modprobe_path. Обычно при чтении страниц образа ядра через пайп в момент очистки буфера для зарезервированной страницы вызывается put_page(), что приводит к ошибке Bad page map и панике ядра. Однако функция pipe_read вызывает только методы ->confirm и ->release, не проверяя подлинность таблицы ops. Поддельная pipe_buf_operations, где оба метода указывают на generic_pipe_buf_confirm (которая просто возвращает ноль и больше ничего не делает), даёт возможность сканировать и читать страницы без их освобождения. Это позволит эксплойту кусками сканировать секцию .data, пока не найдётся нужная строка. Перезаписать modprobe_path и запустить через execve файл с «магическими байтами», которые не соответствуют ни одному бинарному формату. Ядро вызовет request_module(), которая запустит программу по подменному пути с глобальными правами uid 0. Оставить дочерний процесс активным, чтобы он удерживал поддельный пайп. Если позволить ему завершиться, пайп будет уничтожен, и из-за попытки освобождения зарезервированной страницы возникнет паника ядра. Чтобы довести эту схему до рабочего состояния, потребовалось около семнадцати часов игры в «рулетку» с Opus 4.8 за токены. За это время я успел изучить бинарники устройства в radare2, проверить включённые механизмы защиты и разобраться со всеми вылетами системы. В итоге точка доступа осталась в рабочем состоянии, а отключение аппаратной разгрузки привело к прекращению порчи данных. Баг когерентности DMA-кэша Драйвер qca-nss-dp от Qualcomm повторно использует пакетные буферы, забывая синхронизировать процессорный кэш для всего буфера приёма перед его возвращением в распоряжение сетевой карты (NIC). На этом железе контроллер DMA пишет напрямую в DRAM, минуя синхронизацию кэшей процессора. Из-за этого «грязная» строка кэша, оставшаяся в буфере от предыдущего использования, может быть сброшена в память уже после того, как сетевая карта приняла новый пакет, затерев часть этого пакета. Затем подсистема SFE/PPE пересчитывает контрольные суммы для уже повреждённых данных, и клиент получает свежую контрольную сумму TCP, валидную для этого мусора. Протокол TCP принимает пакет, а вот механизмы проверки подлинности сообщений (MAC) в TLS и SSH обнаруживают искажение, выдавая ошибки bad record mac и corrupted MAC. На архитектуре x86 оборудование само следит за согласованностью DMA с кэшами процессора, поэтому там такое упущение никак бы не навредило. Изучая исходники ядра, я обнаружил похожие проблемы с обслуживанием кэша при DMA и в других драйверах. Только пока не знаю, как протестировать их на реальном железе и кому о них сообщить. Описание драйвера Это внешний код NSS от Qualcomm, доступный в репозитории openwrt/qca-nss-dp. При работе по быстрому пути передачи движок SFE сбрасывает кэш для данных skb->data в объёме skb_headlen(skb) байт, что в точности составляет линейную часть исходящего пакета. edma_tx.c#L483-L490: buff_addr = (dma_addr_t)virt_to_phys(skb->data);                 EDMA_TXDESC_BUFFER_ADDR_SET(txd, buff_addr); #ifdef EDMA_40BIT_SUPPORT                 EDMA_TXDESC_BUFFER_ADDR_HI_SET(txd, buff_addr); #endif                 dmac_clean_range_no_dsb((void )skb->data, (void )(skb->data + buf_len));sourcecraft.dev Затем он выставляет флаг skb->fast_recycled = 1, а буфер возвращает в закреплённый за процессором список повторного использования без очистки содержимого. edma_tx.c#L735-L743:    /*     * Если пакет пошёл по быстрому пути SFE, устанавливается     * флаг fast_recycled, чтобы любой драйвер Rx DMA, который     * позднее будет выделять буфер под этот пакет, мог избежать     * аннулирования кэша.     */     if (likely(skb->fast_xmit) && likely(skb->is_from_recycler)) {         skb->fast_recycled = 1;     }sourcecraft.dev Механизм повторного использования обнуляет структуру sk_buff вплоть до поля tail, восстанавливает флаг fast_recycled и сбрасывает указатель skb_data на значение skb->head + NET_SKB_PAD. Когда этот буфер переиспользуется для приёма, код пути наполнения видит установленный флаг и пропускает операцию аннулирования кэша. edma_rx.c#L477-L491: /*  * Аннулирование кэша для skb->data.  * Операция сброса на ядрах A73 также влечёт за собой аннулирование.  * Если пакет передаётся по быстрому пути, а значит, выделенный - под него буфер возвращается в пул по быстрому циклу, можно быть  * уверенными, что аннулирование кэша было выполнено при прошлой передаче.  */  if (unlikely(!skb->fast_recycled)) {      dmac_inv_range_no_dsb((void *)skb->data,                    (void *)(skb->data + rx_alloc_size -                    EDMA_RX_SKB_HEADROOM -                    NET_IP_ALIGN));  } skb->fast_recycled = 0;sourcecraft.dev Область приёма составляет 1856 байт, или 29 строк кэша, начиная со смещения head + 192. При предыдущей передаче произошёл сброс всего двух или трёх строк, причём по другому смещению. «Грязные» строки, оставшиеся вне этой очищенной области, могут сбрасываться в DRAM уже после того, как сетевая карта выполнит DMA-передачу, затирая принятый пакет порциями по 64 байта. Причиной такого сброса может стать обычное вытеснение строк из кэша. На arm64 к этому также приводит аннулирование невыровненной области памяти. Функция __dma_inv_area использует инструкцию dc civac (очистка и аннулирование) для частично заполненных пограничных строк кэша. После того, как «грязные» данные затёрли часть пакета в DRAM, восстановить полученные байты с помощью аннулирования кэша уже не получится. Сетевая карта проверяет контрольную сумму исходного пакета ещё до его повреждения, а код приёма на точке доступа видит аппаратные флаги состояния и помечает пакет как CHECKSUM_UNNECESSARY. Точная последовательность операций внутри PPE скрыта в проприетарном коде драйвера и железа, но анализ сетевых пакетов показывает, что контрольная сумма вычислялась уже после повреждения данных. Повторное использование буферов включается параметром CONFIG_SKB_RECYCLER на этапе компиляции, в рабочей среде такого переключателя нет. Отключение аппаратной разгрузки не даёт буферам уходить на быстрый путь передачи. В результате драйвер перестаёт выставлять флаг fast_recycled, а код приёма полностью аннулирует буфер кэша перед тем, как передать его сетевой карте. Через проводной тракт приёма точки доступа проходит только трафик, скачиваемый Wi-Fi клиентами; загружаемый ими трафик через него не идёт, а обмен данными между проводными клиентами происходит исключительно через коммутатор. Opus 5.5 нашёл баг, а потом отказался его обсуждать Когда я перешёл от диагностики проблемы к её исправлению, Opus 5.5 начал обрывать сессии примерно на каждом втором сообщении. Причём достаточно было просто упомянуть что-то вроде «локального повышения привилегий». И хотя у меня на аккаунте включена опция Cyber Verification Program, это никак не помогло. К слову, Opus 4.8 помог реализовать эксплойт без подобных проблем. Из-за своих защитных механизмов Opus 5.5 также обрывал сессию, когда я просил его вычитать эту статью. А вот GPT-6 Astra вычитывает и правит её без какой-либо кибер-верификации. До отключения offload и после Я протестировал передачу сырого TCP-трафика между теми же двумя компьютерами с включённой аппаратной разгрузкой и выключенной. Offload Направление Данные Скорость Повреждённые блоки по 64 байта Включен LAN -> Wi-Fi 8192 МиБ 103,4 МиБ/с 3 Отключен LAN -> Wi-Fi Тест в течение ночи 95,4 МиБ/с 0 В этом тесте из-за её отключения скорость скачивания упала примерно на 8%. Приходится жертвовать производительностью только потому, что TP-Link не даёт мне нормально починить собственное устройство. При включённой же разгрузке невозможно скачать большой файл по Wi-Fi одним потоком, проходят только обрубки. Когда же я её отключил, за всю ночь тестирования не побился ни один фрагмент, и с тех пор крупные файлы передаются без проблем. Ну а выгрузка с Wi-Fi клиента в LAN и без того работала исправно. После отключения разгрузки начинает расти счётчик NOT_SUPPORT_BRIDGE в файле /sys/sfe/exceptions, так как трафик в режиме моста теперь идёт не по ускоренному сетевому тракту, а по обычному. После перезагрузки роутера настройки сбрасываются, поэтому скрипт-наблюдатель на моём NAS периодически опрашивает устройство и перезапускает эксплойт, если разгрузка снова включилась. Если же у него это не получается, он перезагружает точку через API управления TP-Link и повторяет попытку. При этом на количество таких перезагрузок установлен жёсткий лимит. А ведь в Qualcomm могут при желании починить свой драйвер или хотя бы выложить его в более открытом виде. В чистом OpenWrt этого бага нет, а TP-Link всё равно не выпустит новую прошивку для моего девайса. Хотя похожие баги с DMA, которые я нашёл в самом ядре Linux, заслуживают более внимательного изучения. Вернусь к ним на выходных. Апдейт: отслеживание обрывов Плата Qualcomm, которую я установил в свой Framework 16, именуется WCN785x, и каждые несколько часов она внезапно прекращала отправлять данные на период от 1 до 4 минут. Поскольку у меня уже был рут-доступ к точке, я запустил на EAP770 утилиту apstats параллельно с BPF-зондами на ноутбуке и зафиксировал три обрыва связи, попутно собрав логи с обеих сторон. Всё, что точка доступа отправляла на ноутбук, до него доходило и подтверждалось сообщением ACK. Значит, радиомодуль ноутбука исправно передаёт сигналы, и приёмник точки их ловит. Вот только кадры данных с ноута почему-то не уходят. На самом ноутбуке пакеты продолжали поступать в драйвер ath12k, и в очереди скопилось аж несколько тысяч кадров. Прошивка подтверждала обработку лишь по нескольку кадров за раз, а оставшиеся в конечном итоге вернула с сообщением CMD_REMOVE_AGED_FRAMES — так в результате этого обрыва было потеряно 10630 кадров из 26388. В остальном драйвер вёл себя исправно.   На стороне точки доступа счётчик rx_data в течение большинства тактов оставался на нуле (+0), за исключением редких всплесков. При этом ошибок приёма (RX errors) и повторных попыток зафиксировано не было — то есть кадры не покидали сетевую плату ноутбука. Затем плату внезапно «отпускало», и она выплёвывала всю накопившуюся очередь за две секунды: точка доступа зафиксировала скачки rx_data+3273, а затем +12498, в то время как ноутбук зарегистрировал сразу 7751 подтверждённых кадров. Проблема явно была не на стороне ОС или эфира: уровень сигнала оставался от -31 до -42 дБм, фоновое сканирование не выполнялось, да и IP-стек на ноутбуке работал абсолютно нормально. Плюс я уже использую последнюю официальную прошивку — WLAN.HMT.1.1.c7-00108 UPSTREAM-3. Драйвер ath12k получает обратно только статусы завершения операций, а всё, что связано с отправкой кадра в эфир, определяется внутри закрытого бинарника amss.bin от Qualcomm. Так что дело в самой прошивке. Я до сих пор не знаю, почему пропадает передача. Всплески трафика, который прорывался во время обрыва, похожи на работу планировщика отправки данных в стандартах 802.11ax/be — передачу на основе триггеров или механизм MU EDCA. Но таких настроек я на устройстве не нашёл, так что проверить эти предположения не получилось. Пока что я переключил радиомодуль 5 Ггц с Wi-Fi 7 на Wi-Fi 6 (802.11ax) и оставил скрипт наблюдать за ним на 24 часа. Если обрывы прекратятся, значит, это проблема Wi-Fi 7 — тогда я останусь на Wi-Fi 6 и отправлю баг-репорт разработчикам ath12k. Если нет, то прошивка косячит в любом режиме, и мне останется либо писать баг-репорт, либо просто купить сетевую карту от Intel.

tp-linkのは、mediatekのこれとか openwrt/target/linux/mediatek/filogic/base-files/lib/preinit/09_mount_cfg_part at main · openwrt/openwrt github.com/openwrt/openwrt/blob/main/target/linux…

GLM-5.3 abliterated 版で試してみたけど、あんまり具体は話さなかった。 ファームウェアの更新がオフィシャルで提供されてなくても、下記のようなのを使う選択肢もある。（ 実家のも一応対応してた。） OpenWrt github.com/openwrt

openwrt#19142 hs20_oper_friendly_name って hostapd から消えてたのか・・・

Huawei HG658c V2 Router's PCB code "AMOHG658V2M VER. B" UART points Huawei HG658c V2 ; S/N: 3KH7S17105008884 20 ; motherboard PCB code "AMOHG658V2M VER. B,“ purchased from Vodafone ; HiSilicon SD5116 (HiSilicon Hi5610 family) Dual-Core ARM Cortex-A9 MPCore ARMv7-A (32-bit) 800 MHz – 1.0 GHz range (with dynamic frequency scaling support) MCU/SoC ; Router. Details: openwrt#25771 I'm sharing this in case it might be useful to someone else.

OpenWrtマージチャレンジ、最難関だった11k shared driverのPR通った！あとはLN6001のath11k, 12kのコンフィグ登録できたら完成！ openwrt#25595