huggy's blog

BS/110度CS アンテナを設置する記録

Fri, 07 Aug 2026 00:00:00 +0900

はじめに

この記事は中国語からの翻訳です。不自然な点がありましたらご容赦ください。

原記事（中国語）

こういう訳あり物件に住むと本当にいろいろ大変で、テレビを見るだけで疲れる = =

だいたいの状況としては、地デジも BS/CS も信号がなくて、たぶん屋根のパラボラが悪い？　それとも配線？

でも屋根に上がるためのはしごがなくて、ようやくある日、社長の家から 4 メートルのはしごを盗んできた。
これで屋根に上がってパラボラを調整できるぞ、となったのに、ずっと動かしても信号がない（

後から持っている知識だけで少し考えて、ようやく原因が分かったのでこの記事を書いた。
要するに、よく分からないものをいじるときはまずパラメータを見よう、思い込みはいけない。

本文

屋根に上がる

引っ越してきた時点で屋根には地デジ + 衛星アンテナが 2 セットあった。1 セット目は強風で倒れたらしく床に転がっていて、そのため、もう 1 セット追加で設置したのだと思う。
なので家じゅうの同軸もめちゃくちゃで、使えない 2 系統分の配線がそのまま残っている。無理やり詰め込むなよ、再利用できなかったのか？（もうどういう神施工だったのか分からない）

簡単に言うと、屋根から室内へ来ている同軸は合計 4 本で、感覚的には 3+1（3 本は同じ管へ、1 本は別の管へ入り、家の反対側から室内へ入る）。実際に室内までどう通っているのかは、もう本当に分からない。。。

そこで屋根から階下まで、テスト用の仮設同軸を 1 本だけ引いた。これなら同軸経路の干渉を少し減らせるし、テストもしやすい。
新品のパラボラアンテナには、方向が合ったことをランプの点灯／消灯で知らせる小型の携帯測定器が付属するらしい。でも私は知らなかったので、Android TV チューナーと adb + scrcpy を使い、屋根で信号状態を表示した。もちろん PT3 + checksignal でも試した。

とにかく動かしまくったが、checksignal / recpt1 はずっと死んだままだった：

recpt1 --device /dev/pt3video0 --strip --lnb 15 --b25 BS15_0 - -

using device: /dev/pt3video0
enable B25 strip
LNB = 15V
using B25...
Cannot tune to the specified channel: /dev/pt3video0

でもテレビボックスをつないで受信レベルを見ると、信号自体は検出できて、パラボラを動かすと変化も見える。

ただし BS1 だけはずっと信号 0。最初は、最悪 BS1 を見なければいいか、くらいであまり気にしていなかった：

BS1 は 0
BS3 はだいたい 65
BS5 はだいたい 70
BS7 もだいたい 70
BS15 も 60-70 くらい
110CS は全滅
BS/CS 4K8K も全滅

受信レベルがまったく出なければ、給電なし・断線・パラボラの向き違いのどれかだ。でもレベルはあるのにチャンネルが一つも見つからないのは、かなり謎だった。。

そしてチャンネルが一つも見つからず、~~日中に屋根へ上がって暑さで死にかけながら~~、信号はあるのに復号できない沼へ入った。

最初は LNB が壊れたと思った

まずは普通の考え方で切り分けた：

同じ線で地デジは正常
LNB 給電はパラボラ側の F コネクタでテスター測定して 15V ある
角度を変える、外して手持ち、地面に置く、全部試した

普通の BS/110度CS パラボラなら、15V が来ていて方位と仰角がだいたい合っていれば、少なくとも BS15（NHK BS）ならロックする見込みがある。
でもまったくロックしないし、CS も全滅。

だから最初は、LNB はいまシュレーディンガー状態なのだと思った。LNB は半壊すると全 0 ではなく、一部の周波数で見かけの受信レベルが出ることは実際にある。
でも見れば見るほど違和感があった。

仰角と LNB の形状がおかしい

このパラボラは以前の仰角が明らかに 50 度を超えていた。
iPhone の水準器で支柱が地面に対して垂直なのを確認したので、仰角はたぶん合っている（

これはかなり変だ。
大阪から 110E の BS/110度CS を見る仰角は約 41 度のはず。
50 度付近なら大阪の真南方向にある静止軌道の最高点、つまり 132E-140E 付近、あるいは 124/128E っぽい。

さらに重要なのは、この LNB 部分が回転できること。

日本の BS・110度CS 放送では、右旋・左旋の円偏波を使う。一方、この LNB には回転できるリングがある。
直線偏波用 LNB なら、本体を回して水平／垂直偏波の向きを受信信号に合わせる必要がある。

ここで結論がひっくり返り始めた：

このパラボラの反射面は SUPER DISH だが、今付いている LNB/フィード部は標準 BS/110度CS 用ではない可能性が高い。

つまり壊れているのではなく、最初から種類が違うのかもしれない。

キメラ

そこで屋根にある、もう 1 組の壊れたアンテナ（支柱が折れていた）に目を向けた。でもパラボラを固定するネジそのものがなめていたので、LNB 側に手を出して、なんとかキメラにできないか見てみた。
今のパラボラ + 廃棄パラボラの LNB、という組み合わせ。
結果、LNB を固定する部分もなめていた（

ということで、結束バンド、スタート。~~何のバンドだよ~~

すると、少し動かしただけでテレビを視聴できるだけの信号を受信できた。

方位・仰角の対照

以下には GPT による補助・整理を含む箇所があります。考え方はだいたいこんな感じです。

大阪付近では、おおむねこう見ればよい：

軌道位置	用途の目安	真方位	仰角
110E	BS / 110CS	220.0°	41.4°
124E	スカパー！プレミアム	199.7°	47.9°
128E	スカパー！プレミアム	193.0°	48.9°
132E	JCSAT-5A 付近	186.1°	49.5°
134E	Apstar 6C 付近	182.6°	49.7°
136E	真南付近	179.1°	49.7°
138E	Telstar 18 付近	175.6°	49.6°
140E	Express-AM5 付近	172.1°	49.4°

なので、大阪でパラボラが長期間 50 度前後に固定されていたなら、ほぼ 110E ではない。
元の位置から 110E の方位（220 度）へ向けるために時計回りに少し回す必要があるなら、元の位置は 124/128E か 132E-140E のあたりだった可能性が高い。

なぜ BS1 は 0 なのに、BS3/5/7 にはレベルがあるのか

以下には GPT による補助・整理を含む箇所があります。

ここがいちばん面白い。

日本の普通の BS/110度CS LNB の局部発振周波数は、通常 10.678GHz で計算する。
一方、スカパー！プレミアムサービス用などの直線偏波 CS コンバーターには、局部発振周波数が 11.2GHz のものがある。

テレビは BS モードで、自分につながっているのが標準 BS/110度CS LNB だと思い込んでいるので、固定された BS-IF 周波数を測る：

テレビ表示	BS-IF
BS1	1049.48 MHz
BS3	1087.84 MHz
BS5	1126.20 MHz
BS7	1164.56 MHz
BS15	1318.00 MHz

でも実際につながっているのが 11.2GHz の CS LNB なら、テレビが測っている IF から逆算される衛星上の周波数は：

実際の RF = 間違った LNB の局部発振周波数 + テレビが測っている IF

こうなる：

テレビ表示	テレビが測る IF	LNB=11.2GHz の場合に実際受信する RF	最寄りの 110CS 周波数	差
BS1	1049.48 MHz	12249.48 MHz	ND2 12291 MHz	-41.52 MHz
BS3	1087.84 MHz	12287.84 MHz	ND2 12291 MHz	-3.16 MHz
BS5	1126.20 MHz	12326.20 MHz	ND4 12331 MHz	-4.80 MHz
BS7	1164.56 MHz	12364.56 MHz	ND6 12371 MHz	-6.44 MHz
BS9	1202.92 MHz	12402.92 MHz	ND8 12411 MHz	-8.08 MHz
BS11	1241.28 MHz	12441.28 MHz	ND10 12451 MHz	-9.72 MHz
BS13	1279.64 MHz	12479.64 MHz	ND12 12491 MHz	-11.36 MHz
BS15	1318.00 MHz	12518.00 MHz	ND14 12531 MHz	-13.00 MHz

これで説明が付く：

BS1 は 12249.48MHz に対応し、最寄りの 110CS ND2 から 41.52MHz 離れているのでレベルは 0
BS3/BS5/BS7 はそれぞれ 110CS の ND2/ND4/ND6 に近く、テレビの AGC がエネルギーを検出できる
BS15 も ND14 に近いため、見かけのレベルが出る
ただしテレビはこれらを BS トランスポンダだと思っており、実際は局部発振周波数の違いでずれて見えている CS 周波数なので、永遠にロックできない

さらに BS7 は現在、普通にスキャンできる BS チャンネルがもともとないのに、70 と表示される。
これも、テレビが表示しているのは「この BS トランスポンダに復号可能な番組がある」ではなく、「この IF 点の近くに RF エネルギーがある」だけだと分かる。

なぜ 110CS に切り替えると逆に全部 0 なのか

以下には GPT による補助・整理を含む箇所があります。

これも同じモデルで説明できる。

テレビは 110CS モードでも、LNB は標準 BS/110度CS 用の 10.678GHz だと仮定する。
だから ND2 を調べるときは：

ND2_IF = 12291MHz - 10678MHz = 1613MHz

だが実際の LNB が 11.2GHz なら、この IF が対応する衛星上の周波数は：

実際の RF = 11200MHz + 1613MHz = 12813MHz

つまり目標の 110CS 周波数より、全体でこれだけ高い：

11200 - 10678 = 522MHz

完全な表は以下：

テレビ表示 110CS	正常な 110CS RF	テレビが合わせる IF	11.2GHz LNB 経由で実際に受信する RF
ND2	12291 MHz	1613 MHz	12813 MHz
ND4	12331 MHz	1653 MHz	12853 MHz
ND6	12371 MHz	1693 MHz	12893 MHz
ND8	12411 MHz	1733 MHz	12933 MHz
ND10	12451 MHz	1773 MHz	12973 MHz
ND12	12491 MHz	1813 MHz	13013 MHz
ND14	12531 MHz	1853 MHz	13053 MHz
ND16	12571 MHz	1893 MHz	13093 MHz
ND18	12611 MHz	1933 MHz	13133 MHz
ND20	12651 MHz	1973 MHz	13173 MHz
ND22	12691 MHz	2013 MHz	13213 MHz
ND24	12731 MHz	2053 MHz	13253 MHz

これらの周波数はすでに 12.8～13.2 GHz まで飛んでおり、110度CS の受信周波数帯から離れている。だから 110CS 画面が全 0 なのは当然。

BS4K8K が全 0 なのも同じ。
4K・8K は左旋円偏波と拡張 IF を使うため、この H/V 直線偏波 CS LNB とは受信方式が異なる。

円偏波を直線偏波 LNB に入れるとどうなるか

以下には GPT による補助・整理を含む箇所があります。

もうひとつの疑問は：

110E は右旋/左旋円偏波なのに、直線偏波 LNB ならまったく受からないのでは？

完全に受からないわけではない。

円偏波は、互いに直交する 2 つの直線偏波成分に分解できる。
だから H/V 直線偏波 LNB でも、理論上は円偏波の電力の半分を受信でき、損失は約 3 dB。
これだけあれば、テレビの AGC/受信レベル画面に「エネルギーあり」と表示される。

でも、それは復調できるという意味ではない。
実際に BS/CS を見るには、同時に以下を満たす必要がある：

衛星位置が合っている
偏波が合っている
局部発振周波数が合っている
IF 周波数表が合っている
変調方式が合っている
ISDB-S / ISDB-S3 の同期と TMCC が合っている

局部発振周波数が違えば、テレビは間違った周波数を聞いている。
規格が違えば、電波レベルが高くても番組は出ない。

計算式

以下には GPT による補助・整理を含む箇所があります。

普通のダウンコンバート：

IF = RF - LO
RF = LO + IF

標準 BS/110度CS LNB：

LO_bs = 10678 MHz

間違った CS LNB を仮定：

LO_wrong = 11200 MHz

BS の奇数トランスポンダの近似中心周波数：

BS_RF(n) = 11727.48 + ((n - 1) / 2) * 38.36
BS_IF(n) = BS_RF(n) - 10678

110CS 偶数 ND の近似中心周波数：

CS_RF(nd) = 12291 + ((nd - 2) / 2) * 40
CS_IF(nd) = CS_RF(nd) - 10678

テレビが BS 画面である BS-IF を測っていて、実際の LNB が 11.2GHz の場合：

Actual_RF = 11200 + BS_IF(n)

テレビが 110CS 画面である CS-IF を測っていて、実際の LNB が 11.2GHz の場合：

Actual_RF = 11200 + CS_IF(nd)
 = CS_RF(nd) + (11200 - 10678)
 = CS_RF(nd) + 522

最後に

今回いちばんの罠は、「反射面に SUPER DISH と書いてある」ことを「これは標準 BS/110度CS アンテナだ」と勝手に理解していたこと。
でも実際には、反射面・フィード部・LNB は別物。

最終的な判断は：

古い反射面は DX SUPER DISH の可能性がある
ただし今の LNB/フィード部は、明らかに直線偏波 CS/Ku 用っぽい
テレビの BS 画面に出たのは、局部発振周波数の違いによる見かけ上の受信レベル
110CS と 4K8K が全 0 なのも、この説明なら辻褄が合う
PT3 の recpt1 がチューニングに失敗したのもソフトウェアの問題ではない

なので今回は単純な「LNB 故障」ではなく、むしろ「LNB の種類が違う」だった。

最後に中古の MASPRO BC45RL を買った。標準 BS/110度CS・4K8K 対応。
こういうものは、アンテナ一式を丸ごと交換するのがいちばん楽だ。屋根に残された設備相手に命まで賭けるな。

完

最後？

いじっている最中、一度、夜の雨の日に 4K の信号があまり良くなくて屋根へ調整に行った。はしごを下りる途中で滑り、手を金属で切ってしまい、そのまま救急外来にかかることになった（

こういう作業は焦らずゆっくりやろう = =
それと、こんな小さなことで命を賭けるな。

終
制作・著作
━━━━━
ⒽⓊⒼⒼⓎ

设置 BS/CS 天线的记录

Fri, 07 Aug 2026 00:00:00 +0900

开篇废话

住这种訳あり的物件感觉实在是折腾，看个电视都累 = =

大概情况的话是这样的：地面波和 BS/CS 都没有信号，大概是屋顶的锅有问题？或者配线

但是没有梯子能上屋顶，终于有一天把社长家4米高的梯子偷过来了，能上屋顶调锅了，但是一直摇都没信号（

后面用仅有的知识想了下，终于是知道了原因，然后写了这篇文章。
总的来说就是，折腾各种不熟悉的东西还是先看看参数，别想当然了。

正文

上去屋顶

搬进来之后楼顶已经有两套地面波 + 卫星锅了，第一套看上去是因为被大风吹倒了，就挂在地板上了，所以又搭建了一套。
所以整个屋子里面的同轴也乱七八糟的，就同时容纳了2套完全用不了的线，硬塞，不能复用吗？（我已经不知道那些神人是怎么施工的了）

简单描述下就是，屋顶总共有4根同轴线到室内，3+1 的感觉（3个接同一个管，1个接向另外一根管，在房子另外一侧入户），实际上到室内我已经不知道是怎么走的了，实在是。。。

所以我单独引了一路临时的同轴从屋顶拉到楼下，这样可以减少点因为同轴线的干扰，也稍微方便下测试。
然后如果是全新的锅的话，会有一个便携的会亮（灭）灯的小装置可以让你知道锅对准了，我由于不知道，就使用了 Android tv tuner 以及 adb + scrcpy 来在屋顶显示信号状态，当然我还尝试过使用我的 pt3 + checksignal 来测试信号。

总之我摇来摇去， checksignal / recpt1 始终是嗝屁的状态：

recpt1 --device /dev/pt3video0 --strip --lnb 15 --b25 BS15_0 - -

using device: /dev/pt3video0
enable B25 strip
LNB = 15V
using B25...
Cannot tune to the specified channel: /dev/pt3video0

但是电视盒子接上去看受信レベル的话，是可以检测到信号的，动锅也看得到变化。

只不过 BS1 一直都是 0 信号，起初我也没太在意，因为觉得大不了 BS1 不看了：

BS1 是 0
BS3 大概 65
BS5 大概 70
BS7 大概 70
BS15 也有 60-70 左右
110CS 全灭
BS/CS 4K8K 全灭

如果完全没信号，那就是没供电、线断了、锅没对准，但是有信号又扫不到台，就很迷惑。。

但是随着扫不到台，~~以及白天去楼顶热死我了~~ 进入了有信号但是无法解码的困局中。

一开始怀疑 LNB 坏了

我先按普通思路排：

相同的线地上波正常
LNB 供电在锅的 F 头用万用表量到了 15V
换角度、拆下来手持、放在地面上都试过

如果是普通 BS/110CS 锅，15V 到了、方向和仰角差不多，那至少 BS15（NHK BS）应该有机会 lock。但是它完全不 lock，CS 也全军覆没。

所以一开始我觉得这是 LNB 现在属于了薛定谔的状态，因为 LNB 半坏的时候确实可能不是全 0，而是某些频点有假 level。但是后来我越看越觉得不对。

仰角和 LNB 形态不对

这个锅之前的仰角明显在 50 度以上。我用 iPhone 水平仪确认过支架是垂直地面的，所以仰角大概是没有问题的（

这就很怪了。大阪看 110E BS/110CS 的仰角应该只有约 41 度。 50 度附近更像是大阪正南方向的同步轨道最高点，也就是 132E-140E 附近，或者 124/128E 的感觉

更关键的是，这个 LNB 部分可以旋转。

普通日本 BS/110CS 是圆偏波（左旋右旋），但这个 LNB 有可旋转的环线偏波 LNB 才需要旋转本体，让水平/垂直偏波方向和卫星来的偏波对齐。

所以这里结论开始反转：

这个锅的盘面是 SUPER DISH，但当前装的 LNB/馈源大概率不是标准 BS/110CS 高频头。

也就是说，它可能不是坏了，而是从一开始类型就不对。

缝合怪

于是我把目光投向了屋顶另外一套坏掉了的接收器（被折断了），但是试了下锅固定的螺丝本身划牙了，所以我对LNB部分下手，看看能不能缝合一下。用目前的锅 + 废弃的锅的 LNB 。结果 LNB 固定部分也滑牙了（

于是扎带启动 ~~（什么乐队啊）~~

结果就随便摇了下就收到能收听电视的信号了。

方位和仰角对照

此处包含 GPT 加工生成部分，总之思路是这样的

大阪附近大致可以这么看：

轨位	用途参考	真方位	仰角
110E	BS / 110CS	220.0°	41.4°
124E	スカパー！プレミアム	199.7°	47.9°
128E	スカパー！プレミアム	193.0°	48.9°
132E	JCSAT-5A 附近	186.1°	49.5°
134E	Apstar 6C 附近	182.6°	49.7°
136E	正南附近	179.1°	49.7°
138E	Telstar 18 附近	175.6°	49.6°
140E	Express-AM5 附近	172.1°	49.4°

所以如果一个锅在大阪被长期固定在 50 度左右，它基本不是 110E。如果从原位置转到 110E 的 220 度方向需要顺时针转一截，那原位置很可能在 124/128E 或 132E-140E 那一段。

为什么 BS1 是 0，但 BS3/5/7 有 level

此处包含 GPT 加工生成部分这里最有意思。

日本普通 BS/110CS LNB 的本振一般按 10.678GHz 算。但是スカパー！プレミアム/CS 系 LNB 常见本振是 11.2GHz。

电视在 BS 模式下以为自己接的是标准 BS/110CS LNB，所以它会去测固定的 BS-IF 频点：

电视显示	BS-IF
BS1	1049.48 MHz
BS3	1087.84 MHz
BS5	1126.20 MHz
BS7	1164.56 MHz
BS15	1318.00 MHz

但如果实际接的是 11.2GHz 的 CS LNB，那么电视测到的 IF 反推回天上的频率就是：

实际 RF = 错误 LNB 本振 + 电视正在测的 IF

于是：

电视显示	电视测的 IF	若 LNB=11.2GHz，实际接收 RF	最近的 110CS 频点	偏差
BS1	1049.48 MHz	12249.48 MHz	ND2 12291 MHz	-41.52 MHz
BS3	1087.84 MHz	12287.84 MHz	ND2 12291 MHz	-3.16 MHz
BS5	1126.20 MHz	12326.20 MHz	ND4 12331 MHz	-4.80 MHz
BS7	1164.56 MHz	12364.56 MHz	ND6 12371 MHz	-6.44 MHz
BS9	1202.92 MHz	12402.92 MHz	ND8 12411 MHz	-8.08 MHz
BS11	1241.28 MHz	12441.28 MHz	ND10 12451 MHz	-9.72 MHz
BS13	1279.64 MHz	12479.64 MHz	ND12 12491 MHz	-11.36 MHz
BS15	1318.00 MHz	12518.00 MHz	ND14 12531 MHz	-13.00 MHz

这就解释通了：

BS1 对应 12249.48MHz，离最近的 110CS ND2 差了 41.52MHz，所以 level 是 0
BS3/BS5/BS7 分别靠近 110CS 的 ND2/ND4/ND6，所以电视 AGC 能看到能量
BS15 也靠近 ND14，所以有假 level
但电视以为这些是 BS transponder，实际却是错本振映射出来的 CS 频点，所以永远不能 lock

而且 BS7 本来现在也没有普通可扫出的 BS 台，但它仍然显示 70。这也说明电视显示的不是「这个 BS 转发器有可解码节目」，只是「这个 IF 点附近有 RF 能量」。

为什么切到 110CS 反而全是 0

此处包含 GPT 加工生成部分这个也能用同一个模型解释。

电视在 110CS 模式下，还是假设 LNB 是标准 BS/110CS 的 10.678GHz。所以它调 ND2 时会调：

ND2_IF = 12291MHz - 10678MHz = 1613MHz

但实际 LNB 如果是 11.2GHz，那么这个 IF 对应的天上频率变成：

实际 RF = 11200MHz + 1613MHz = 12813MHz

也就是比目标 110CS 频率整体高了：

11200 - 10678 = 522MHz

完整表如下：

电视显示 110CS	正常 110CS RF	电视调的 IF	实际经 11.2GHz LNB 听到的 RF
ND2	12291 MHz	1613 MHz	12813 MHz
ND4	12331 MHz	1653 MHz	12853 MHz
ND6	12371 MHz	1693 MHz	12893 MHz
ND8	12411 MHz	1733 MHz	12933 MHz
ND10	12451 MHz	1773 MHz	12973 MHz
ND12	12491 MHz	1813 MHz	13013 MHz
ND14	12531 MHz	1853 MHz	13053 MHz
ND16	12571 MHz	1893 MHz	13093 MHz
ND18	12611 MHz	1933 MHz	13133 MHz
ND20	12651 MHz	1973 MHz	13173 MHz
ND22	12691 MHz	2013 MHz	13213 MHz
ND24	12731 MHz	2053 MHz	13253 MHz

这些频率已经跑到 12.8-13.2GHz 了，远离普通 110CS 的主频段，所以 110CS 页面全 0 是正常的。

BS4K8K 全 0 也一样。 4K8K 涉及左旋圆偏波和扩展 IF，和这种 H/V 线偏波 CS LNB 完全不是一个体系。

圆偏波进线偏波 LNB 会怎样

此处包含 GPT 加工生成部分还有一个问题是：

110E 是右旋/左旋圆偏波，线偏波 LNB 不是应该完全收不到吗？

不是完全收不到。

圆偏波可以分解成两个正交线偏波分量。所以 H/V 线偏波 LNB 理论上能吃到圆偏波的一半功率，损失大概 3dB。这足够让电视的 AGC/受信レベル页面显示「有能量」。

但这不代表能解调。要真的看 BS/CS，需要同时满足：

卫星位置对
偏波对
本振对
IF 频率表对
调制方式对
ISDB-S / ISDB-S3 的同步和 TMCC 对

只要本振错了，电视就在错误的频点听。只要制式错了，电平再高也不会有节目。

计算公式

此处包含 GPT 加工生成部分

普通下变频：

IF = RF - LO
RF = LO + IF

标准 BS/110CS LNB：

LO_bs = 10678 MHz

假设错误 CS LNB：

LO_wrong = 11200 MHz

BS 奇数 transponder 的近似中心频率：

BS_RF(n) = 11727.48 + ((n - 1) / 2) * 38.36
BS_IF(n) = BS_RF(n) - 10678

110CS 偶数 ND 的近似中心频率：

CS_RF(nd) = 12291 + ((nd - 2) / 2) * 40
CS_IF(nd) = CS_RF(nd) - 10678

如果电视在 BS 页面测某个 BS-IF，但实际 LNB 是 11.2GHz：

Actual_RF = 11200 + BS_IF(n)

如果电视在 110CS 页面测某个 CS-IF，但实际 LNB 是 11.2GHz：

Actual_RF = 11200 + CS_IF(nd)
 = CS_RF(nd) + (11200 - 10678)
 = CS_RF(nd) + 522

最后

这次最大的坑是，我把「盘面写着 SUPER DISH」默认理解成「这是标准 BS/110CS 天线」。但实际上，盘面、馈源、LNB 是三件事。

最后的判断是：

旧盘面可能是 DX SUPER DISH
但当前 LNB/馈源明显更像线偏波 CS/Ku 用途
电视 BS 页面显示的是错误本振映射后的假 level
110CS 和 4K8K 全 0 完全符合这个解释
PT3 recpt1 tune 失败也不是软件问题

所以这次不是单纯「LNB 坏了」，而更像「LNB 类型不对」。

最后我买了一个二手 MASPRO BC45RL，标准 BS/110CS 4K8K 对应。这种事情还是整套换掉最省事，别跟屋顶遗留设备赌命？

完

最后？

其中折腾的时候有一次晚上雨天，4K 的信号不是太好，我去屋顶调锅，然后下楼梯的时候摔了下，手被金属划伤了，也是给我挂上急诊了（

告诉我们折腾东西还是要慢一点 = = 然后别和这些小事情赌命。

以上

富士通 PRIMERGY TX1320 M4 のファン回転数を調整する話

Tue, 30 Jun 2026 02:00:00 +0900

はじめに

夏になるとこの当番、自宅のサーバーたちが本当にうるさすぎるので、
ファン回転数を調整する方法を少し調べた。　　

~~FIFAを見るだけでも落ち着かない~~

具体的な調査過程は省略する。
要するに、IPMI にコマンドを投げるスクリプトを使うだけなので、Python、ipmitool、lm_sensors が必要。

本文

プロジェクトはこちら。

https://github.com/makeding/fujitsu-1320-m4-fancontrol

環境

こちらで動作確認できた環境は以下。

FUJITSU PRIMERGY TX1320 M4
iRMC S5 Firmware Revision 3.31P (1.00)
SDR 3.40

他の iRMC や他の機種で動く保証はない。

依存関係

Debian / Ubuntu:

apt install git python3 ipmitool lm-sensors sensors-detect

NixOS ならだいたいこんな感じ。

environment.systemPackages = with pkgs; [
 python3
 ipmitool
 lm_sensors
];

温度が見えることを確認する。

sensors

自分の環境では主に Mellanox NIC の温度を見ている。出力はこんな感じ。

mlx5-pci-0200
Adapter: PCI adapter
sensor0: +81.0°C (crit = +105.0°C, highest = +81.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +41.0°C (high = +86.0°C, crit = +100.0°C)

手動で調整する

インストールする。

git clone https://github.com/makeding/fujitsu-1320-m4-fancontrol.git
cd fujitsu-1320-m4-fancontrol
install -m 0755 irmc_fan.py /usr/local/sbin/irmc_fan.py
install -m 0755 irmc_fan_daemon.py /usr/local/sbin/irmc_fan_daemon.py

よく使うコマンド。

# 40% に設定
/usr/local/sbin/irmc_fan.py set 40

# 現在のファン回転数を見る
/usr/local/sbin/irmc_fan.py sdr

# iRMC の自動制御に戻す
/usr/local/sbin/irmc_fan.py clear

簡単なデーモン

もちろん小さなデーモンも書いた。sensors を定期的に実行し、主に mlx5-pci-0200:sensor0 を見て、できるだけ 85°C 以内に収める。ついでに CPU Package と PCH も見る。

手動で起動する。

/usr/local/sbin/irmc_fan_daemon.py --interval 10

出力例:

2026-06-30 02:04:25 pwm=45% want=45% mlx=81.0C mlx2=81.0C cpu=41.0C pch=59.0C

デフォルトの方針:

mlx5 が 75°C 未満ならできるだけ静かにする
85°C に近づいたらはっきり回転数を上げる
sensors が読めない場合は 70% まで上げる。センサー取得に失敗したまま低速で回すのを避けるため
回転数を上げるときは速く、下げるときはゆっくり。頻繁な上下動を避ける

NIC の sensor 名が違う場合はパラメータで変更できる。

/usr/local/sbin/irmc_fan_daemon.py \
 --mlx-chip mlx5-pci-0200 \
 --mlx-label sensor0

systemd

簡単な service を作る。

[Unit]
Description=Fujitsu iRMC smart fan control
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/local/sbin/irmc_fan_daemon.py --interval 10 --min-pwm 30 --max-pwm 100
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

保存先:

/etc/systemd/system/irmc-fan-daemon.service

有効化する。

systemctl daemon-reload
systemctl enable --now irmc-fan-daemon.service
journalctl -u irmc-fan-daemon.service -f

スクリプトを別の場所に置いた場合は、ExecStart のパスを変更すればよい。

まとめ

標準的な EC 経由ではないファン調整は本当に面倒だった。

以上。

終
制作・著作
━━━━━
ⒽⓊⒼⒼⓎ

富士通 PRIMERGY TX1320 M4 调整风扇转速

Tue, 30 Jun 2026 02:00:00 +0900

开篇废话

这玩意夏天实在是太 J8 吵了，所以研究了下如何调整转速。 ~~ 主要看个世界杯都不安宁~~

具体过程不分享了，反正就是有个脚本给 IPMI 发命令，所以你需要 Python、ipmitool 和 lm_sensors。

正文

项目在这里：

https://github.com/makeding/fujitsu-1320-m4-fancontrol

环境

我这里成功的环境是：

FUJITSU PRIMERGY TX1320 M4
iRMC S5 Firmware Revision 3.31P (1.00)
SDR 3.40

其他 iRMC 固件版本、机型不保证可用。
无保证。

依赖

Debian / Ubuntu:

apt install git python3 ipmitool lm-sensors sensors-detect

NixOS 大概是：

environment.systemPackages = with pkgs; [
 python3
 ipmitool
 lm_sensors
];

确认能看到温度：

sensors

我这台主要看 Mellanox 网卡温度，类似这样：

mlx5-pci-0200
Adapter: PCI adapter
sensor0: +81.0°C (crit = +105.0°C, highest = +81.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +41.0°C (high = +86.0°C, crit = +100.0°C)

手动调速

安装：

git clone https://github.com/makeding/fujitsu-1320-m4-fancontrol.git
cd fujitsu-1320-m4-fancontrol
install -m 0755 irmc_fan.py /usr/local/sbin/irmc_fan.py
install -m 0755 irmc_fan_daemon.py /usr/local/sbin/irmc_fan_daemon.py

常用命令：

# 设成 40%
/usr/local/sbin/irmc_fan.py set 40

# 看当前风扇转速
/usr/local/sbin/irmc_fan.py sdr

# 还原 iRMC 自动控制
/usr/local/sbin/irmc_fan.py clear

简单守护

当然又写了一个小守护，循环跑 sensors，主要盯 mlx5-pci-0200:sensor0，尽量压在 85°C 内，同时看 CPU Package 和 PCH。

手动跑：

/usr/local/sbin/irmc_fan_daemon.py --interval 10

输出大概这样：

2026-06-30 02:04:25 pwm=45% want=45% mlx=81.0C mlx2=81.0C cpu=41.0C pch=59.0C

默认策略：

mlx5 低于 75°C 时尽量安静
接近 85°C 开始明显升速
读不到 sensors 时直接升到 70%，避免传感器挂了还低速转
升速快、降速慢，避免转速来回抖

如果你的网卡 sensor 名字不一样，可以改参数：

/usr/local/sbin/irmc_fan_daemon.py \
 --mlx-chip mlx5-pci-0200 \
 --mlx-label sensor0

systemd

简单起一个服务：

[Unit]
Description=Fujitsu iRMC smart fan control
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/local/sbin/irmc_fan_daemon.py --interval 10 --min-pwm 30 --max-pwm 100
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

保存到：

/etc/systemd/system/irmc-fan-daemon.service

启用：

systemctl daemon-reload
systemctl enable --now irmc-fan-daemon.service
journalctl -u irmc-fan-daemon.service -f

如果脚本放到了别的位置，改一下 ExecStart 里的路径即可。

结尾

这套不走标准 EC 的调整风扇真麻烦，跑了。

完

HGW とひかり電話の組み合わせにまつわる怪談

Tue, 09 Jun 2026 23:00:00 +0900

はじめに

この記事は中国語からの翻訳です。不自然な点がありましたらご容赦ください。

原記事（中国語）

ネットワークを少しでもいじっている良い子のみんなにとって、HGW（Home Gateway）という存在はやはり避けて通れない話題です。
もちろん、HGW は避けにくいとはいえ、届いたら部屋の隅に放置して埃をかぶらせることもできます。
たぶん？

そして怪談が始まりました。

本文

その前に

まず契約状況を説明しておきます。
うちがenひかりで　フレッツ光クロスv6プラスとひかり電話を契約しました。

ところが enひかりのスタッフから、手続きを進めるには HGW の契約が必須だと電話で強く言われました。
こちらは YAMAHA NVR（ひかり電話を利用できるルーター）を自前で用意していると伝えたのですが、
それでも不可とのことでした（何度も電話がかかってきて再確認されました）。理由は、YAMAHA のそのルーターは 1Gbps までしか対応していないため使えない、というものでした。

結局 enひかりのカスタマーサポートを説得しきれず、泣く泣く月額 220 円で HGW を契約しました。

構成

もちろん、HGW というこの困った機器が自宅に届いた後は、そのまま部屋の隅に置いて埃をかぶらせることにしました。ネットワーク構成は以下の通りです。

ONU -> OpenWrt(IPoE)
 -> YAMAHA NVR500(ひかり電話)

実際の構成としては以下のようになります。

ONU->SWITCH(vlan=100)

vlan=100 -> ONU | OpenWrt | NVR500

開通当日

開通当日もまた怪談でした。当初は 6 月 2 日に開通予定だったのですが、2 日は人が多いということで、結局 3 日になりました。そしておそらく午前 3 時頃にネットが使えるようになりました。

ところがその日の 21 時頃、またネットが切断されました。その時は外で餃子の王将を食べていたのですが、帰宅して確認すると、IPv6 アドレスが v6プラス（ISP 側のアドレス）から NGN（NTTの閉域網）側のアドレスに戻っていました。

開通 2 日目

局側で何か設定を間違えたのではないかと推測し、翌朝 10 時頃に enひかりへ電話しました。
電話では午後には復旧予定と言われましたが、実際には電話の 30 分後には復旧しました。

しかし 13 時ちょうどに、また正確に切断されました。
そこで再び enひかりへ電話したところ、調査の結果、私の回線には 2 台の機器が見えていると言われました。考えてみると、おそらく HGW と YAMAHA が衝突したのだと思います。HGW には一度も電源を入れていないにもかかわらずです。
本来 NTT 局側からの設定は HGW に配信されるはずだったのに、HGW は待っても現れず、代わりに YAMAHA の認証が来た。するとネットワーク異常と判断され、IPv6 の IP が回収されたのではないか、という流れです（ここでいう回収とは v6プラスの IP が回収され、閉域網、つまり NGN の IP に戻ることを指します）。

その時は本当に腹が立ちました。HGW の契約を強制したのも enひかりなのに、その結果としてこの問題が起きたわけです。その場で HGW 契約を解約したいと伝えたところ、今回はようやく解約できることになりました。

もちろん、奇跡ってのはタダじゃないんだ。HGW 契約を解約するには、追加のネットワーク切替費用が必要でした。内訳はおそらく 2,310 円（v6プラス再割当費用？）+ 2,200 円（固定 IP 再発行費用）です。
これを聞いたときは怒りを通り越して笑ってしまいました。最初に HGW 契約を強制してきたのに、最後にこんな面倒が起きて、その後始末の費用までこちらが負担することになるとは。

とはいえ最大の悪役はやはり NTT です。この仕組み、だいぶ闇が深いです。設定を配信できなかったら回収する、というのは一体どういう挙動なのでしょうか。
HGW 契約が必須だと言われた件も、おそらく NTT 側の標準フロー上の要求で、enひかりは単に文書通りに運用していただけなのだと思います = =

開通 3 日目

HGW 契約の解約を依頼した日の夕方、17 時頃に enひかりのスタッフから電話があり、手続きが間に合わないと言われました。そのため、3 日目の 11 時過ぎにようやくネットが復旧しました。

解約後はすべて正常に動いています。少なくとも、この記事を書いている 2026 年 6 月 9 日時点では問題ありません。

タイムライン参考

6 月 3 日 午前 3 時
↓
v6プラスが正常に開通
OpenWrt も正常に利用可能
↓
16 時頃
NVR500 の設定が完了し、動作開始
↓
21 時頃
v6プラスが回収される
↓
6 月 4 日 11 時
電話後、v6プラスが再付与される
↓
6 月 4 日 13 時
v6プラスが回収される
↓
6 月 4 日 15 時
電話で状況確認 + HGW 解約
↓
6 月 5 日 11 時
HGW 解約後、正常復旧

まとめ

異常経路はおそらく以下のようなものだったのではないかと思います。

局側が HGW への設定配信を待つ
↓
HGW は一度も通電していないのに、NVR500 が現れる
↓
局側の設定がすべて撤回される

そのため、CROSS + ひかり電話を契約する場合は、HGW を契約せず、自前の YAMAHA NVR を使うと最初から伝えることをおすすめします。何があっても HGW は契約しない方がいいです。そうしないと、NTT から二回も財布を殴られることになります。

終
制作・著作
━━━━━
ⒽⓊⒼⒼⓎ

关于 HGW 以及光电话组合的鬼故事

Tue, 09 Jun 2026 23:00:00 +0900

开篇废话

在日本的话但凡稍微摸一点网络的情况下，HGW（Home Gateway）这个东西依然是绕不过去的话题。
当然，HGW虽然很难绕过去，但是我们是可以扔角落吃灰的，
大概？

于是鬼故事就出现了

正文

在这之前

大概要讲一下契约的情况了：
我在 enhikari 契约了 flets CROSS v6plus 以及光电话业务。
结果 enhikari 的 staff 在电话一定要求我契约 HGW 才可以继续走流程，即使我说了我自带 YAMAHA NVR （可以使用光电话的路由器），
也还是不行（连续电话打过来再三确认），说是雅马哈那个路由器只支持 1Gbps ，所以我用不了我最后说不过 en 客服还是忍痛以 220JPY/M 的价格契约了 HGW

架构

当然 HGW 这弱智玩意送到家后肯定是直接扔角落吃灰的，于是网络架构是：

ONU -> OpenWrt(IPoE) -> YAMAHA NVR500(光电话)

这样的架构，实际上架构为：

ONU->SWITCH(vlan=100)

vlan=100 -> ONU | OpenWrt | NVR500

开通当天

然后开通也是鬼故事，本来计划6月2日开通，结果说2号人也很多，结果3变成3号了，然后大概凌晨三点左右有网 = =

然后当天晚上21点左右就又断网了，当时还在外面吃王将，回家检查发现 IPv6 的地址从 v6plus（运营商的地址）变回 NGN（NTT大内网）的地址了。

开通第二天

于是猜测可能是局端手滑切错了，第二天打电话给 enhikari ，大概早上 10 点打的。
然后电话说下午预计有网，实际上打完电话后半小时就有了。

然后到了 13 点整，又准时断网了。
于是我就又打电话给 enhikari ，结果调查了一下说我网络有两个设备，想了下大概是 HGW 和雅马哈冲突了，即使 HGW 从来都没通过电。
本来 NTT 局端下发配置的话应该下给 HGW ，结果 HGW 没等到却来了雅马哈的认证 = = 于是就认为网络异常结果收回了 IPv6 的 IP （这里收回指的的 v6plus 的 IP ，收回后变回局域网，也就是 NGN 的 IP）

当时真的非常生气，因为强制让我契约 HGW 的也是 enhikari ，结果这就出现了这玩意，我当场说要解除 HGW 的契约，这次终于松口可以解除了。

当然奇迹可不是免费的，解除 HGW 契约需要额外的网络切换费用大概是 2310（v6plus重分配费用？） + 2200 （固定 IP 重发行费用）
特么听到这玩意气笑了，当初强制让我契约 HGW ，最后出现了这挡破事，还要我承担后果。

当然最大的恶人还是 NTT ，这套机制太阴间了，下发不到配置就收回是什么操作？
一定要契约 HGW 这件事，大概率也是 NTT 的标准流程要求，enhikari 估计只是照着文档执行而已。 = =

开通第三天

要求解除 HGW 的契约的下午，大概 17点左右，enhikari 的 staff 打电话说来不及手续了，所以第三天的11点后终于有网了。

解除了后就一切正常了，截止2026年6月9日，也就是我写这篇文章的时候。

时间线参考

6月3日 凌晨3点
↓
v6plus 正常开通
OpenWrt 正常使用
↓
下午4点左右
NVR500 配置完成并开始工作
↓
21点左右
v6plus 被回收
↓
6月4日 11点
打电话后 v6plus 被重新赋予
↓
6月4日 13点
v6plus 被回收
↓
6月4日 15点
打电话了解情况 + 解约HGW
↓
6月5日 11点
解约 HGW 恢复正常

总结

异常路径我猜测是这样的：

局端等待 HGW 下发配置
↓
HGW 从未接电，却等来了 NVR500
↓
局端全部配置被撤销

因此我推荐大家契约 CROSS + 光电话的时候，一定不要契约 HGW 而是说自备 yamaha NVR ，无论如何都不要契约，否则 NTT 层面能爆你两次金币。

完

关于在日本丢东西以及捡到东西几个小故事

Sat, 18 Apr 2026 13:30:00 +0900

开篇废话

在日本也生活了3年左右的时间了，其中免不了丢失和捡到东西的这些生活琐事，在这里记录一下。

关于坊间什么故事好像大家都听腻了，所以我就记录下事件为主吧，也别太吹为神了。

在 NITORI 丢手机

在 2024 还是 25 年，有一次在 NITORI 乱逛的时候应该是蹭了下椅子，然后快到家的时候一摸，好像少了一台手机（我一般出门至少带2台或者以上）。
一开始以为在拉面店丢的，然后找了一圈没看到最后又回到了 NITORI，那台手机是带了 GMS 开了 find my phone 但是没开定位，不过还是响了，在售后？还是仓库的接待处服务台？
响了，于是店员知道我来找手机了，让我输入密码就把手机给我了（当时他们好像说了时间很短所以没扔交番）。

理论上还是有好心人捡到丢前台了，这里表示感谢。

在 Tokyo Metro 丢钱包

在新公司上班没多久，有一次上班一如既往地走得很快，应该小跑了一会，然后钱包就从口袋掉出来了？
在上地铁之前（都下楼到站台了），突然感觉口袋一空，拍了下发现钱包不见了，然后急忙跑回去。
当时还没定期卷，于是我向人工说了下我钱包丢了，想出站到 JR 之类的地方找找，然后人工柜台的员工之间把我拦住，问我描述钱包特征。
总之比划了半天，什么颜色啊，尺寸啊，里面有什么东西吗，然后我说了个我钱包独特的特征。然后印象中好像员工直接两眼放光，然后拿出来了我的钱包。
然后我才意识到原来早就有好心人送过来了，在这跟我确认钱包是不是我的 = =

这次教训还是很惨烈的，于是火速下单 airtags 了，我买了个卡片版的放钱包和银行卡放一起。

在家附近捡到手机

当然一直丢东西，也有我捡到东西的时候。
去朋友家路上，然后一看地面有一台手机，于是我就等了2分钟后直接扔附近交番（简易派出所）了，当然在捡起来之前拍了几张照片，把附近建筑物也拍了下。

在交番我就说捡到了台手机『スマホを拾いました』，然后旁边有个老太一直在夸赞，感觉还有点害羞的。

然后就体验到了流程，捡到手机什么什么的，可以用日语交谈吗什么什么的。
当然问在哪里捡到的就不说了，没有什么意思。

大概了解完时间地点后，警察会用公式化流程的话跟你说明一堆东西（感觉是背下来的那种捧读了）
其中会问你这玩意的处分权，你捡到了这个东西，如果3个月之内没有人认领，你可以拥有这台手机（怎么可能没人认领）
以及会问你是否需要报酬，大概是价值的 30% 还是什么有点忘了，没听清楚属于，我当然是不要。
然后我说如果失主找到了的话可以通知我一下吗，警察就说这个也是要登记信息，稍微会耗一点时间，于是我就懒得了。

于是我稍微明白了点，那么多拾金不昧的其实也有时间成本在里面，
因为你登记的话至少磨蹭个 15 30分钟了属于，不能简化处理，得走正经流程的话。

* 这里判断简化处理是因为我什么都不要的情况下，警察连我驾照都没看。

总之神〇川警察在这方面还是正常的。

在景区丢钱包

在 2026 年的一个普通的周末，在伊豆一直南下公山路旅行，我有个朋友，在伊豆在修善寺附近丢钱包了。
当时的路线是往南西去加油站然后继续一路南下，在圣地巡礼途中下车买冰淇淋发现钱包不见了，这个时候离修善寺已经15公里往外了，车的续航大概大概还有 80KM （考虑到都是山路+开空调，理论上续航50左右）。

于是就有两难的选择，选择直接折返的话，我们也要先去加油。这样的话继续南下将会不可能。
在想了下，我提议先去给交番打电话，说明下钱包丢了，让警察先去登记下。
于是大家用工地日语去给警察拨电话，警察一度问周围有没有能说日语的人，把警察逼到敬语什么的全无了，总之顺利报失了。

这里警察问了2次还是3次还有没有人能开车，描述钱包里面有什么东西的时候说了驾驶证也在里面，这样继续开车的话就是免许不携带了。

过了快半小时来电话了，说找到了，问我们什么时候有到，我们支支吾吾的连目前在哪里都不知道（我对地名还是很下手的，也不知道在哪里），于是开始描述总之意思是到了这个交番要用交番的电话给这个电话打电话，没听清楚一开始警察说了什么词，可能是備え付け？只知道后面警察这么描述回拨电话的流程。

于是全员终于放松了下，大家都知道可以继续南下了。其中过一个红绿灯我意识到好像我们都没放音乐，赶紧安排。

再过了5分钟，警察感觉东西继续放交番应该等不到我们就要下班了，于是把钱包转交给了当地的中心警察署，描述位置的话说对面有麦当劳什么什么的。

于是我们扫除了阴霾，继续南下！

全员都还好，除了我，那一天开了6个小时的山路 = =

找回的过程的话，大概是先跟导航~~パトカー~~跟到警察署。

于是我拿到驾照以来停的最正的一次车就在这里。

大概说明了下来意后，警察就直接拿着一个装钱包的袋子出来了，问是不是。

问了下大概信息后又拿走了，大概是米奇妙妙屋那种，研究下接下来有几个问题，要能回答得上来才能还回来。
推测因为朋友的那个钱包在留卡驾照等能证明身份的都在里面，所以无法简易证明我是我。

其中又问了：

XXX YYY 是谁的卡
YYY XXX 又是谁的卡（名字倒写）
XXX ZZZZ 又是谁的信用卡（朋友他爹）

在好像没有什么话能问后又进去研究确认了下，最后又出来，让摘了下口罩（我朋友花粉症），然后终于有幸当天就找回了钱包。
当然我们表示感谢后来走了，警察也照例说别在丢了哦。

于是打量了下，大家决定把车继续停在警察署，去对面麦当劳吃饭了。

这个麦当劳甚至还有蓝蓝路在，简单合影了下。

然后对于我来说精彩刺激的一天就结束了，接下来就是拿回钱包的朋友开车了。

当然事后朋友也火速下单了个小米的 airtags 放钱包了。

有那么一瞬间其实也挺感慨的，感觉自己多少还是有点摆脱了以前那种一出事就先怪人的思路。
按比较常见的反应，大概率是先责怪一波，只会把事情越搞越乱。

这件事也让我想起以前自己丢东西的时候，国内那种处理方式。

这次反而是我在现场稍微稳住了一下局面，按自己的经验提了点建议，比如也别打 110 了，直接用塑料日语去打附近交番的电话就行（Google Maps 上基本都有写）。
不然的话，大概率就是直接折返，后面的行程也基本全没了。

结尾

以上就是我的3个小故事和1个大故事了。

日本的失物流程其实是“制度 + 人情”的结合，
总之小东西，钱和雨伞的话肯定不用指望找到了。
比较麻烦的东西，贵重物品，钱包在目前日本的社会环境还是很容易能找回的。

当然物价继续涨下去的话什么都不好说了。

总之推荐钱包放个 airtags ！

完

VAIO BIOS 静默更新参数的发现过程 + 一点回忆录

Sun, 15 Mar 2026 15:30:00 +0900

开篇废话

使用前请确认： AC 连接 + 电池有电 Bitlocker off 万一砖了……不关我的事

最近有个单是给笔记本批量重装系统，也就是简单初始化，大部分东西都通过无人值守+奇怪脚本解决了，
但是 BIOS 更新并不会通过 WSUS 来推送没，至少机器到我手上的时候没收到过 BIOS 的更新，不想某个 L / D 开机就给你更 BIOS 了。

所以研究了下 BIOS 更新部分有没有静默安装的参数，凭我的直觉是有的，于是就有这篇文章了。

当然本文太水了，所以有个 #额外部分可以看看，然后笑话我（

命令

首先 VAIO 找到对应的最新 bios 下载包，这个教程里面的是这一款：
https://solutions.vaio.com/6403

创建快捷方式增加 /VPM_NonInteractive 静默参数：

SP000847.exe /VPM_NonInteractive

或者 cmd：

start "" /wait "SP000847.exe" /VPM_NonInteractive

然后如果需要更新的情况下，大概等待个2分钟左右，就会自动重启系统进行 BIOS 自动更新了。

运行起来的话是只有 UAC 窗口的，剩下的都是静默状态，如果是直接打开 exe 的话需要点2-3个弹窗然后 start ，因此很方便进行系统封装后自动执行的命令。最简单的就是放在开始菜单的启动目录，当然 UAC 的问题需要手动点确认，所以可以考虑放在 oobe 进桌面时执行？具体我没研究了。

然后我反查了下文章，感觉 VAIO 提供的很多驱动包都可以使用这个命令 https://solutions.vaio.com/5335/ モジュールを任意の場所に置き、コマンドにてモジュールのある場所にカレントディレクトリを移動し、ファイル名の後に[/vpm_noninteractive]の引数をつけて実行してください。

正文

当然这个要讲一下怎么找到的静默参数了，全网是没有任何这个参数的介绍的，当然主要是 VAIO 只在日本有，其解决方案基本上也是私密的（猜测）
本来想拆包然后找到 bios 直接更新的，但是 7-zip / winrar 没有什么想法，然后跑了 binwalk 也没有看到藏了什么文件：

❯ binwalk SP000847.exe 

 /Users/h/Downloads/SP000847.exe
--------------------------------------------------------------------------------
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
2845781 0x2B6C55 Windows 
 PE 
 binary, 
 machine 
 type: 
 Intel 
 x86-64
--------------------------------------------------------------------------------

Analyzed 1 file for 85 file signatures (187 magic patterns) in 102.0 milliseconds

于是就 g 了，接下来我直接把文件塞到了 Ghidra ，众所周知，Windows PE 的程序的启动参数基本是 / 开头的，于是一眼就看到了非常像的参数了：

看上去就一个 /VPM_NonInteractive 是可以接受传入的，看上去名字也很像静默执行的感觉（NonInteractive）。
所以我就直接执行了，然后过几分钟 pc 就重启进行一个更新 BIOS 操作了，除了 UAC 以外没有任何需要交互的操作。

附上伪代码：


/* WARNING: Function: __security_check_cookie replaced with injection: security_check_cookie */

bool FUN_1400059d0(longlong param_1,longlong *param_2)

{
 int *piVar1;
 wchar_t *pwVar2;
 wchar_t *pwVar3;
 wchar_t wVar4;
 uint uVar5;
 longlong *plVar6;
 longlong lVar7;
 size_t sVar8;
 size_t sVar9;
 ulonglong uVar10;
 wchar_t *pwVar11;
 uint uVar12;
 int iVar13;
 ulonglong uVar14;
 bool bVar15;
 undefined1 auStack_308 [32];
 undefined4 local_2e8;
 undefined8 local_2e0;
 wchar_t *local_2d8;
 longlong local_2d0;
 longlong local_2c8;
 longlong local_2c0;
 undefined1 local_2b8 [64];
 undefined8 local_278;
 ulonglong local_48;
 ulonglong local_38;
 
 local_38 = DAT_14027f930 ^ (ulonglong)auStack_308;
 uVar10 = 0;
 local_2c8 = param_1;
 plVar6 = (longlong *)FUN_140022698();
 if (plVar6 == (longlong *)0x0) {
 /* WARNING: Subroutine does not return */
 FUN_140004cc0(0x80004005);
 }
 lVar7 = (**(code **)(*plVar6 + 0x18))(plVar6);
 pwVar11 = (wchar_t *)(lVar7 + 0x18);
 uVar12 = 0xffffffff;
 uVar14 = uVar10;
 local_2d8 = pwVar11;
 do {
 lVar7 = *param_2;
 pwVar2 = (wchar_t *)(lVar7 + uVar14 * 2);
 pwVar3 = (wchar_t *)(lVar7 + (longlong)*(int *)(lVar7 + -0x10) * 2);
 if (pwVar2 < pwVar3) {
 sVar8 = wcsspn(pwVar2,L" ");
 if (pwVar3 <= pwVar2 + (int)sVar8) goto LAB_140005aa4;
 sVar9 = wcscspn(pwVar2 + (int)sVar8,L" ");
 iVar13 = (int)sVar8 + (int)uVar14;
 FUN_140006480(param_2,&local_2d0,iVar13,sVar9 & 0xffffffff);
 uVar5 = iVar13 + 1 + (int)sVar9;
 }
 else {
LAB_140005aa4:
 if ((*(longlong **)(*param_2 + -0x18) == (longlong *)0x0) ||
 (plVar6 = (longlong *)(**(code **)(**(longlong **)(*param_2 + -0x18) + 0x20))(),
 plVar6 == (longlong *)0x0)) {
 plVar6 = (longlong *)FUN_140022698();
 plVar6 = (longlong *)(**(code **)(*plVar6 + 0x20))(plVar6);
 if (plVar6 == (longlong *)0x0) {
 /* WARNING: Subroutine does not return */
 FUN_140004cc0(0x80004005);
 }
 }
 local_2d0 = (**(code **)(*plVar6 + 0x18))();
 local_2d0 = local_2d0 + 0x18;
 uVar5 = uVar12;
 }
 lVar7 = local_2d0;
 uVar14 = (ulonglong)uVar5;
 pwVar2 = pwVar11 + -0xc;
 if ((wchar_t *)(local_2d0 + -0x18) != pwVar2) {
 if ((*(int *)(pwVar11 + -4) < 0) || (*(longlong *)(local_2d0 + -0x18) != *(longlong *)pwVar2))
 {
 FUN_140004ce0(&local_2d8,local_2d0,*(undefined4 *)(local_2d0 + -0x10));
 pwVar11 = local_2d8;
 }
 else {
 lVar7 = FUN_140004630();
 LOCK();
 pwVar11 = pwVar11 + -4;
 iVar13 = *(int *)pwVar11;
 *(int *)pwVar11 = *(int *)pwVar11 + -1;
 UNLOCK();
 if (iVar13 < 2) {
 (**(code **)(**(longlong **)pwVar2 + 8))(*(longlong **)pwVar2,pwVar2);
 }
 local_2d8 = (wchar_t *)(lVar7 + 0x18);
 pwVar11 = local_2d8;
 lVar7 = local_2d0;
 }
 }
 wVar4 = *pwVar11;
 LOCK();
 piVar1 = (int *)(lVar7 + -8);
 iVar13 = *piVar1;
 *piVar1 = *piVar1 + -1;
 UNLOCK();
 if (iVar13 < 2) {
 (**(code **)(**(longlong **)(lVar7 + -0x18) + 8))();
 }
 if (wVar4 == L'\0') {
 bVar15 = false;
 pwVar11 = local_2d8;
 goto LAB_140005cb8;
 }
 FUN_140005f80(&local_2d8);
 pwVar11 = local_2d8;
 iVar13 = FID_conflict:_wcsicoll(local_2d8,L"/VPM_NonInteractive");
 if (iVar13 == 0) {
 if ((-1 < *(int *)(*param_2 + -0x10)) &&
 (lVar7 = FUN_1401bb6b4(*param_2,L"/VPM_NonInteractive"), lVar7 != 0)) {
 uVar12 = (uint)(lVar7 - *param_2 >> 1);
 }
 FUN_140006370(param_2,uVar12,0x13);
 FUN_1400155a0(local_2b8);
 local_2c0 = FUN_1401b7e10(0xb8,&PTR_14023bdc0);
 if (local_2c0 != 0) {
 uVar10 = FUN_140007aa0(local_2c0,local_278);
 }
 local_48 = uVar10;
 if (uVar10 != 0) {
 local_2e0 = 0;
 local_2e8 = 4;
 lVar7 = FUN_1400292d4(FUN_140012910,uVar10,0,0);
 *(longlong *)(uVar10 + 0x60) = lVar7;
 if (lVar7 != 0) {
 *(undefined4 *)(lVar7 + 0x50) = 0;
 ResumeThread(*(HANDLE *)(*(longlong *)(uVar10 + 0x60) + 0x58));
 }
 }
 lVar7 = local_2c8;
 iVar13 = *(int *)(local_2c8 + 0x1b4);
 while (iVar13 == 0) {
 Sleep(2000);
 iVar13 = *(int *)(lVar7 + 0x1b4);
 }
 iVar13 = *(int *)(lVar7 + 0x1b0);
 FUN_1400056a0(local_2b8);
 bVar15 = iVar13 == 0;
LAB_140005cb8:
 LOCK();
 pwVar2 = pwVar11 + -4;
 iVar13 = *(int *)pwVar2;
 *(int *)pwVar2 = *(int *)pwVar2 + -1;
 UNLOCK();
 if (iVar13 < 2) {
 (**(code **)(**(longlong **)(pwVar11 + -0xc) + 8))();
 }
 return bVar15;
 }
 if ((int)uVar5 < 0) {
 /* WARNING: Subroutine does not return */
 FUN_140004cc0(0x80070057);
 }
 } while( true );
}

额外

其实这次接的单最后是以我离开现场、系统全部重做为结局。对同事以及因此被拖延的工期还是挺抱歉的。

先介绍简单背景：
对面公司拿出了好几页的纸质的手顺让我们全部手工安装，于是总结了下步骤写成了 batch 简化下实际操作，~~想着偷下懒，也顺便给同事减轻一点负担~~。

到了第二阶段，有些软件安装不太顺利。我稍微调查了一下，判断是软件自身的问题，只要放在那里等自动更新即可解决。
但是客户完全不理睬我的意见以及解释，我当时又有点 KY（空気読めない）地多提醒了几次，甚至软件厂商的 KB 都给客户看了，提示的度，也就是 KY 程度对于我来说还是很难掌控的，然后可能在其他方面总之应该是认为我在顶嘴，违反流程还是什么的，让客户感觉到了不安。
最后在客户又在演示重装那个有问题的软件，但是还是失败了2次后，我再次提示了下，然后过了一会让我马上滚蛋了，说我不按照 manual 来操作。

后面的事情就更戏剧化了，有个同事把我们用批处理跑的事暴露了，于是我罪上加罪，很自然地就成了这个项目延期的主要责任人。
不过让我滚了也好，把火力矛头都对向我了后，那么对剩下在现场的同事大概就会温柔许多了。

当然还是我的问题。如果一开始就老老实实按照文档操作，大概也不会出什么问题，何必多此一举呢。只是出于一点技术上的追求，还是不自觉地偏离了客户要求的轨道。

现在回想起来，当客户都能给出 N 页流程纸让我们手填了，其实就已经说明这不会是一个轻松的项目。不过公司第一次接这种活也没有经验，按照业界最低价格就接了。
实际上我本身也不太擅长和这种客户沟通。事情很多、细节很多，如果多确认点的话一天又过去了。
但甲方终究是甲方，甚至有些有歧义的问题我都是通过同事帮忙发邮件去确认的。

而且说实话，在我看来那 N 页流程纸本身几乎没有什么实质性的指导意义。
写了那么多步骤，却连最基本的系统母盘用什么 iso 都没有说明。
严格来说，我甚至可以装一个 Windows 21H2，让大家怀旧一下，也依然完全符合这份流程。

当然，对我来说这次算是一个很深刻的教训。对于这种流程驱动、事件主导的公司来说，一旦已经形成了非常详细而僵化的操作流程，那么效率往往就不是优先考虑的事情。
而这种环境，大概也确实不太适合我这种习惯优先考虑效率的人。

毕竟也正是因为流程已经固化到这种程度，这样简单的 PC 初始化工作才会被外包出来。在很多公司内部，这类事情其实很容易消化。通过无人值守部署（稍微查一下微软文档就能生成的 unattend.xml 和组策略），一个人同时处理几十台机器并不是什么困难的事情。如果机器数量再多一点，甚至可以直接使用 PXE 网络安装方案。

而在这里，却是由明显不太理解部署流程的人写出一份手顺，再让技术人员逐条执行。
对我来说，这种体验多少有些奇怪。

直到让我滚蛋，我才意识到这种模式下，其实对于操作者来说，我是没有任何裁量权的。或者再简单点说，就是我无脑执行，出错了就应该直接推锅，而不是在这里研究解决方案去顶嘴。
本质上，这其实是技术逻辑和流程需求之间的冲突。当一个明显缺乏技术意义的流程被要求逐条执行时，对技术人员来说多少会有一种违背专业判断的感觉，说得再简单点就是被侮辱了。

总之还是很忧愁的，因为我的技术能力在这次案件里面如果这样就完全派不上用场了，对双方都不友好，对面只是要求听话的稍微会点电脑的打工仔而已，我这么上心干什么。

说了那么多，感觉最优解就是尽量不要再接这种技术含量接近 0、又完全事件驱动型的项目。

期间最离谱的是找了个借口说我在系统里面放了特制的病毒，这个病毒不会让系统无法启动，而是会专门破坏用来安装系统的 U 盘，据说已经坏掉了好几块。

把本来还在郁闷着的我整乐了，大家都是个技术者，破坏u盘在说什么天方夜谭吗。

找个好点的理由或者没有理由直接来要我也会给的啊！
不过借着这个理由，对方顺便把我的初始化部署脚本就这样要了过去。

没想到在 2026 年还能碰到这种级别的阴谋论式的 PUA，一边甩锅，一边顺手把脚本拿走。

* 我还是想学下隔空毁坏u盘的技术，毕竟在我的认知里面只有希沃白板的断头台才能做到物理毁坏U盘：

不过再想想也释然了，客户在 Google maps 的风评其实是很微妙的，也符合目前接触的画风，
如果不用这种流程驱动型的文件来维护权威，那么这种会社无法存活下去。

最后，在我心目中夢グループ在我心中的地位还在上升，原来石田社长已经非常善良了。

总结

大家都是程序员，很多习惯其实都是共通的。为了方便调试或部署，一些隐藏参数被嵌入程序里其实是很常见的，也算是约定俗成的做法。
不过很多时候这些参数并不会在文档或其他地方标明，但通常还是可以通过反编译等手段把它们找出来。
~~（当然本文其实没有做到这一步，只是通过简单的字符串匹配就找到了静默运行的参数）。~~

想起了我博客的第一篇文章了~~（Hello World 是不算的）~~：
在 macOS 10.15 以上刷入 IPCC 文件 / On macOS 10.15 or later enable carrier-testing
博客的起点 = = 扒程序的隐藏逻辑，怀念高中的时候了。

完

VAIO BIOSのサイレント更新パラメータ発見記 + ちょっとした回想

Sun, 15 Mar 2026 15:30:00 +0900

はじめに

この記事は中国語からの翻訳です。不自然な点がありましたらご容赦ください。

原記事（中国語）

実行前の確認： AC接続 + バッテリー残量あり BitLocker off もし文鎮化しても……自己責任を

最近、ノートPCを大量に再インストールする案件があり、要は初期化作業です。大半は無人応答＋謎スクリプトで片付いたのですが、
BIOS 更新は WSUS 経由で配信されない（少なくとも私の手元に来た時点では一度も降ってこなかった）ので、
ある日突然 L / D の電源投入で勝手に BIOS が更新されるのは避けたい、という話になりました。

そこで BIOS 更新にサイレントインストールのパラメータがないか調べました。直感的にはあるはずと思ったので、この記事を書きました。

……とはいえ本文が薄いので、追加セクションも用意しました。笑ってやってください（

コマンド

まず VAIO の公式サイトから対象機種の最新 BIOS をダウンロードします。
このチュートリアルで使っているのはこれです：
https://solutions.vaio.com/6403

ショートカットを作成して /VPM_NonInteractive のサイレントパラメータを追加：

SP000847.exe /VPM_NonInteractive

または cmd から：

start "" /wait "SP000847.exe" /VPM_NonInteractive

更新が必要な場合、2分ほど待つと自動で再起動して BIOS の自動更新が始まります。

実行中に出るのは UAC のダイアログだけで、他はすべてサイレントです。
EXE を直接起動すると 2〜3 回ポップアップをクリックして Start する必要があるので、
システムイメージ化後の自動実行にはこちらの方が便利です。
一番簡単なのはスタートアップに入れる方法ですが、UAC の確認は手動になるので、
OOBE でデスクトップに入ったタイミングで実行するなども考えられます（詳細は未検証）。

その後この記事を見直したところ、VAIO の多くのドライバーパッケージでもこのコマンドが使えるようです https://solutions.vaio.com/5335/
モジュールを任意の場所に置き、コマンドにてモジュールのある場所にカレントディレクトリを移動し、ファイル名の後に[/vpm_noninteractive]の引数をつけて実行してください。

本文

このサイレントパラメータの見つけ方を少し説明します。
ネット上にはこのパラメータの情報が全くなく、VAIO は日本専売なので、
サポート情報も基本的にクローズド（という推測）です。

最初はパッケージを分解して BIOS を直に更新できないかと考えましたが、
7-zip / winrar は反応なし、binwalk を使っても何も出てきませんでした：

❯ binwalk SP000847.exe 

 /Users/h/Downloads/SP000847.exe
--------------------------------------------------------------------------------
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
2845781 0x2B6C55 Windows 
 PE 
 binary, 
 machine 
 type: 
 Intel 
 x86-64
--------------------------------------------------------------------------------

Analyzed 1 file for 85 file signatures (187 magic patterns) in 102.0 milliseconds

そこで諦めて Ghidra に投げ込みました。
Windows PE の起動パラメータは基本的に / から始まるので、
すぐにそれっぽい文字列が見つかりました：

見つかったのは /VPM_NonInteractive だけで、名前的にもサイレント実行（NonInteractive）っぽいですよね。
試しに実行してみたら、数分後に PC が再起動して BIOS 更新が始まり、UAC 以外は何も操作不要でした。

reverse code snippet：


/* WARNING: Function: __security_check_cookie replaced with injection: security_check_cookie */

bool FUN_1400059d0(longlong param_1,longlong *param_2)

{
 int *piVar1;
 wchar_t *pwVar2;
 wchar_t *pwVar3;
 wchar_t wVar4;
 uint uVar5;
 longlong *plVar6;
 longlong lVar7;
 size_t sVar8;
 size_t sVar9;
 ulonglong uVar10;
 wchar_t *pwVar11;
 uint uVar12;
 int iVar13;
 ulonglong uVar14;
 bool bVar15;
 undefined1 auStack_308 [32];
 undefined4 local_2e8;
 undefined8 local_2e0;
 wchar_t *local_2d8;
 longlong local_2d0;
 longlong local_2c8;
 longlong local_2c0;
 undefined1 local_2b8 [64];
 undefined8 local_278;
 ulonglong local_48;
 ulonglong local_38;
 
 local_38 = DAT_14027f930 ^ (ulonglong)auStack_308;
 uVar10 = 0;
 local_2c8 = param_1;
 plVar6 = (longlong *)FUN_140022698();
 if (plVar6 == (longlong *)0x0) {
 /* WARNING: Subroutine does not return */
 FUN_140004cc0(0x80004005);
 }
 lVar7 = (**(code **)(*plVar6 + 0x18))(plVar6);
 pwVar11 = (wchar_t *)(lVar7 + 0x18);
 uVar12 = 0xffffffff;
 uVar14 = uVar10;
 local_2d8 = pwVar11;
 do {
 lVar7 = *param_2;
 pwVar2 = (wchar_t *)(lVar7 + uVar14 * 2);
 pwVar3 = (wchar_t *)(lVar7 + (longlong)*(int *)(lVar7 + -0x10) * 2);
 if (pwVar2 < pwVar3) {
 sVar8 = wcsspn(pwVar2,L" ");
 if (pwVar3 <= pwVar2 + (int)sVar8) goto LAB_140005aa4;
 sVar9 = wcscspn(pwVar2 + (int)sVar8,L" ");
 iVar13 = (int)sVar8 + (int)uVar14;
 FUN_140006480(param_2,&local_2d0,iVar13,sVar9 & 0xffffffff);
 uVar5 = iVar13 + 1 + (int)sVar9;
 }
 else {
LAB_140005aa4:
 if ((*(longlong **)(*param_2 + -0x18) == (longlong *)0x0) ||
 (plVar6 = (longlong *)(**(code **)(**(longlong **)(*param_2 + -0x18) + 0x20))(),
 plVar6 == (longlong *)0x0)) {
 plVar6 = (longlong *)FUN_140022698();
 plVar6 = (longlong *)(**(code **)(*plVar6 + 0x20))(plVar6);
 if (plVar6 == (longlong *)0x0) {
 /* WARNING: Subroutine does not return */
 FUN_140004cc0(0x80004005);
 }
 }
 local_2d0 = (**(code **)(*plVar6 + 0x18))();
 local_2d0 = local_2d0 + 0x18;
 uVar5 = uVar12;
 }
 lVar7 = local_2d0;
 uVar14 = (ulonglong)uVar5;
 pwVar2 = pwVar11 + -0xc;
 if ((wchar_t *)(local_2d0 + -0x18) != pwVar2) {
 if ((*(int *)(pwVar11 + -4) < 0) || (*(longlong *)(local_2d0 + -0x18) != *(longlong *)pwVar2))
 {
 FUN_140004ce0(&local_2d8,local_2d0,*(undefined4 *)(local_2d0 + -0x10));
 pwVar11 = local_2d8;
 }
 else {
 lVar7 = FUN_140004630();
 LOCK();
 pwVar11 = pwVar11 + -4;
 iVar13 = *(int *)pwVar11;
 *(int *)pwVar11 = *(int *)pwVar11 + -1;
 UNLOCK();
 if (iVar13 < 2) {
 (**(code **)(**(longlong **)pwVar2 + 8))(*(longlong **)pwVar2,pwVar2);
 }
 local_2d8 = (wchar_t *)(lVar7 + 0x18);
 pwVar11 = local_2d8;
 lVar7 = local_2d0;
 }
 }
 wVar4 = *pwVar11;
 LOCK();
 piVar1 = (int *)(lVar7 + -8);
 iVar13 = *piVar1;
 *piVar1 = *piVar1 + -1;
 UNLOCK();
 if (iVar13 < 2) {
 (**(code **)(**(longlong **)(lVar7 + -0x18) + 8))();
 }
 if (wVar4 == L'\0') {
 bVar15 = false;
 pwVar11 = local_2d8;
 goto LAB_140005cb8;
 }
 FUN_140005f80(&local_2d8);
 pwVar11 = local_2d8;
 iVar13 = FID_conflict:_wcsicoll(local_2d8,L"/VPM_NonInteractive");
 if (iVar13 == 0) {
 if ((-1 < *(int *)(*param_2 + -0x10)) &&
 (lVar7 = FUN_1401bb6b4(*param_2,L"/VPM_NonInteractive"), lVar7 != 0)) {
 uVar12 = (uint)(lVar7 - *param_2 >> 1);
 }
 FUN_140006370(param_2,uVar12,0x13);
 FUN_1400155a0(local_2b8);
 local_2c0 = FUN_1401b7e10(0xb8,&PTR_14023bdc0);
 if (local_2c0 != 0) {
 uVar10 = FUN_140007aa0(local_2c0,local_278);
 }
 local_48 = uVar10;
 if (uVar10 != 0) {
 local_2e0 = 0;
 local_2e8 = 4;
 lVar7 = FUN_1400292d4(FUN_140012910,uVar10,0,0);
 *(longlong *)(uVar10 + 0x60) = lVar7;
 if (lVar7 != 0) {
 *(undefined4 *)(lVar7 + 0x50) = 0;
 ResumeThread(*(HANDLE *)(*(longlong *)(uVar10 + 0x60) + 0x58));
 }
 }
 lVar7 = local_2c8;
 iVar13 = *(int *)(local_2c8 + 0x1b4);
 while (iVar13 == 0) {
 Sleep(2000);
 iVar13 = *(int *)(lVar7 + 0x1b4);
 }
 iVar13 = *(int *)(lVar7 + 0x1b0);
 FUN_1400056a0(local_2b8);
 bVar15 = iVar13 == 0;
LAB_140005cb8:
 LOCK();
 pwVar2 = pwVar11 + -4;
 iVar13 = *(int *)pwVar2;
 *(int *)pwVar2 = *(int *)pwVar2 + -1;
 UNLOCK();
 if (iVar13 < 2) {
 (**(code **)(**(longlong **)(pwVar11 + -0xc) + 8))();
 }
 return bVar15;
 }
 if ((int)uVar5 < 0) {
 /* WARNING: Subroutine does not return */
 FUN_140004cc0(0x80070057);
 }
 } while( true );
}

追加

実は今回の案件、最後は「私が現場を離れて、全台システム再インストール」で決着しました。
同僚や納期に影響を与えたことは申し訳なく思っています。

簡単な背景説明：
相手企業が数ページ分の紙手順を用意していて、全て手作業でインストールするよう求められました。そこで手順をまとめてバッチを作り、~~ちょっとサボりつつ、同僚の負担も減らそうとした~~ というわけです。

第二フェーズで、いくつかのソフトのインストールがうまくいかず、少し調べたところソフト側の問題で、放置して自動更新を待てば解決できると判断しました。
しかし顧客は私の意見や説明を聞かず、私も当時は KY気味に何度も念押しし、メーカーの KB まで見せました。
注意の度合い、つまり KY の度合いは自分でもコントロールが難しく、結果的に他の面でも反抗的だと思われたのか、
手順違反だと受け取られて不安を与えてしまったようです。

顧客が問題のソフトを再インストールして、2回連続で失敗したタイミングで私がまた一言言ったところ、
しばらくして「今すぐ帰れ」と言われました。マニュアル通りにやっていないのが理由でした。

その後の展開はさらにドラマチックでした。
同僚の一人が、こちらがバッチで作業していたことをバレてしまい、私の罪が上乗せ。
自然な流れで、この案件遅延の主犯になりました。

でも追い出されたのは良かった面もあって、矛先が私に向いたことで、
現場に残った同僚には少し優しくなるだろうと思いました。

結局は私の落ち度です。最初から文書通りにやっていれば問題は起きなかったでしょう。
技術的なこだわりで勝手に軌道を外れてしまったのが原因です。

今振り返ると、顧客が数ページ分の紙手順を書かせる時点で、
楽な案件ではないことは明らかでした。
ただ会社としては初めての種類の案件で、業界最安レベルの価格で受けてしまった。
私はそもそもこういう顧客とのコミュニケーションが得意ではありません。
確認すべきことが多く、細かい確認をしているだけで一日が終わってしまいます。

ただ相手は発注元（クライアント）です。
曖昧な点は同僚に頼んでメールで確認してもらいました。

それに正直、数ページ分の手順書には実質的な指針がほとんどありませんでした。
手順を大量に書いているのに、最も基本的な OS イメージ（ISO）すら指定がないのです。
極端な話、Windows 21H2 を入れても手順上は問題ないことになります。

今回の件は深い教訓になりました。
こういう「プロセスドリブン」「イベント主導」の会社では、
細かく硬直化した手順ができあがると、効率は優先事項ではなくなります。
そしてそういう環境は、効率を優先する私には合わないのだと思います。

だからこそ、こんな単純な PC 初期化作業が外注に出されるのでしょう。
多くの会社では、こういう作業は内部で簡単に消化できます。
無人展開（Microsoft のドキュメントを少し読めば作れる unattend.xml やグループポリシー）を使えば、
一人で数十台を同時に処理するのも難しくありません。
台数がもっと多ければ、PXE のネットワークインストールも使えるでしょう。

しかしこの現場では、明らかに展開手順を理解していない人が手順書を作り、
技術者がそれを一行ずつ実行させられる構図でした。
私にとっては、かなり違和感のある体験でした。

追い出されて初めて気づいたのは、この仕組みではオペレーター側に裁量権がないということです。
もっと簡単に言えば「黙ってやれ、失敗したら責任を取れ」という構図です。
本質的には技術ロジックと手順要求の衝突であり、
技術的に意味の薄い手順を一つずつ守らされると、
専門家としての判断を否定されたような感覚になります。言い換えれば侮辱です。

結局のところ、私の技術が今回の案件では活きず、
双方にとって不幸でした。相手が求めているのは、
「少しだけPCに詳しい従業員」であって、私が本気になる必要はなかったのだと思います。

なので結論としては、
技術要素がほぼゼロで、完全にイベントドリブンな案件は、
できるだけ受けないのが最適解だと感じました。

一番ありえなかったのは、
「私が特殊なウイルスを仕込んだ」と言いがかりをつけられたことです。
そのウイルスはPCを壊すのではなく、OSを入れるためのUSBだけを壊すらしい。
しかも既に何本も壊れた、と。

少しでもPCを知っていれば、どれだけ荒唐無稽な話か分かるはずです。
落ち込んでいたはずが、思わず笑ってしまいました。
技術者同士で「USBだけ壊すウイルス」なんて、さすがにファンタジーすぎませんか。

もっとマシな理由を出すか、理由なしで「スクリプトを見せて」と言ってくれれば、普通に渡したのに。
しかもこの口実で、こちらの初期化デプロイ用スクリプトまで持っていかれました。
2026年にもなって、こんなレベルの陰謀論じみた言いがかりを受けるとは思いませんでした。
責任を押し付けながら、ちゃっかりスクリプトだけ持っていく。

* 私も遠隔でUSBを壊せる技術を学びたい。私の認識だと、物理破壊できる中国教室の黒板ギロチンくらいです：

それでも最後は少し冷静になれました。
顧客の Google Maps 評価はかなり微妙で、今回の体験とも一致します。
こういう「プロセス至上主義」の書類で権威を維持しないと、
この手の会社は生き残れないのだと思います。

最後に、私の中で夢グループの評価はさらに上がりました。
石田社長はとても優しい人だったんだなと。

まとめ

プログラマなら感覚的に分かると思いますが、
デバッグやデプロイを便利にするために隠しパラメータを埋め込むのは割と一般的な手法です。
ただし、こうしたパラメータはドキュメントに書かれていないことが多く、
逆に言えば逆アセンブルなどで掘り出せることも少なくありません。
~~（もちろんこの記事ではそこまでやっていなくて、単純に文字列検索しただけですが）。~~

ふと思い出しました。ブログの第一回記事（Hello World 除く）はこちらでした：
在 macOS 10.15 以上刷入 IPCC 文件 / On macOS 10.15 or later enable carrier-testing
ブログの起点は「プログラムの隠しロジックを剥がす」だったなあと、高校時代を懐かしく思いました。

以上。

終
制作・著作
━━━━━
ⒽⓊⒼⒼⓎ

Unifi 设备在 Official Hosting 的奇怪配对问题

Sun, 15 Mar 2026 13:20:00 +0900

开篇废话

最近一个项目不但用了 Unifi 设备然后还用了 Official Hosting ，这意味着每个月都要给 Unifi 上供，其实感觉意义不明（跑

然后就出了很尴尬的情况，怎么都 adopt 不上。

本文由于可能截图到不能截图的部分，所以全程口述

正文

管理内网一定要能直接管理

当时网络架构大概是这样的： untagged = mgnt tagged = lan / server lan / iot

然后当初是有线连接交换机然后设置第一台 AP 了，对于腰子的保护，在弱电箱旁边的我移动到了正常点的地方，然后使用无线想继续设置。

然后发现设置不来，可以发现设备，但是死活 adopt 不了。最后又回到了弱电箱连接有线，然后成功了。

最后意识到了：AP 连上交换机后，实际上是直接走 untagged mgnt vlan 拿到 ip 了，所以我们 adopt 的时候要和 AP 处于同一个广播域(L2) = =

当然为什么能穿透 vlan 搜索到设备就不得而知了，懒得开电线鲨鱼了。

备用方法

https://help.ui.com/hc/en-us/articles/204909754-Remote-Adoption-Layer-3

当然官方对 Official Hosting 的情况还是有备用的连接方案的。其中一个是弄 DHCP option 43 或者 DNS A `unifi` = controller ip (当然我没试过，有可能是别的记录？)
但是那个破 NEC 路由器弄得我不想再配任何东西，所以当时就没用上。

还有一种是 ssh ui:ui@ip 连进去输入

set-inform http://xxx.unifi-hosting.ui.com:8080/inform

来完成配置。

当然就出现了另外的问题：有些超级低端的沙卵交换机并不支持 ssh ，所以不能这样。

备用的备用方法

后面搜索到了第三方工具来喂给设备 adopt 请求：

https://github.com/HostiFi/hostifi-device-discovery-tool-releases/releases

可以 discover 到设备，点 adopt 然后理论上后台就能见到了。

然而实际上并没有出现，当然我当时施工结束前死马当活马医把所有交换机都点了下，就鞠躬道歉下班了。

超级隐藏区域

众所周知 official hosting 的话，你买 license 是可以切割很多虚拟的区域的，当然我这属于协力会社，没有完整控制器的权限。
于是我在事后复盘的时候在想这玩意会不会藏在一个默认区域放这种顺着 Inform URL 来尝试配对孤儿设备呢？

于是我思来想去让同事查询了下 Default zone，发现我当时用 HostiFi Device Discovery Tool 尝试 adopt 的交换机都出现了，于是我们赶紧 adopt 然后在设置里面把设备移动到正确的区域 (Move To New Site) 就 ok 了。

总结

总之我感觉没事就别碰 Unifi 的 Official Hosting 模式了，给自己找不痛快 = =
另外这些完全没有什么文章来说明，所以我写了一篇。

完

UniFi公式ホスティングでの謎のAdopt問題

Sun, 15 Mar 2026 13:20:00 +0900

はじめに

この記事は中国語からの翻訳です。不自然な点がありましたらご容赦ください。

原記事（中国語）

最近あるプロジェクトで UniFi 機器と Official Hosting を組み合わせて使用しました。毎月 UniFi へ費用を払い続けることになり、正直意義があるのか疑問でしたが（笑）

そして困った状況が発生しました。どうやっても Adopt できないのです。

本記事はスクリーンショットできない箇所があるため、全編テキストのみとなっております。

本文

管理ネットワークには直接アクセスできる環境が必要

当時のネットワーク構成はおおよそ以下の通りでした：

untagged = mgmt
tagged = lan / server lan / iot

最初は有線でスイッチに接続して最初の AP を設定しました。電気ボックスの横でかがみ込む姿勢がつらかったので、少し離れた場所に移動して無線で設定を続けようとしました。

すると、デバイスは発見できるのに Adopt が一切できないという状況に陥りました。結局また電気ボックスに戻り有線で接続したところ、無事に成功しました。

気づいたこと：AP がスイッチに接続すると、untagged の管理 VLAN 経由で IP を取得します。そのため Adopt の際は AP と同じ L2 ブロードキャストドメインにいる必要があります。

なぜ VLAN を超えてデバイスを検索できるのかは謎のままです。Wireshark で調べる気力はありませんでした。

代替方法

https://help.ui.com/hc/en-us/articles/204909754-Remote-Adoption-Layer-3

Official Hosting 向けに、いくつかの代替 Adopt 方法が公式から提供されています。一つは DHCP option 43 の設定、または DNS A レコードで unifi をコントローラーの IP に向ける方法です（試してはいませんが、レコードの種類は違うかもしれません？）。ただ、問題の NEC ルーターに何か設定するのが嫌だったので、この方法は使いませんでした。

もう一つは ui:ui@<ip> で SSH ログインして以下のコマンドを実行する方法です：

set-inform http://xxx.unifi-hosting.ui.com:8080/inform

しかしここでまた別の問題が。低価格帯のスイッチの中には SSH 非対応のものもあり、この方法も使えないケースがありました。

代替の代替方法

デバイスに直接 Adopt リクエストを送れるサードパーティ製ツールを見つけました：

https://github.com/HostiFi/hostifi-device-discovery-tool-releases/releases

デバイスを Discover して Adopt をクリックすれば、理論上は管理画面に表示されるはずです。

実際には表示されませんでした。施工終了前にダメ元で全スイッチにポチポチしてから、頭を下げて退場しました。

超隠しエリア

Official Hosting では、ライセンスを購入すると複数の仮想サイトに分割できます。私は協力会社の立場だったため、コントローラーへの完全なアクセス権がありませんでした。

事後に振り返っていると、ふと思いました。Inform URL 経由で接続を試みた孤立デバイスが、何かデフォルトのサイトに溜まっているのではないかと。

同僚に Default site を確認してもらったところ、HostiFi Device Discovery Tool で Adopt しようとしたスイッチが全て表示されていました。すぐに Adopt して、設定画面から正しいサイトへ移動（Move To New Site）することで解決しました。

まとめ

UniFi の Official Hosting モードはできるだけ使わない方がいいと感じました。面倒なことしか起きません。また、こういった情報はほとんど文書化されていないため、この記事を書きました。

以上。

終
制作・著作
━━━━━
ⒽⓊⒼⒼⓎ

Weird Adoption Issues with UniFi Devices on Official Hosting

Sun, 15 Mar 2026 13:20:00 +0900

Preface

This article is translated from Chinese. Please excuse any unnatural phrasing.

Original article (Chinese)

Recently I worked on a project using both UniFi devices and Official Hosting, which means paying UniFi every month — honestly not sure it’s worth it lol

Then I ran into an embarrassing situation where I just couldn’t get the devices adopted no matter what.

Note: This article contains no screenshots as there were sections I couldn’t capture.

Main Content

The Management Network Must Be Directly Reachable

The network setup at the time was roughly:

untagged = mgmt
tagged = lan / server lan / iot

I had originally set up the first AP via a wired connection to the switch. To spare my back from crouching next to the electrical cabinet, I moved to a more comfortable spot and tried to continue the setup wirelessly.

Then I found I couldn’t get it working — devices were discoverable, but adoption kept failing no matter what. In the end I went back to the electrical cabinet, plugged in wired, and it worked.

The realization: once an AP connects to the switch, it gets its IP via the untagged mgmt VLAN, so when adopting you must be on the same L2 broadcast domain as the AP.

Why device discovery can cross VLANs remains a mystery — too lazy to fire up Wireshark.

Fallback Methods

https://help.ui.com/hc/en-us/articles/204909754-Remote-Adoption-Layer-3

Official Hosting does have some fallback adoption options. One is to set DHCP option 43 or a DNS A record for unifi pointing to the controller IP (I haven’t tried this myself — might be a different record type?). But dealing with that NEC router had worn me out, so I didn’t bother with this approach.

Another option is to SSH in with ui:ui@<ip> and run:

set-inform http://xxx.unifi-hosting.ui.com:8080/inform

Of course, another problem came up: some ultra-budget switches don’t support SSH, so this doesn’t work for those.

Fallback of the Fallback

I found a third-party tool that can push an adopt request directly to the device:

https://github.com/HostiFi/hostifi-device-discovery-tool-releases/releases

You can discover devices, click adopt, and in theory they should show up in the controller.

In practice, nothing appeared. Before wrapping up the job, I tried adopting all the switches as a last-ditch effort, then bowed apologetically and called it a day.

The Hidden Default Site

With Official Hosting, purchasing a license lets you split the controller into multiple virtual sites. Since I was working as a subcontractor, I didn’t have full controller access.

When I reviewed everything afterward, I wondered: could orphaned devices that tried to connect via the Inform URL end up sitting in some default site?

After thinking it over, I had a colleague check the Default site — and sure enough, all the switches I had tried to adopt with the HostiFi Device Discovery Tool were there. We quickly adopted them and moved each device to the correct site (Move To New Site), and that was that.

Conclusion

Honestly, avoid UniFi Official Hosting mode if you can — it’s just asking for trouble. And since there’s basically no documentation about any of this anywhere, here’s my writeup.

That’s all.

End

Mikrotik CRS 3xx 系列交换机 RouterOS 模式下的 vlan 配置

Sun, 01 Mar 2026 18:30:00 +0900

开篇废话

最近有个案件需求大概是这样的，使用 Mikrotik 家的 CRS3xx 交换机进行 vlan 设置，稍微研究了下，和我之前自用的 1XX 配置又不一样了，所以在这里分享下奇奇怪怪的配置办法

CRS1XX 的话参考我去年的文章：我的家里网络配置 - 交换机篇

总所周知 RouterOS 底层就是 Linux ，所以才出现了各个交换机配置不太一样的情况…. 就是这种奇妙情况，然后发现 GPT 不太好使，所以在这里记录下（

本文由于可能截图到不能截图的部分，所以全程口述

正文

别抄错机型了

首先我们看一下是不是这款交换芯片的机器：

[admin@MikroTik] > /interface/ethernet/switch/print 
Columns: NAME, TYPE, L3-HW-OFFLOADING, QOS-HW-OFFLOADING
# NAME TYPE L3-HW-OFFLOADING QOS-HW-OFFLOADING
0 switch1 Marvell-98DX3257 no no 
1 switch2 Atheros-8227 no no 
[admin@MikroTik] >

如果是的话可以放心继续，当然我的型号是：

[admin@MikroTik] > /system/routerboard/print 
 routerboard: yes 
 model: CRS354-48G-4S+2Q+
 revision: r4 
 serial-number: xxx
 firmware-type: qca9531L 
 factory-firmware: 7.18.2 
 current-firmware: 7.18.2 
 upgrade-firmware: 7.21.3 
[admin@MikroTik] >

也可以给个参考。

创建 bridge

这个和 CRS1XX 也差不多，先要有一个软件桥接器，然后把想要沟通的 vlan 都扔进去：

/interface bridge add name=bridge vlan-filtering=yes pvid=1

/interface vlan add interface=bridge name=MGNT vlan-id=888 disabled=no
/interface vlan add interface=bridge name=WAN vlan-id=101 disabled=no
/interface vlan add interface=bridge name=LAN vlan-id=1001 disabled=no

添加 vlan 规则

这里偷懒就只写 101 了，实际配置比较复杂，凑合看

access

ether1 = vlan101 = untag

/interface bridge port add bridge=bridge interface=ether1 pvid=101 frame-types=admit-only-untagged-and-priority-tagged

trunk

/interface bridge port add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged
/interface bridge port add bridge=bridge interface=sfp-sfpplus2 frame-types=admit-only-vlan-tagged
/interface bridge port add bridge=bridge interface=sfp-sfpplus3 frame-types=admit-only-vlan-tagged
/interface bridge port add bridge=bridge interface=sfp-sfpplus4 frame-types=admit-only-vlan-tagged

hybrid

举一反三

pvid=101 frame-types=admit-all

添加 bridge 规则

这里的 tagged 就约等于标准的 Linux 语法了，然后 untagged 可以不用加，会自动根据前面设置的 pvid 设定（我事后研究配置才发现的），当然加了最好

/interface bridge vlan add bridge=bridge vlan-ids=101 tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 untagged=ether1

简单 ACL

当然这玩意可以增加有限的 ACL 规则，研究了下大概是这个套路：
我们先研究下 bridge 走了哪个交换机芯片，当然大概率是 switch1 ether49 是管理口，单独走了个交换机芯片：

[admin@MikroTik]> /interface/ethernet/switch/port/prin
t 
Flags: R - RUNNING
Columns: NAME, SWITCH, L3-HW-OFFLOADING, STORM-RATE
 # NAME SWITCH L3-HW-OFFLOADING STORM-RATE
 0 qsfpplus1-1 switch1 yes 100
...
 8 R sfp-sfpplus1 switch1 yes 100
...
12 R ether1 switch1 yes 100
...
60 R ether49 switch2 yes 100

所以基本上这个套路，所以我们可以对着 switch1 增加 ACL 规则来实现非常浅的4层过滤功能：

/interface/ethernet/switch/rule add switch=switch1 protocol=tcp dst-port=23 new-dst-ports="" comment="ban telnet anywhere"

对的，这里没有什么明显的 drop / reject ，而是把匹配的流量用 new-dst-ports="" 导航不存在的 interface 然后包就被丢弃了。

总结

反正这玩意还是很奇妙的，毕竟用 Linux 的思维管理交换机还是太少见了，这种因为交换机硬件不同而命令不一样的更罕见了。。。

然后别指望这破 CPU 跑三层 NAT：

[admin@MikroTik] > /system/resource/print 
 uptime: 8m56s 
 version: 7.21.3 (stable) 
 build-time: 2026-02-12 13:10:04
 factory-software: 7.16.2 
 free-memory: 75.4MiB 
 total-memory: 128.0MiB 
 cpu: MIPS 24Kc V7.4 
 cpu-count: 1 
 cpu-frequency: 650MHz 
 cpu-load: 100% 
 free-hdd-space: 19.8MiB 
 total-hdd-space: 32.0MiB 
 write-sect-since-reboot: 385 
 write-sect-total: 5750 
 architecture-name: mipsbe 
 board-name: CRS354-48G-4S+2Q+ 
 platform: MikroTik 
[admin@MikroTik] >

完

Mikrotik CRS3xxシリーズスイッチのRouterOSモードでのVLAN設定

Sun, 01 Mar 2026 18:30:00 +0900

はじめに

この記事は中国語からの翻訳です。不自然な点がありましたらご容赦ください。

原記事（中国語）

最近あるプロジェクトで Mikrotik の CRS3xx スイッチを使った VLAN 設定が必要になりました。少し調べてみたところ、自宅で使っている CRS1xx とは設定方法が異なっており、その独特な設定方法をここで共有します。

CRS1xx については以前の記事をご参照ください：自宅ネットワーク構成 - スイッチ編

ご存知の通り RouterOS の内部は Linux ですので、スイッチによって設定方法が異なるという状況が生まれます。 GPT もあまり役に立たなかったので、ここに記録しておきます（

本記事はスクリーンショットできない箇所があるため、全編テキストのみとなっております。

本文

機種を間違えないように

まず、対象のスイッチチップを搭載した機種かどうか確認します：

[admin@MikroTik] > /interface/ethernet/switch/print
Columns: NAME, TYPE, L3-HW-OFFLOADING, QOS-HW-OFFLOADING
# NAME TYPE L3-HW-OFFLOADING QOS-HW-OFFLOADING
0 switch1 Marvell-98DX3257 no no
1 switch2 Atheros-8227 no no
[admin@MikroTik] >

一致していれば問題なく続けられます。参考までに私の機種は：

[admin@MikroTik] > /system/routerboard/print
 routerboard: yes
 model: CRS354-48G-4S+2Q+
 revision: r4
 serial-number: xxx
 firmware-type: qca9531L
 factory-firmware: 7.18.2
 current-firmware: 7.18.2
 upgrade-firmware: 7.21.3
[admin@MikroTik] >

Bridge の作成

CRS1xx と同様に、まずソフトウェアブリッジを作成し、通信させたい VLAN をすべて追加します：

/interface bridge add name=bridge vlan-filtering=yes pvid=1

/interface vlan add interface=bridge name=MGNT vlan-id=888 disabled=no
/interface vlan add interface=bridge name=WAN vlan-id=101 disabled=no
/interface vlan add interface=bridge name=LAN vlan-id=1001 disabled=no

VLAN ルールの追加

ここでは省略して 101 のみ記載しています。実際の設定はより複雑ですが、応用して読んでください

アクセスポート

ether1 = vlan101 = untag

/interface bridge port add bridge=bridge interface=ether1 pvid=101 frame-types=admit-only-untagged-and-priority-tagged

トランクポート

/interface bridge port add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged
/interface bridge port add bridge=bridge interface=sfp-sfpplus2 frame-types=admit-only-vlan-tagged
/interface bridge port add bridge=bridge interface=sfp-sfpplus3 frame-types=admit-only-vlan-tagged
/interface bridge port add bridge=bridge interface=sfp-sfpplus4 frame-types=admit-only-vlan-tagged

ハイブリッドポート

応用すれば自明です：

pvid=101 frame-types=admit-all

Bridge VLAN ルールの追加

ここの tagged は標準的な Linux のブリッジ VLAN 構文とほぼ同じです。untagged は省略可能で、前述の pvid 設定に基づいて自動的に設定されます（設定を見直して初めて気づきました）。とはいえ、明示的に指定しておく方が望ましいです。

/interface bridge vlan add bridge=bridge vlan-ids=101 tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 untagged=ether1

簡易 ACL

このスイッチには限定的な ACL ルール機能もあります。大まかな手順は以下の通りです。

まず bridge がどのスイッチチップを使っているか確認します。ほぼ確実に switch1 です。 ether49 は管理ポートで、別のスイッチチップで動作しています：

[admin@MikroTik]> /interface/ethernet/switch/port/print
Flags: R - RUNNING
Columns: NAME, SWITCH, L3-HW-OFFLOADING, STORM-RATE
 # NAME SWITCH L3-HW-OFFLOADING STORM-RATE
 0 qsfpplus1-1 switch1 yes 100
...
 8 R sfp-sfpplus1 switch1 yes 100
...
12 R ether1 switch1 yes 100
...
60 R ether49 switch2 yes 100

この仕組みを踏まえ、switch1 に対して ACL ルールを追加することで、簡易的なレイヤー4フィルタリングが実現できます：

/interface/ethernet/switch/rule add switch=switch1 protocol=tcp dst-port=23 new-dst-ports="" comment="ban telnet anywhere"

明示的な drop / reject アクションはありません。代わりに、マッチしたトラフィックを new-dst-ports="" で存在しないインターフェースにリダイレクトすることでパケットを破棄します。

まとめ

Linux の思考でスイッチを管理するというのは珍しい体験です。さらにスイッチチップによってコマンドが変わるというのはもっと稀なケースです。

なお、この貧弱な CPU にレイヤー3 NAT を期待しないでください：

[admin@MikroTik] > /system/resource/print
 uptime: 8m56s
 version: 7.21.3 (stable)
 build-time: 2026-02-12 13:10:04
 factory-software: 7.16.2
 free-memory: 75.4MiB
 total-memory: 128.0MiB
 cpu: MIPS 24Kc V7.4
 cpu-count: 1
 cpu-frequency: 650MHz
 cpu-load: 100%
 free-hdd-space: 19.8MiB
 total-hdd-space: 32.0MiB
 write-sect-since-reboot: 385
 write-sect-total: 5750
 architecture-name: mipsbe
 board-name: CRS354-48G-4S+2Q+
 platform: MikroTik
[admin@MikroTik] >

以上。

終
制作・著作
━━━━━
ⒽⓊⒼⒼⓎ

VLAN Configuration on Mikrotik CRS3xx Switches in RouterOS Mode

Sun, 01 Mar 2026 18:30:00 +0900

Preface

This article is translated from Chinese. Please excuse any unnatural phrasing.

Original article (Chinese)

Recently I had a job requirement involving VLAN setup on Mikrotik’s CRS3xx switches. After some research, the configuration turned out to be different from the CRS1xx I use at home, so I’m sharing the quirky setup process here.

For CRS1xx, refer to my earlier article: My Home Network Setup - Switch Edition(Chinese)

As everyone knows, RouterOS is Linux under the hood — which is exactly why the configuration varies between switch models. GPT wasn’t much help here either, so I’m documenting this myself.

Note: This article contains no screenshots as there were sections I couldn’t capture.

Main Content

Make Sure You Have the Right Model

First, check whether your device has this switch chip:

[admin@MikroTik] > /interface/ethernet/switch/print
Columns: NAME, TYPE, L3-HW-OFFLOADING, QOS-HW-OFFLOADING
# NAME TYPE L3-HW-OFFLOADING QOS-HW-OFFLOADING
0 switch1 Marvell-98DX3257 no no
1 switch2 Atheros-8227 no no
[admin@MikroTik] >

If it matches, you’re good to continue. My specific model for reference:

[admin@MikroTik] > /system/routerboard/print
 routerboard: yes
 model: CRS354-48G-4S+2Q+
 revision: r4
 serial-number: xxx
 firmware-type: qca9531L
 factory-firmware: 7.18.2
 current-firmware: 7.18.2
 upgrade-firmware: 7.21.3
[admin@MikroTik] >

Create a Bridge

Similar to CRS1xx — first create a software bridge, then add all the VLANs you want to communicate through:

/interface bridge add name=bridge vlan-filtering=yes pvid=1

/interface vlan add interface=bridge name=MGNT vlan-id=888 disabled=no
/interface vlan add interface=bridge name=WAN vlan-id=101 disabled=no
/interface vlan add interface=bridge name=LAN vlan-id=1001 disabled=no

Add VLAN Rules

I’m only showing VLAN 101 here for brevity — the actual config is more complex, use your imagination

Access

ether1 = vlan101 = untag

/interface bridge port add bridge=bridge interface=ether1 pvid=101 frame-types=admit-only-untagged-and-priority-tagged

Trunk

/interface bridge port add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged
/interface bridge port add bridge=bridge interface=sfp-sfpplus2 frame-types=admit-only-vlan-tagged
/interface bridge port add bridge=bridge interface=sfp-sfpplus3 frame-types=admit-only-vlan-tagged
/interface bridge port add bridge=bridge interface=sfp-sfpplus4 frame-types=admit-only-vlan-tagged

Hybrid

By analogy:

pvid=101 frame-types=admit-all

Add Bridge VLAN Rules

The tagged here is roughly equivalent to standard Linux bridge VLAN syntax. untagged can be omitted — RouterOS will populate it automatically based on the pvid set earlier (I only discovered this while reviewing the config after the fact). That said, it’s better to include it explicitly.

/interface bridge vlan add bridge=bridge vlan-ids=101 tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 untagged=ether1

Basic ACL

The switch also supports a limited set of ACL rules. Here’s roughly how it works.

First, find out which switch chip your bridge is using — most likely switch1. ether49 is the management port and runs on a separate switch chip:

[admin@MikroTik]> /interface/ethernet/switch/port/print
Flags: R - RUNNING
Columns: NAME, SWITCH, L3-HW-OFFLOADING, STORM-RATE
 # NAME SWITCH L3-HW-OFFLOADING STORM-RATE
 0 qsfpplus1-1 switch1 yes 100
...
 8 R sfp-sfpplus1 switch1 yes 100
...
12 R ether1 switch1 yes 100
...
60 R ether49 switch2 yes 100

So the pattern is clear — add ACL rules against switch1 to get basic Layer 4 filtering:

/interface/ethernet/switch/rule add switch=switch1 protocol=tcp dst-port=23 new-dst-ports="" comment="ban telnet anywhere"

Note there’s no explicit drop/reject action. Instead, matched traffic is redirected via new-dst-ports="" to a non-existent interface, causing the packets to be silently discarded.

Conclusion

This is quite a peculiar device. Managing a switch with a Linux mindset is already rare, and it’s even rarer for the commands to differ based on the switch chip hardware.

And don’t expect to run Layer 3 NAT on this CPU:

[admin@MikroTik] > /system/resource/print
 uptime: 8m56s
 version: 7.21.3 (stable)
 build-time: 2026-02-12 13:10:04
 factory-software: 7.16.2
 free-memory: 75.4MiB
 total-memory: 128.0MiB
 cpu: MIPS 24Kc V7.4
 cpu-count: 1
 cpu-frequency: 650MHz
 cpu-load: 100%
 free-hdd-space: 19.8MiB
 total-hdd-space: 32.0MiB
 write-sect-since-reboot: 385
 write-sect-total: 5750
 architecture-name: mipsbe
 board-name: CRS354-48G-4S+2Q+
 platform: MikroTik
[admin@MikroTik] >

That’s all.

End

智能折腾[2] - 给 ESP8266 平台的 RGBW 灯泡刷机

Wed, 11 Feb 2026 16:30:00 +0900

开篇废话

上个月参加了 TLUG Technical Meeting 然后有位演讲者介绍了他的 Home Assistant 然后我也捡起来继续用了。上一篇文章还是在 2020 年，拖更了快6年了草。

本文如标题所示，是给灯泡刷机，当然这个灯泡是 PDD 7元~~凑包邮~~购买的，自称支持 RGBCW ，当然最后测试的话缺少暖色调（看上去大概由彩色灯珠模拟？）

拆开来一看是 ESP8266EX ，不知道哪里来的外贸尾货就是了，叫做 EDSUN ，默认接了涂鸦平台。
我们改成 ESPHOME 平台凑合用用（

老中这种倾销式生产还是太恐怖了，带 ESP8266 的玩具居然10元以内就能买到了

正文

接 TTL

一开始我想用夹子的，但是看上去不让读，或者我的 CH341 光荣牺牲了 = =
最后焊了1H左右：

（后面才意识到很难吃锡的是线的原因

然后主板看上去就是完全的公版方案，我们一眼就知道该连什么：

我推荐 GND 使用左上角 ROM 芯片的 pin ，这样好焊点，然后 IO0 （右下角紫色的那个）需要下拉电位，也就是接地，所以更推荐从 ROM 芯片左上角来接地，这样接两根线没啥问题，当然我觉得你需要万用表确认下（
然后 RX TX 3v3 就不说了。

备份固件

查了下这破玩意 ROM 为 25q80csig 是1M 的：

esptool --port /dev/tty.usbserial-140 read-flash 0x00000 0x100000 backup.img

2M 的话把 0x100000 -> 0x200000 以此类推。

ESPHOME

稍微改了下，反正能用就是了：

esphome:
 name: edsun_bulb

esp8266:
 board: esp01_1m

wifi:
 ssid: "IOT"
 password: "xxxxx"
 ap:
 ssid: "blub"
 password: "111111111"
captive_portal:

logger:
 baud_rate: 0

api:
 encryption:
 # 连接 hass 的话这里自己生成个 key
 key: <111>

ota:
 platform: esphome

safe_mode:

web_server:
 port: 80

output:
 - platform: esp8266_pwm
 id: white
 pin: GPIO4
 frequency: 400 Hz
 - platform: esp8266_pwm
 id: green
 pin: GPIO12
 frequency: 400 Hz
 - platform: esp8266_pwm
 id: blue
 pin: GPIO13
 frequency: 400 Hz
 - platform: esp8266_pwm
 id: red
 pin: GPIO14
 frequency: 400 Hz

light:
 - platform: rgbw
 name: EDSUN Bulb
 red: red
 green: green
 blue: blue
 white: white
 id: thelight
 color_interlock: true
 gamma_correct: 1.0
 restore_mode: RESTORE_DEFAULT_OFF
 effects:
 - random:
 - strobe:
 - flicker:
 alpha: 50% #The percentage that the last color value should affect the light. More or less the “forget-factor” of an exponential moving average. Defaults to 95%.
 intensity: 50% #The intensity of the flickering, basically the maximum amplitude of the random offsets. Defaults to 1.5%.
 - lambda:
 name: Tiny Smooth Rainbow
 update_interval: 1s
 lambda: |-
 static const uint8_t colors[12][3] = {
 {255,105,180},
 {255,0,0},
 {255,127,0},
 {255,255,0},
 {127,255,0},
 {0,255,0},
 {0,255,127},
 {0,255,255},
 {0,127,255},
 {0,0,255},
 {127,0,255},
 {255,0,255}
 };

 static int state = 0;
 auto call = id(thelight).turn_on();
 call.set_transition_length(500);
 call.set_rgb(colors[state][0]/255.0, colors[state][1]/255.0, colors[state][2]/255.0);
 call.perform();

 state++;
 if (state == 12) state = 0;

esphome compile bulb.yaml
ls .esphome/build/edsun_bulb/.pioenvs/edsun_bulb

firmware.bin lib0d3 libda8
firmware.elf lib4d9 libefd
firmware.factory.bin lib6f5 libFrameworkArduino.a
firmware.ota.bin lib760 libFrameworkArduinoVariant.a
FrameworkArduino lib82f src
ld lib96d

我们要刷的是 firmware.factory.bin 接下来 OTA 的话刷 firmware.ota.bin

确认颜色通道

output:
 - platform: esp8266_pwm
 id: test_gpio0
 pin: GPIO0
 frequency: 400 Hz

 - platform: esp8266_pwm
 id: test_gpio2
 pin: GPIO2
 frequency: 400 Hz

 - platform: esp8266_pwm
 id: test_gpio4
 pin: GPIO4
 frequency: 400 Hz

 - platform: esp8266_pwm
 id: test_gpio5
 pin: GPIO5
 frequency: 400 Hz

 - platform: esp8266_pwm
 id: test_gpio12
 pin: GPIO12
 frequency: 400 Hz

 - platform: esp8266_pwm
 id: test_gpio13
 pin: GPIO13
 frequency: 400 Hz

 - platform: esp8266_pwm
 id: test_gpio14
 pin: GPIO14
 frequency: 400 Hz

 - platform: esp8266_pwm
 id: test_gpio15
 pin: GPIO15
 frequency: 400 Hz

 - platform: esp8266_pwm
 id: test_gpio16
 pin: GPIO16
 frequency: 400 Hz


light:
 - platform: monochromatic
 name: "TEST GPIO0"
 output: test_gpio0

 - platform: monochromatic
 name: "TEST GPIO2"
 output: test_gpio2

 - platform: monochromatic
 name: "TEST GPIO4"
 output: test_gpio4

 - platform: monochromatic
 name: "TEST GPIO5"
 output: test_gpio5

 - platform: monochromatic
 name: "TEST GPIO12"
 output: test_gpio12

 - platform: monochromatic
 name: "TEST GPIO13"
 output: test_gpio13

 - platform: monochromatic
 name: "TEST GPIO14"
 output: test_gpio14

 - platform: monochromatic
 name: "TEST GPIO15"
 output: test_gpio15

 - platform: monochromatic
 name: "TEST GPIO16"
 output: test_gpio16

然后到网页里面自己按一下吧 = = 这里不教了，也没截图。

然后实际测了下 GPIO 然后看了下灯珠，理论上就是没有暖色的灯珠的 = = 所以其实就是 RGBW （RED+GREEN+BLUE+WHITE），不过凑合能用就是了。

总结

好久没搞智能家居了，毕竟搞这玩意之前得先有自己的家，很遗憾并没有（

当然刷这玩意的话，其实对于时间成本来说是完全亏本的，但是人还是要找点东西折腾下，对吧？

完

我的2025年回顾

Wed, 11 Feb 2026 16:00:00 +0900

开篇废话

去年总共给自己定了这些目标，除了搬家基本上都实现了：

跳槽 ✅
搬家
旅游 ✅
驾照 ✅

然后就是还活着，可喜可贺
可喜可乐
可口可乐

现实生活

辞职 && 驾照

参考年中总结：
近期现状：离职、反思和驾校

写这一段总结的时候还没有离职的鬼故事2 - 关于上家送假材料给入管的破事这裆破事

只能说前司已经无敌了，让人直接背后一凉，你永远不知道在这种情况下还会帮你申请什么东西，还是远离最好。

当然在中兴日本的半年时间过的还是很快乐的。
同时也学了不少通信相关的知识，解决了很多奇奇怪怪的问题，挺有成就感的。

新工作

目前的工作其实是在推特上找的 ~~当然也是朋友按着我填的简历~~
感觉日语能力实打实提高了很多，符合我目前预期（

不过还是太滑水了，目前为止好像没啥挑战性的项目。
不过居然这辈子能赚到亻壬〇堂的钱，还是没想到的。

不过我自己还是想亲手做点项目或者产品出来，总之先混着也挺好的～

旅游

今年往北去了福岛
往南去了三浦半岛看海
往西去了埼玉野营
~~往西去了山梨的山里测信号~~
往东去了千叶安房看星星
在川崎去了生田绿地。

反正就随便玩玩，精神状态就靠这个稍微恢复了点。

日立公园

居然有人 cos フリーレン（

いわき

这地方最出名的应该是〇〇〇信用金库事件了

福岛

311的时候我还在上小学，然后这里也是个受灾的小学，很难想象当时的洪水高度。
只记得当时大家不知道为什么在抢盐了，当时的我大概日本在哪里都不知道。

当然还有更多废墟照片，不过我感觉这几张就够展示了。

赛博世界

今年没有什么开坑项目，有的话大概是：

luci-app-wolh
- 网络唤醒但是卡片版
HomomiTV
- KonomiTV fork ，反正就是看电视用的

然后 luci-app-fleth 和 @Pixiv_bot 目前还是在随缘维护中。

最后就是早报的频道被杜叔叔炸了，所以2026年开始就不维护了。

AI

今年 AI 的冲击还是很大的，我今年下半年开始订阅了 Claude 之类的，然后就很少写代码了，都是 AI 代劳，我当总指挥家 = =

就连我这种死抠的人都给 AI 充钱了

而且与此同时的是，从这之后我水博客的文章都变得没什么灵感，本来可能要奋战好几天的东西然后再水一下文章，结果 AI 们几句话就给我解决了，那我这还有写文章的必要吗？
当然可能也和上家搞我也有关。

~~当然今年写了个修复 jellyfin 数据库的文章，这类的可以多写点了~~

总之就是简单的问题不值得写文章，难的问题还是解决不了，当然我前几年折腾东西就算失败了也会有废文，这两年就基本上没有了，感觉折腾精神还是不够。

明年目标

少吃点
提升点专注力
做点自己的项目/产品
第二種電気工事
搬家

嘛，总之还是活着先，定那么多目标也没哈用。

还是想做点自己想做的东西！

以上

关于我家的网络配置失误导致路由器收到了错误的 RA 导致 IPv6 路由炸了这件事

Tue, 23 Dec 2025 19:00:02 +0900

开篇废话

这两周家里网络感觉很烂，刷推图片很难加载出来，然后 YouTube 经常降到 360p （

然后朋友来我家也说很卡「哎呀哎呀，你家里的网络实在是太慢了」，当然实际情况是个叠加 debuff，除了本文提到的问题还有大家喜闻乐见的 IP 冲突

告诉我们静态 IP 不要设置到动态 IP 段里面，或者要固化。

总之网络有点小毛病，周末终于有空排查了下（

症状

路由器开机后1分钟内，wan6 就会被挂上奇怪的地址：

LUCI里面：

LAN:
IPv4: 172.21.85.1/27
IPv6: 2409:12:2ac1:1234::1/64
IPv6: fd50:d679:a8e3:c0de::1/64
IPv6: undefined/0

WAN:
IPv6: ::ba32:22ff:fac1:42ad/64
IPv6: 2409:12:2ac1:1234:ba32:22ff:fac1:42ad/64
IPv6-PD: 2409:12:2ac1:1234::/64
IPv6-PD: ::/64

cli 里面：

root@OpenWIT:~# ip -6 r 
default from ::/64 via fe80::ce2d:e0ff:fe4b:c33e dev eth0.101 proto static metric 512 pref medium
(略)
root@OpenWIT:~# ip -6 a
（略）
5: eth0.101@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
 inet6 ::ba32:22ff:fac1:42ad/64 scope global dynamic noprefixroute 
 valid_lft 2591949sec preferred_lft 604749sec
 inet6 2409:12:2ac1:1234:ba32:22ff:fac1:42ad/64 scope global dynamic noprefixroute 
 valid_lft 2591973sec preferred_lft 604773sec
 inet6 fe80::ba32:22ff:fac1:42ad/64 scope link proto kernel_ll 
 valid_lft forever preferred_lft forever

看上去很诡异，已经试过重启大法了，OpenWrt 重启，还有宿主机重启，甚至是当 AP 用的路由器也重启了，还是摆脱不了这个野鸡地址。

按照经验猜不到的话，还是请我们的老朋友，电线鲨鱼了。

排查

我是电线鲨鱼直接连 Proxmox 宿主机的 vmbr0 作为 tcpdump （sshdump）直接连的，排查的重点是 icmp6 包，然后基本上我们看下 RA 就可以了:

icmpv6.type == 134

抓包的同时重启 wan6 口，直到 wan6 显示收到地址之后就可以停止抓包了。总共就几个包：

点了几下发现个比较离谱的包，然后根据 mac 找到真凶了 ———————

~~原来是我上个月配了一半然后弃坑了的交换机在乱发 RA（~~

然后就把配置掀了再说，以后有空再继续折腾了。

后面看了下 RouterOS 这个配置好像是默认就存在的，比较奇妙

总结

总之这是篇简单的网络排障文，有 Wireshark 以及一点网络知识的话，排查起来就挺就简单的。

不过我很好奇的是，另外一台 OpenWrt 22.03 还有几台服务器都没事，为啥就家用区的 OpenWrt 24.10 这样炸了呢？

然后就是 OpenWrt + Mikrotik 两个灵车组合，真是想不炸都难，当然好处是凭本事修。

总之不想折腾了，能用就行了的说。

~~IPv6 是真的复杂，怪不得普及不了~~

完

tsreplace で録画済みテレビ番組を正しくトランスコードする

Tue, 23 Dec 2025 19:00:01 +0900

はじめに

この記事は中国語からの翻訳です。不自然な点がありましたらご容赦ください。

おうちの録画番組が3TBまで膨れ上がってしまったので、何とかしてフリースペースする必要があった。

そこで少し調べてみて、tsreplace を使うことにした。

本文

録画した番組は m2ts 形式で、実際には映像と音声以外にも様々なデータが含まれているが、ffmpeg ではこのコンテナを正しく処理できない。直接 ffmpeg でエンコードすると、番組情報やデータ放送などの領域が失われてしまう。最も重要なのは、KonomiTV が番組を正しく解析できなくなることだ。そのため、tsreplace を使って正しくトランスコードする必要がある:

https://github.com/rigaya/tsreplace

もちろん readme にも書いてあるが、大体の意味は:

そう、実質的には MPEG2 を HEVC に変換して容量を節約するというもので、20Mbps のビットレートを HEVC にすると大体 3-5Mbps になる。

さて、紹介は終わった。特に言うこともない。 readme で推奨されているコマンドを使って、CPU ソフトウェアデコードで実行した:

tsreplace.exe -i <入力tsファイル> -o <出力tsファイル> -e ffmpeg.exe -y -f mpegts -i - -copyts -start_at_zero -vf yadif -an -c:v libx265 -preset medium -crf 23 -g 90 -f mpegts -

もちろん最終的には友人のスーパーコンピュータクラスタで実行した。大体900本の動画(平均30分)で、1日程度でエンコードが完了した。

最後にファイル転送の時間が一番長かった。合計3TBで、アメリカまで転送するのに2日近くかかった。戻ってくる速度は悪くなかったが、実際にはハードディスクの速度上限に達していたはずだ。

2026年7月30日更新：その後、今度はデータ放送をいじり始めた。

映像を小さくした後でも、チャンネルによってはデータ放送がかなりの容量を使っていることに気づいた。最初は --remove-typed ですべて消せばいいと思ったが、web-bml に入れると「データ取得中」のまま。さすがにデータが途中までしかなければ、運がよくても動かないらしい（

そこで、起動に必要なデータは残し、それ以外は14.5分ごとに1分間だけ残す --smart-remove-typed を作った。今のところ web-bml でも正常に開けて、番組によってはさらに30～40%ほど小さくなった。もちろんほとんど0%のチャンネルもあり、差はかなり大きい。

tsreplace -i input.m2ts -o output.m2ts --smart-remove-typed

数百本を手作業で処理するわけにもいかないので、Codex に tsreplace-trim-directory も書かせた。.processing を作ってTSDuckで確認してから元ファイルを置き換え、空き容量不足、録画中、検証失敗の場合は元ファイルに触らない。10Mも減らないファイルは置き換えるのも面倒なので、そのまま残す。結果はTSVに書き、次回は完了済みを飛ばして失敗したものだけ再試行する。

紅白歌合戦のようにデータ放送にも保存する価値がありそうな番組は、番組名を見てtrimしないようにもした。とりあえず、また少しディスク容量を取り戻せた。コードは自分の tsreplace fork に置いてある。

KonomiTV の魔改造

当然、併用するには、私の HonomiTV のロジックをまた変更する必要があった。もちろん claude に任せたが、大まかな方針は明確にしておく必要がある:

まず、再解析ロジックを追加した。
ファイル名は変わらず、再生時間もほぼ変わらず、ファイルサイズだけが変わった場合は、ビデオを新規追加しない(以前のロジックでは修正ではなく新規追加していた)。
それから、速度が遅すぎるので files_only パラメータを追加して、ファイルのエンコード情報のみをチェックし、サムネイル/キーフレームなどの時間のかかる重複操作を再生成しないようにした。
次に、以前のシンボリックリンク(Symlink)の自動検出ロジックを調整した。現在、ファイルがトランスコードされたかどうかを目視で確認するためにシンボリックリンクを使っているが、KonomiTV の以前のロジックでは、自動的に解析して実際のファイルパスでデータベースに登録していた。
最後に、パッシブ判定を設定した。ファイルサイズの差異が20%の場合はパッシブスキャンをトリガーし、サムネイルをリネームする(現在、サムネイルは実際にはファイルハッシュで命名されているが、ファイルが変わるとハッシュも変わってしまう)。

まとめ

AI がなかった時代、このちょっとした機能の修正にどれだけ時間がかかったか想像するのは難しい

以上。

終
制作・著作
━━━━━
ⒽⓊⒼⒼⓎ

使用 tsreplace 来正确转码已经录制的电视

Tue, 23 Dec 2025 19:00:01 +0900

开篇废话

家里的电视节目已经膨胀到3T了，不得不想点办法压缩下了。

于是稍微研究了下，然后使用了 tsreplace

正文

由于我们录制的是 m2ts 格式的电视节目，里面实际上除了视频和音频以外还有很多奇怪的数据在里面，但是 ffmpeg 不能正确处理这层容器，如果直接扔进 ffmpeg 转的话，我们会丢失节目信息以及数据放送等区域，最重要的是 KonomiTV 将会无法正确解析节目，因此我们需要使用 tsreplace 来进行正确转码：

https://github.com/rigaya/tsreplace

当然 readme 也说了，也和我大概意思就是：

总之就是文件里面视频部分使用 mpeg2 转 hevc 来节省空间，20Mbps 的码率弄成 hevc 大概 3-5Mbps 最后的效果是，比如50分钟的节目，从 5G 压到了 1G 左右

好了介绍完了，好像也没啥说的。

我用了 readme 推荐的命令，使用 cpu 软解：

tsreplace.exe -i <入力tsファイル> -o <出力tsファイル> -e ffmpeg.exe -y -f mpegts -i - -copyts -start_at_zero -vf yadif -an -c:v libx265 -preset medium -crf 23 -g 90 -f mpegts -

当然是最后是跑在朋友的超算集群里了，当然批量转码部分你问下 gpt 能给你生成114种办法，这里就懒得贴了，因人而异。
大概 900 个视频（平均30分钟），一天左右压制完了。

最后就是从文件传输的时间最长了，总共3T大概花了快2天才传到美国，传回来速度还不错，然后实际上应该跑到硬盘速度上限了。

2026 年 7 月 30 日更新：后来我又开始折腾数据放送了。

前面虽然已经把视频压小了，但是后来发现有些台的数据放送还是能占掉不少空间。一开始当然想直接用 --remove-typed 全删掉算了，结果丢进 web-bml 就只剩下一直“数据取得中”，看来运气再好也不能指望缺了一半的数据还能跑起来（

所以最后还是搞了个比较折中的 --smart-remove-typed，大概就是启动需要的东西一直留着，其他数据每 14.5 分钟留 1 分钟，剩下的删掉。至少目前拿 web-bml 测了下已经能正常打开，文件有的能再小 30%～40%，当然也有些台几乎是 0%，差距还挺大的。

tsreplace -i input.m2ts -o output.m2ts --smart-remove-typed

当然几百个文件不可能手动一个个跑，于是又顺手让 Codex 写了个 tsreplace-trim-directory。大概就是先生成 .processing，用 TSDuck 检查完再替换原文件，空间不够、文件还在录或者检查失败就不动原文件；省不到 10M 的也懒得替换了。处理结果扔进 TSV，下次再跑会自动跳过已经搞完的，失败的继续重试。

另外红白歌会这种数据放送可能以后还有点纪念价值，所以顺手做了节目名保护，不会给它 trim 掉。总之又抠出来了一点硬盘空间，完整代码还是放在我的 tsreplace fork 里了。

KonomiTV 魔改

当然配合使用的话，我的 HonomiTV 又要改逻辑了，当然是由 Claude Code 代劳的，但是大概思路还是要明朗才能改：

首先就是重新分析增加逻辑，文件名不变，时长几乎不变，然后只是文件大小变了，则不重新生成文件（之前的逻辑是会新增而不是修改），然后我嫌速度太慢了增加了个 files_only 参数，这样只检测文件编码信息而不重新生成缩略图/关键帧等耗时重复的操作，然后是调整之前自动检测软链接（Symlink）的逻辑，因为我目前是用软链接来目视文件是否转码的 = =，但是 KonomiTV 之前的逻辑是会帮你自动解析后以实际文件路径入库，最后安排了被动判定，如果文件大小差异 20% 则触发被动扫描，以及重命名缩略图（目前缩略图实际上是以文件哈希来命名的，文件变了哈希也不对了。）

总结

很难想象没有 AI 的时代这点破功能要改多久（

完