huggy's blog

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日近くかかった。戻ってくる速度は悪くなかったが、実際にはハードディスクの速度上限に達していたはずだ。

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天才传到美国，传回来速度还不错，然后实际上应该跑到硬盘速度上限了。

KonomiTV 魔改

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

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

总结

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

完

Jellyfin 升级 10.11 后的数据库修复

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

开篇废话

之前把 Jellyfin 升级到了 10.11.0 基本上所有的媒体库都炸了，表现为无法找到媒体库的弹窗：

无法找到有效的媒体源来播放。

拖了1个月实在是受不了了，因为我用的音乐软件 finamp 也几乎没法正常用了，专辑里面没有任何 track

所以问了下 Claude Code 然后稍微修复了下。

修修补补继续用= =

正文

当然先给解决方案了，有兴趣的可以滚下去看我的排查的部分。

首先请备份你目前已经烂掉的数据库，
不出意外的话，你的 jellyfin 的数据库文件在：

/var/lib/jellyfin/jellyfin.db

总之停止服务然后备份下：

systemctl stop jellyfin
cd /var/lib/jellyfin/
cp jellyfin.db jellyfin.db.bak

然后我们执行第一阶段的修复 sql：

wget https://blog.huggy.moe/attachment/2025/9/complete_fix.sql
sqlite3 jellyfin.db < complete_fix.sql

然后理论上就可以用了，如果还是一样，后台点一下重新扫描所有媒体库再观察看看。

这个是我的执行日志：

❯ sqlite3 jellyfin.db < complete_fix.sql 
========================================
= Jellyfin Database Repair Script =
========================================

步骤 1/2: 修复 PrimaryVersionId 字段...
  ✓ 已更新 27100 个媒体项目的 PrimaryVersionId

步骤 2/2: 重建 AncestorIds 表...
  检查缺失记录数...
  ✓ 已删除旧的 AncestorIds 记录
  生成新的 AncestorIds 记录...
  ✓ 已插入新的 AncestorIds 记录

========================================
= 修复完成统计 =
========================================
音频项目总数: 23815
PrimaryVersionId 已设置的音频项目: 23815
AncestorIds 表中的音频项目数: 23815
缺失 AncestorIds 的音频项目数: 0

✓ 所有修复已完成！

当然还是不行的话，还有个加强的 sql：

wget https://blog.huggy.moe/attachment/2025/9/2-trigger_rescan.sql
sqlite3 jellyfin.db < 2-trigger_rescan.sql

❯ sqlite3 jellyfin.db < trigger_rescan.sql 
========================================
准备触发重新扫描
========================================
旧专辑数量: 5011
旧音频文件数量: 22180
旧艺术家数量: 4994
========================================
========================================
更新完成统计
========================================
已重置专辑数量: 5011
已重置音频文件数量: 22180
已重置艺术家数量: 4994
========================================
脚本执行完成！
现在可以在 Jellyfin 管理面板中点击 "Scan All Libraries"
建议勾选 "Search for missing metadata" 选项
========================================
ok

理论上就药到病除了。

当然目前理论上只是音乐仓库好了，电视剧的裤好像还是坏的，但是我之前手动重建了，就不管了。

排查

我们浏览器开个 F12 看看为啥出现这个情况：
看得出来，请求了 /Users/xxx/Items/? 的路由的时候出现了问题，返回为空，然后我也有能正常播放的专辑，于是我把样本扔给 claude 分析：

然后实际上一搜，就有别人也遇到了这个情况：

https://github.com/jellyfin/jellyfin/issues/14900 - 播放/混音按钮失败
https://github.com/jellyfin/jellyfin/issues/15299 - 季度文件夹显示空

GitHub 里面的解决方案是如果有备份的话，可以回滚，然后避开10.11.0-10.11.2 版本，从 10.10.7 直接升级到 10.11.3 理论上就没这个问题了：

This issue was fixed in 10.11.3 ( #15446). There was a bug in 10.11.0 → 10.11.2 for users migrating their old DB (10.10.x) to 10.11.x. The ancestor IDs were not migrated. This caused several issues, such as not being able to play or shuffle an album, playlists disappearing, plus other issues.

当然我本地就没备份了，所以只能继续排查了。

claude 最后就帮我确认是 AncestorIds 出现了问题：
~~怎么シャミ子还在追我，只因为我离多摩川很近吗（~~

然后我打完补丁的数据库传进去后，好像还是没啥效果，又问了下，然后 claude 让我强制过期下扫描库：

也就是本文的第二个 sql ，然后就好了。

（当然实际上 claude 排查了快1个小时，做了好几个 sql 都失败了）

总结

嘛，开源破车凭本事修属于。

完

离职的鬼故事2 - 关于上家送假材料给入管的破事

Sun, 07 Dec 2025 17:45:00 +0900

开篇废话

本来以为离职后拿到源泉为止这件事就过去了，结果年末还是给我加强度了。

当然不知道前情的请看上集：

近期现状：离职、反思和驾校

太长不看

个人事业主+没有公司挂靠 = 失业

我离职后差不多2个月的时候，上家用我的名义，签了我的名字给入管发了伪造的「契约机关届出」，在届出书上写我成为了个人事业主，但故意不填挂靠公司信息（等于让入管认为我失业了）。
随后入管发现材料填写很灵车就直接把材料退到我家要我重填了。

收到信后我实在是绷不住了，我收到的除了假材料还顺便附上了我离职后就从来没见到过的职票和保险丧失证明。
稍微懂点的就知道如果入管接受了这份材料，我就在入管心中成为了没有挂靠的个人事业主（等于失业），我这签证还能保得住吗？

至于上家为什么要这么做，实际上公司怎么想的我也不管，反正除了"想让入管炸我签证"之外，我想不出什么其他合理的解释了。

于是就有了这篇 part 2，写了下我收到这材料的过程以及如何写被害申告的过程。

正文

某天晚上

寒冷的晚上我回家看邮箱，结果来了入管的信。
不知道的还以为我拿到永住什么了呢，我只感觉到慌（

总之我不明白入管为啥找我，按着惶恐的心拆开了信发现了里面有退职票和保险丧失证明，然后还看到了：

¿

一开始拿到手我还没看懂，直到朋友又骂我是工地日语水平~~〇糖小猫~~级别的阅读理解我才反应过来我又被上家阴了。

在届出书的 ②B 中，新机关里面是空的，然后贴了张纸条：

B一該当なし
个人事業主になりました。
B 一 无对应事项  
我已经成为个体经营者。

也就意味着我失去了这份工作后，摇身一变变成了个人事业主（可以理解成中国的个体户，交灵活就业或者不交社保的人，当然日本还是要交国民年金的），这很显然不符合人文签证的标准（没有所属机关），我的签证很快就会完蛋。

然后入管就以没有新的届出机关返回了我的材料：

個人事業主の場合でも記入が必要です。  
法人番号欄に「個人」と記入の上、  
機関名称等を記入して下さい。

即使是个体经营者也需要填写。
请在“法人编号”一栏填写“个人”，
并填写机构名称等信息。

思来想去，寄错地址，本来要寄到我家的善意选项也被排除了，如果好心寄到我家的话为何要帮我签名？
然后留的两个电话都是公司的，很明显是不想让入管联系到我，而是联系到公司。

总之最后判断这文件就是纯粹想来搞我而弄的，让我升级成个人事业主目的基本上也只有一个了，入管知道我没工作的话，下次更新签证会直接翻车或者喜提1年。

至于为什么8月交的材料11月份才退回到我家就不知道了，也许内部本身觉得材料很可以，所以冷静了几个月才发还给我，又或者内部流程走一半发现不对被退了，总之感谢入管的审核人员给退回了 = =

¿¿

我在7月1日其实就交了电子届出了，所以这个8月的假材料并理论上不会给我带来任何影响。
但是这玩意的最恐怖的地方是你不知道公司背地里偷偷都给你交了什么材料，所以并不是无视就完事了。

这玩意恐怖之处就是，你甚至都敢伪造给入管的材料了，那么其他地方是不是也伪造了？不管是我的简历也好，或者政府什么助成金什么的，都有可能帮你伪造了从中获利中饱私囊。

然后我又在电子届出系统里面常识再登记了下，发现同样的身份信息是无法再次注册电子届出账号的：

这也就有更恐怖的信息了，会不会是上家帮我注册电子届出账号，然后发现失败了，才改成纸质的方式届出的？如果我当时没有火速注册电子届出系统，是不是我自己都届出不了？

¿¿¿

其实企业测有单独的届出材料的：
https://www.moj.go.jp/isa/content/930002830.pdf

用这份材料的话就不需要伪造我的签名即可把我给撇清关系，所以我最后也只能得出就是故意想害我丢签证的行为了，没有更合理的解释。

¿¿¿¿

然后这假材料其实是直接违法日本刑法了，称为：「（有印）私文書偽造罪」

刑法（明治四十年法律第四十五号）
令和七年七月二十二日 施行
（私文書偽造等）
第百五十九条　行使の目的で、次の各号に掲げるいずれかの行為をした者は、三月以上五年以下の拘禁刑に処する。
一　他人の印章等を使用して権利、義務若しくは事実証明に関する文書等を偽造し、又は偽造した他人の印章等を使用して権利、義務若しくは事実証明に関する文書等を偽造する行為
二　他人の電磁的記録印章等を使用して権利、義務若しくは事実証明に関する電磁的記録文書等を偽造し、又は偽造した他人の電磁的記録印章等を使用して権利、義務若しくは事実証明に関する電磁的記録文書等を偽造する行為
２　他人が押印し若しくは署名した権利、義務若しくは事実証明に関する文書等又は他人が電磁的記録印章等を使用して作成した権利、義務若しくは事実証明に関する電磁的記録文書等を変造した者も、前項と同様とする。
３　前二項に規定するもののほか、権利、義務又は事実証明に関する文書等又は電磁的記録文書等を偽造し、又は変造した者は、一年以下の拘禁刑又は十万円以下の罰金に処する。

刑法（明治四十年法律第四十五号）
令和七年七月二十二日施行

（伪造私文书等）
第159条　以行使为目的，实施下列各项之一行为者，处三个月以上五年以下的拘禁刑。

一　使用他人的印章等伪造与权利、义务或事实证明有关的文书等，或者使用伪造的他人印章等伪造与权利、义务或事实证明有关的文书等的行为。
二　使用他人的电子记录印章等伪造与权利、义务或事实证明有关的电子记录文书等，或者使用伪造的他人电子记录印章等伪造与权利、义务或事实证明有关的电子记录文书等的行为。

2　变造他人盖章或签名的、与权利、义务或事实证明有关的文书等，或变造他人使用电子记录印章等制作的、与权利、义务或事实证明有关的电子记录文书等者，亦同前项处罚。

3　除前两项规定之外，伪造或变造与权利、义务或事实证明有关的文书等或电子记录文书等者，处一年以下拘禁刑或十万日元以下罚金。

虽然实际上看上去很恐怖，但是其实参考了几个实际案例，就算能判刑也是很轻的，当然我没找过有其他公司伪造他人材料给入管而判刑的例子

¿¿¿¿¿

所以我最后还是决定不忍气吞声，还是搞了点材料扔入管了就算结束了。
如果你去升级成刑事案件，你去报警拿被害届再找个律师去炸粪坑的话，你能保证炸不到你？
炸到你了你的损失就更大了，非常不值得。

因此只要像入管解释下，这些文件都作废就好了，然后还不放心的话可以去文件开示。

? (申告書)

总之我结合了华尔街各路圈钱大师（ChatGPT/Grok/Gemini/Claude）的意见后，写了以下申告书：

契約機関に関する届出の偽造被害に関する申告書
令和7年12月4日
東京出入国在留管理局横浜支局
就労・永住審査部門御中

届出人：（氏名）
在留カード番号：（番号）
生年月日：2002年（平成14年）5月19日
電話：（電話番号）
メール：（メールアドレス）
住所：（住所）

私は令和7年6月30日をもって株式会社◎◎利◎「为了保障原公司隐私，这里打码一位汉字」（退職時商号：株式会社◎「为了保障原公司隐私，这里打码一位汉字」達ソフト、法人番号90100〇「为了保障原公司隐私，这里打码一位数字」1122981）、翌7月1日に電子届出システムにて退職届出および新契約機関届出を正しく提出・完了しております。

しかし、令和7年8月12日付で提出された届出書（写し添付）については以下の重大な問題があります：

署名の偽造：③欄の署名は私の筆跡ではありません

虚偽の記載：②B欄に「該当なし・個人事業主になりました」と虚偽記載されています

無断提出・無権代理：⑤欄の提出者は前契約機関（xxx）関係者であり、私は当該提出について一切の同意・委任をしておりません

また、退職時にIT関連企業への就職を禁ずる競業制限誓約書への署名を求められましたが、不当な要求であったため拒否いたしました。その後、前契約機関（xxx）は以下の対応を行いました：

源泉徴収票の遅延：退職から3か月以上経過後の10月にようやく交付

退職証明書類の未交付：「退職票」および「雇用保険資格喪失証明書」について、本件偽造届出書に同封して貴局へ送付するという常軌を逸した対応を行っています（これらの書類は今回の貴局からの返送により初めて私の手元に届きました）

このような前契約機関（xxx）による偽造届出書の提出および退職関連書類の遅延交付により、私の新たな就労先への入社手続に重大な支障が生じるおそれがありました。

つきましては、下記事項についてご対応をお願い申し上げます。

令和7年8月12日付届出書が偽造による不実の届出であることを確認いただき、無効とすること

令和7年7月1日に私が電子届出システムにて提出した正しい届出が適切に反映されていることを確認いただくこと

今後、当該偽造書類が一切受理されないよう記録として残していただくこと

本件は私の在留資格の安定性を脅かす極めて悪質な行為であり、看過できません。
何卒、適切かつ迅速なご対応を賜りますよう、よろしくお願い申し上げます。

添付書類：

偽造届出書の写し（令和7年8月12日付提出、貴局より返送されたもの）

令和7年7月1日電子届出の受理完了画面コピー

前契約機関との源泉徴収票交付遅延に関するメール記録

以上

总之想维权的话综合成本过高，所以还是就这么算了。

结尾

感觉我脾气也还是太好了，被人这么瞪鼻子上眼也还只是给入管发文，没有去报警已经最大仁慈了，当然入管报不报警我就不清楚了。

想到了12月1日有个朋友打工的公司都有人持刀来忘年会要说法了，你这公司这么恶心员工不怕哪天有人线下真实反杀吗？

总之就这样了，碰到这种鬼故事你真要去讨要个说法也是会反溅到你身上一坨，属于100%会被报复，惹不起我还躲不起吗。

当然有空的话还是去找个律师咨询下，看看律师意见如何。

跑了。

I-O DATA HDL2-HA シリーズ NAS の魔改造たび

Thu, 18 Sep 2025 22:30:00 +0900

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

はじめに

I-O DATA HDL2-HA シリーズの🍆がヤフオクでジャンク品として時々出品されているので、数台購入して遊んでみました。

https://www.iodata.jp/product/nas/general/hdl2-ha/index.htm

仕組みは以下の通りです：

root@jp-puniru ~# fastfetch
          ▗▄▄▄       ▗▄▄▄▄    ▄▄▄▖             root@jp-puniru
          ▜███▙       ▜███▙  ▟███▛             --------------
           ▜███▙       ▜███▙▟███▛              OS: NixOS 25.11 (Xantusia) x86_64
            ▜███▙       ▜██████▛               Host: HDL2-HA (0.3.4.20190111)
     ▟█████████████████▙ ▜████▛     ▟▙         Kernel: Linux 6.12.41
    ▟███████████████████▙ ▜███▙    ▟██▙        Uptime: 33 days, 6 hours, 33 mins
           ▄▄▄▄▖           ▜███▙  ▟███▛        Packages: 535 (nix-system)
          ▟███▛             ▜██▛ ▟███▛         Shell: fish 4.0.2
         ▟███▛               ▜▛ ▟███▛          Terminal: /dev/pts/0
▟███████████▛                  ▟██████████▙    CPU: Intel(R) Atom(TM) C3538 (4) @ 2.10 GHz
▜██████████▛                  ▟███████████▛    Memory: 1.49 GiB / 7.63 GiB (20%)
      ▟███▛ ▟▙               ▟███▛             Swap: 302.00 MiB / 3.82 GiB (8%)
     ▟███▛ ▟██▙             ▟███▛              Disk (/): 5.30 GiB / 14.72 GiB (36%) - btrfs
    ▟███▛  ▜███▙           ▝▀▀▀▀               Disk (/mnt/records): 1.52 TiB / 2.73 TiB (56%) - btrfs
    ▜██▛    ▜███▙ ▜██████████████████▛         Local IP (enp5s0f0): 192.168.6.253/24
     ▜▛     ▟████▙ ▜████████████████▛          Locale: en_US.UTF-8
           ▟██████▙       ▜███▙
          ▟███▛▜███▙       ▜███▙
         ▟███▛  ▜███▙       ▜███▙

CPUはまだ10年くらいは戦えそうです。
メモリスロットは2基あり、4GBを2枚挿しています。
ECCメモリに対応しているようですが、ノートPC用のECCメモリなんて見たことありますか？ネットワークカードにはRJ45の10GbEポートが2つ搭載されています。

そして、最も印象的なのは3ベイNASです。
データドライブが2つ、システムドライブが1つ、M2ドライブが1つ搭載されています。
マザーボード内にはUSBポートもあります。

最後、出品者が特に安く売っている場合のパターンは大体こんな感じです（推測）：

廃棄時にハードディスクを全て取り出して別売り、システムディスクも含めて、システムディスクだけで4000〜5000円ほどで売れる
廃棄時にハードディスクを破棄処分するため、システムディスクがない

なので、このようなDIYできるが少し難しいジャンク品を拾えるわけです（

本文

清掃

手に入れたらまず分解して清掃し、CPUグリスの塗り直しは面倒なのでサボりました（

マザーボードをコチタでーーーーーーーーす：（裏面にメモリとM.2のスロットがあります）

グラフィックカード

この機器にはグラフィックカードは搭載されていませんが、PCIE x8のフルハイトスロットがあります。
ただし、グラフィックカードを挿入する際にブラケットがないと斜めに挿さってしまいます（引っかかってしまうため）そのため、マザーボードを取り出してからグラフィックカードを挿入しました（上の図を参照）。
安価なグラフィックカードを挿すことをお勧めします（AkibaJunksなどで購入すれば良いです）

これでグラフィカルな画面に入って、BIOSをいじったりできますが、設定できる項目はほとんどありません。

システムのインストールなども便利になります。
理論上はグラフィックカードがなくてもシステムをインストールできますし、BOOTX64.EFIがあれば起動することができるはずです。

フロントパネルケーブルの取り外し

IODATA以外のOSはフロントパネルが対応するものがないため。フロントパネルディスプレイのケーブルは抜いておきましょう。

LEDライトの制御

To Be Continued

面倒で時間もないので、ステータスランプは点滅しっぱなしにするか、ケーブルを抜いてしまいましょう。

おそらく簡単なGPIOプルダウンでLowにすれば解決するのでしょうが、資料もなく時間もないため諦めました。

温度制御ドライバ

機器の温度制御などはIT8625Eで制御されており、it87-dkmsをインストールする必要があります。 https://github.com/a1wong/it87 または https://github.com/frankcrawford/it87 を使用できます。

これでsensorsにデータが表示されるようになります：

root@jp-puniru ~# sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +62.0°C  (high = +74.0°C, crit = +94.0°C)
Core 2:        +61.0°C  (high = +74.0°C, crit = +94.0°C)
Core 6:        +57.0°C  (high = +74.0°C, crit = +94.0°C)
Core 8:        +58.0°C  (high = +74.0°C, crit = +94.0°C)
Core 12:       +59.0°C  (high = +74.0°C, crit = +94.0°C)

it8620-isa-0830
Adapter: ISA adapter
in0:         732.00 mV (min =  +0.56 V, max =  +1.36 V)
in1:           1.32 V  (min =  +1.28 V, max =  +1.38 V)  ALARM
in2:           2.20 V  (min =  +2.08 V, max =  +2.30 V)
+5V:           4.51 V  (min =  +4.15 V, max =  +4.61 V)
in4:           2.12 V  (min =  +2.08 V, max =  +2.30 V)
in5:           2.05 V  (min =  +0.11 V, max =  +0.41 V)  ALARM
in6:           1.96 V  (min =  +1.57 V, max =  +0.60 V)  ALARM
3VSB:          3.55 V  (min =  +3.43 V, max =  +3.79 V)
Vbat:          3.29 V
fan1:        1196 RPM  (min =   12 RPM)
fan2:           0 RPM  (min =   88 RPM)  ALARM
temp1:        +58.0°C  (low  =  +0.0°C, high = +100.0°C)  sensor = thermal diode
temp2:        +59.0°C  (low  =  +0.0°C, high = +100.0°C)  sensor = thermal diode
temp3:        +43.0°C  (low  =  +0.0°C, high = +100.0°C)  sensor = thermal diode
pwm1:             25%  (freq = 23437 Hz)  MANUAL CONTROL
pwm2:             25%  (freq = 23437 Hz)
pwm4:             64%  (freq = 23437 Hz)
pwm5:             64%  (freq = 23437 Hz)
intrusion0:  OK

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +26.8°C

root@jp-puniru ~#

温度制御については私は面倒くさがりなので、pwmを有効にするだけで終わりました：

echo 1 > /sys/class/hwmon/hwmon0/pwm1_enable

いじりたい方は自分で温度PWMのチュートリアルを探してください（

自動起動

自己責任

このひどいBIOSは自動起動機能を削除しており、BIOSをダンプすると設定が隠されており、デフォルトで有効になっていることが分かりました：

そこでBIOSを改造してみたところ、オプションは表示されるようになりましたが効果がありませんでした：

ここでの考えはずっとBIOSの魔改造で、何人かの友人にも相談しましたが、進展がありませんでした
後で別のアプローチがあることが分かりました（草

最終的に奇妙な方法を使って実現しましたが、いくつかの理由により、
その考え方などを公開することはできません。

もちろんC3000ファミリーのデータシートを参考にできます： https://www.mouser.com/datasheet/2/612/c3000-family-datasheet-1623704.pdf

とにかく g3mgnt をダウンロードして実現できます。理論上、Inside BIOSベースのAtom C3000ファミリー汎用です：

理論上、この機器の自動起動はまだ壊れていますが、CMOSバッテリーが切れるまでは何とか使えるでしょう。
また、マザーボードのバッテリーははんだ付けされているので、はんだごてを持参してください（

wget https://blog.huggy.moe/attachment/2025/g3mgnt && chmod +x g3mgnt
./g3mgnt on
Current: on -> on ✓

誰も見たくないの詳細な出力：

root@jp-puniru ~# ./g3mgnt
G3 Management Tool for IO-DATA HDL2-HA series by huggy
Usage: ./g3mgnt [on/off/mem/status [verbose]]
  ./g3mgnt on             - Enable power resume on AC restore
  ./g3mgnt off            - Disable power resume
  ./g3mgnt mem            - Enable power resume from memory state
  ./g3mgnt status         - Show current power resume status (simple)
  ./g3mgnt status verbose - Show detailed status information
root@jp-puniru ~# ./g3mgnt status verbose
G3 Management Tool for IO-DATA HDL2-HA series by huggy
═══════════════════════════════════════════════════════════
Power Resume Status: on (Power resume enabled, normal boot)

Register Details:
PCI Register (0xa4): 0x00
  - Bit 0 (Power Resume): 0 (enabled) (0=enabled, 1=disabled)
Device Memory (0xfe000018): 0x29c0002c
  - Bit 13 (Memory Mode): 0 (normal) (0=normal, 1=memory)
═══════════════════════════════════════════════════════════
root@jp-puniru ~#。

もちろん、私も魔改装のBIOSを作成して多くの設定を表示しました。
必要な方や復旧が必要な方はメールまたはDMでご連絡ください。
ここでは直接提供しません。

改造BIOSでは主により高い温度上限を設定できますが、他には特に用途がありませんかな：

ただし、この機器は実際にはWoLがデフォルトで有効になっています。

システムインストール

前述の通り、グラフィックカードがない状況でも、実際には他の機器でインストールしてから移せば良いのです。
システムインストール時に EFI = BOOTX64.EFI にしておけば、通常は正常に起動するはずです。
ここではNixOSを入れましたが、問題なく起動しました。

まとめ

主な問題点は停電復旧時の自動起動がないことで、1週間かけてようやく解決しました（

やはりこの機器はマイナーすぎて、資料が全くありません >_< ただのx86機器なのですが、私のようにジャンク品を拾う人もそういないでしょうからね。

最後に、我が家のenひかりの10Gネットワークの工事を待っています！

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

I-O DATA HDL2-HA 系列 NAS 的魔改造之旅

Thu, 18 Sep 2025 22:30:00 +0900

开篇废话

I-O DATA HDL2-HA 系列机器偶尔能在雅虎拍卖（ヤフオク）以捡垃圾的形态拍卖，我就买了几台玩玩。

https://www.iodata.jp/product/nas/general/hdl2-ha/index.htm

大概配置如下：

root@jp-puniru ~# fastfetch
          ▗▄▄▄       ▗▄▄▄▄    ▄▄▄▖             root@jp-puniru
          ▜███▙       ▜███▙  ▟███▛             --------------
           ▜███▙       ▜███▙▟███▛              OS: NixOS 25.11 (Xantusia) x86_64
            ▜███▙       ▜██████▛               Host: HDL2-HA (0.3.4.20190111)
     ▟█████████████████▙ ▜████▛     ▟▙         Kernel: Linux 6.12.41
    ▟███████████████████▙ ▜███▙    ▟██▙        Uptime: 33 days, 6 hours, 33 mins
           ▄▄▄▄▖           ▜███▙  ▟███▛        Packages: 535 (nix-system)
          ▟███▛             ▜██▛ ▟███▛         Shell: fish 4.0.2
         ▟███▛               ▜▛ ▟███▛          Terminal: /dev/pts/0
▟███████████▛                  ▟██████████▙    CPU: Intel(R) Atom(TM) C3538 (4) @ 2.10 GHz
▜██████████▛                  ▟███████████▛    Memory: 1.49 GiB / 7.63 GiB (20%)
      ▟███▛ ▟▙               ▟███▛             Swap: 302.00 MiB / 3.82 GiB (8%)
     ▟███▛ ▟██▙             ▟███▛              Disk (/): 5.30 GiB / 14.72 GiB (36%) - btrfs
    ▟███▛  ▜███▙           ▝▀▀▀▀               Disk (/mnt/records): 1.52 TiB / 2.73 TiB (56%) - btrfs
    ▜██▛    ▜███▙ ▜██████████████████▛         Local IP (enp5s0f0): 192.168.6.253/24
     ▜▛     ▟████▙ ▜████████████████▛          Locale: en_US.UTF-8
           ▟██████▙       ▜███▙
          ▟███▛▜███▙       ▜███▙                                       
         ▟███▛  ▜███▙       ▜███▙

cpu 感觉还能战10年
内存插槽两个，我插了 2*4G
好像可以上 ecc ，但是有谁见过笔记本 ecc 内存条的？
网卡有两个 10G 口，不过是电口。
以及最厉害的三盘位 NAS
2个数据盘1个系统盘1个M2盘，主板内部有 usb 接口

然后卖家如果卖的特别便宜的话基本上套路是这样的（推测）：

淘汰下来硬盘全部拿出来再卖，包括系统盘，光系统盘能卖 4000 - 5000 日元左右
淘汰下来硬盘销毁处理，导致没有系统盘

所以这种有点难 DIY 的垃圾我们能捡漏（

正文

清灰

到手肯定要拆了清灰下，然后散热就懒得再涂了（

附赠一张拆机图：

（背面有内存和 M2 的槽位）

显卡

这玩意是没有显卡的，但是有 PCIE x8 全高 slot ，不过显卡插进去的话没有档板的话很容易插歪（被顶住了）
所以我把主板拆出来插了显卡，可以参考上面的图然后推荐插个亮鸡卡就ok了（akibajunks什么的买个单槽位的就行），

然后我们可以进入图形页面稍微改下 bios 什么的，虽然几乎没有能改的东西。

然后安装系统什么的也方便点，理论上没有显卡也可以装系统，反正 BOOTX64.EFI 在应该就能自动引导。

卸掉前面板排线

我们没有适配所以前面板是什么功能都没有的，所以前面板显示器排线记得扯掉。

控制 LED 灯

To Be Continued

太麻烦了没空搞，让 status 灯继续闪或者把电源排线也扯下来吧。
应该也是简单 GPIO 下拉下电平？什么的就解决了，不过真没资料 + 没时间折腾就放弃了，欢迎分享研究成果。

温控驱动

机器温控什么的是 IT8625E 控制，需要安装 it87-dkms。
使用 https://github.com/a1wong/it87
或者 https://github.com/frankcrawford/it87 即可。然后 sensors 就有数据了：

root@jp-puniru ~# sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +62.0°C  (high = +74.0°C, crit = +94.0°C)
Core 2:        +61.0°C  (high = +74.0°C, crit = +94.0°C)
Core 6:        +57.0°C  (high = +74.0°C, crit = +94.0°C)
Core 8:        +58.0°C  (high = +74.0°C, crit = +94.0°C)
Core 12:       +59.0°C  (high = +74.0°C, crit = +94.0°C)

it8620-isa-0830
Adapter: ISA adapter
in0:         732.00 mV (min =  +0.56 V, max =  +1.36 V)
in1:           1.32 V  (min =  +1.28 V, max =  +1.38 V)  ALARM
in2:           2.20 V  (min =  +2.08 V, max =  +2.30 V)
+5V:           4.51 V  (min =  +4.15 V, max =  +4.61 V)
in4:           2.12 V  (min =  +2.08 V, max =  +2.30 V)
in5:           2.05 V  (min =  +0.11 V, max =  +0.41 V)  ALARM
in6:           1.96 V  (min =  +1.57 V, max =  +0.60 V)  ALARM
3VSB:          3.55 V  (min =  +3.43 V, max =  +3.79 V)
Vbat:          3.29 V  
fan1:        1196 RPM  (min =   12 RPM)
fan2:           0 RPM  (min =   88 RPM)  ALARM
temp1:        +58.0°C  (low  =  +0.0°C, high = +100.0°C)  sensor = thermal diode
temp2:        +59.0°C  (low  =  +0.0°C, high = +100.0°C)  sensor = thermal diode
temp3:        +43.0°C  (low  =  +0.0°C, high = +100.0°C)  sensor = thermal diode
pwm1:             25%  (freq = 23437 Hz)  MANUAL CONTROL
pwm2:             25%  (freq = 23437 Hz)
pwm4:             64%  (freq = 23437 Hz)
pwm5:             64%  (freq = 23437 Hz)
intrusion0:  OK

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +26.8°C  

root@jp-puniru ~#

温控的话我比较懒，开下 pwm 就结束了：

echo 1 > /sys/class/hwmon/hwmon0/pwm1_enable

想折腾的自己找教程配合温度 PWM （

开机自启

自分責任

这坑壁 BIOS 把开机自启给砍掉了，dump bios 发现设置被隐藏并且是默认开启的：

然后尝试 mod bios ，选项是出来了但是不生效：

这里思路一直都是魔改 BIOS 还摇了好几个朋友问问，结果没啥进展（最好讨论到要替换模块什么的）后面发现好像有别的路子可以走（草

最后用了些奇奇怪怪的办法安排上了，由于一些原因不能公开其思路什么的，

当然可以参考 C3000 家族的 datasheet：
https://www.mouser.com/datasheet/2/612/c3000-family-datasheet-1623704.pdf

总之可以下载我的 g3mgnt 来实现，理论上基于 inside bios 的 atom c3000 家族通用：

理论上这玩意的开机自启还是坏的，不过直到CMOS电池电量耗尽之前就凑合用吧，另外主板电池特么是焊接的，自带电烙铁吧（

wget https://blog.huggy.moe/attachment/2025/g3mgnt && chmod +x g3mgnt
./g3mgnt on
Current: on -> on ✓

没人看的文档以及详细输出：

root@jp-puniru ~# ./g3mgnt
G3 Management Tool for IO-DATA HDL2-HA series by huggy
Usage: ./g3mgnt [on/off/mem/status [verbose]]
  ./g3mgnt on             - Enable power resume on AC restore
  ./g3mgnt off            - Disable power resume
  ./g3mgnt mem            - Enable power resume from memory state
  ./g3mgnt status         - Show current power resume status (simple)
  ./g3mgnt status verbose - Show detailed status information
root@jp-puniru ~# ./g3mgnt status verbose
G3 Management Tool for IO-DATA HDL2-HA series by huggy
═══════════════════════════════════════════════════════════
Power Resume Status: on (Power resume enabled, normal boot)

Register Details:
PCI Register (0xa4): 0x00
  - Bit 0 (Power Resume): 0 (enabled) (0=enabled, 1=disabled)
Device Memory (0xfe000018): 0x29c0002c
  - Bit 13 (Memory Mode): 0 (normal) (0=normal, 1=memory)
═══════════════════════════════════════════════════════════
root@jp-puniru ~#。

当然我也魔改了一份 bios 解锁了一堆设置，有需要或者救砖的可以给我发邮件或者给我私聊，这里就不直接提供了。
魔改 BIOS 主要可以设置更高温度墙，其他没啥用：

不过这台机器其实 WoL 默认有，不过我都研究出这么简单的办法了，也就不需要 WoL 启动了对吧（

装系统

正如我前面所说的，没有显卡的情况下其实在别的机器装好就可以了，装系统的时候记得 BL = BOOTX64.EFI 应该都能正常启动。
这里我塞了 NixOS 进去没啥问题启动了。

总结

主要雷点就是没有来电自启，折腾了一星期终于解决了（

还是这机器太小众了，啥资料都没有 >_< 不过就是个 x86 机器，也没几个人会像我一样捡垃圾对吧？

最后等我家的 10G 网开通！

完

huggy's blog

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

はじめに

本文

その前に

構成

開通当日

開通 2 日目

開通 3 日目

タイムライン参考

まとめ

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

开篇废话

正文

在这之前

架构

开通当天

开通第二天

开通第三天

时间线参考

总结

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

开篇废话

在 NITORI 丢手机

在 Tokyo Metro 丢钱包

在家附近捡到手机

在景区丢钱包

结尾

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

开篇废话

命令

正文

额外

总结

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

はじめに

コマンド

本文

追加

まとめ

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

开篇废话

正文

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

备用方法

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

备用的备用方法

超级隐藏区域

总结

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

はじめに

本文

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

代替方法

代替の代替方法

超隠しエリア

まとめ

Weird Adoption Issues with UniFi Devices on Official Hosting

Preface

Main Content

The Management Network Must Be Directly Reachable

Fallback Methods

Fallback of the Fallback

The Hidden Default Site

Conclusion

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

开篇废话

正文

别抄错机型了

创建 bridge

添加 vlan 规则

access

trunk

hybrid

添加 bridge 规则

简单 ACL

总结

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

はじめに

本文

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