如果后续需要备份配置、排查服务或研究设备内部数据，更方便的做法是先通过 FactoryMode 开启一次临时 Telnet，再把 LAN 侧 Telnet 配置写入设备数据库。这样重启后可以使用自己设置的账号密码重新登录。

本文记录一次在 F410GV9 上实际验证成功的配置过程。Telnet 只对局域网开放，WAN 侧开关始终保持关闭。操作修改前建议备份现有配置。

环境与准备

本次设备和网络状态如下：

电脑需要连接到光猫 LAN 侧，并与 192.168.1.1 处于同一网段。可以先确认设备在线，以及 Telnet 尚未开放：

1
2

ping 192.168.1.1
nc -vz 192.168.1.1 23

开启临时 Telnet 使用 zteOnu。准备好 Go 环境后直接使用上游源码即可：

1
2
3

git clone https://github.com/Septrum101/zteOnu.git
cd zteOnu
go test ./...

开启临时 FactoryMode Telnet

F410GV9 的普通 Web 管理位于 80，FactoryMode 接口位于 8080。zteOnu 默认端口就是 8080，下面仍显式写出端口，避免把两个服务混淆。

本机实测可用的 FactoryMode 用户名是 factorymode，密码是 nE%jA@5b。这组凭据来自公开项目 zte_modem_tools 内置的默认候选表，并不是设备独有的密码，也不是 Web 管理账号。不同运营商和固件可能使用其他组合。

执行：

1
2
3
4
5

go run . \
  --ip 192.168.1.1 \
  --port 8080 \
  --user factorymode \
  --pass 'nE%jA@5b'

握手成功时，工具会依次完成 FactoryMode 复位、随机数交换、认证和模式切换，并返回一组临时 Telnet 凭据：

1
2
3
4
5
6
7

step [0] reset factory: ok
step [1] request factory mode: ok
step [2] send sq: ok
step [3] check login auth: ok
step [4] enter factory mode: ok
user: <TEMP_USER>
pass: <TEMP_PASSWORD>

输出中的 <TEMP_USER> 和 <TEMP_PASSWORD> 由设备为本次 FactoryMode 会话动态生成，每次运行都可能不同。这组账号也不是准备写入数据库的持久账号。FactoryMode 可能在数分钟后超时，拿到凭据后应尽快继续。

使用临时账号连接光猫：

1

telnet 192.168.1.1 23

成功后会看到设备型号和 BusyBox shell。先用只读命令确认权限：

1
2

id
uname -a

实测结果为：

1
2

uid=0(root) gid=0(root)
Linux F410GV9 4.1.25 #1 Thu Aug 19 13:16:08 CST 2021 armv7l GNU/Linux

把光猫改成桥接、由主路由拨号当然可以解决 IPv6 前缀分配问题，但 XG-140G-TF 本身的转发性能足够，而主路由是软路由，PPPoE 本身也非常吃单核性能，所以我还是希望保留光猫拨号。进一步检查后发现，XG-140G-TF 的固件中其实包含下游 DHCPv6-PD Server，只是电信配置默认没有开启对应的产品级开关。

本文记录如何在保留光猫拨号的情况下，开启 XG-140G-TF 的 IPv6 PD 前缀分发。光猫的管理员登录、Telnet 开启和 root 密码获取方法，请先参考配置 XG-140G-TF 光猫。

问题现象

光猫的 IPv6 状态显示，WAN 连接已经通过 Prefix Delegation 从电信取得了/60前缀，例如：

1

2001:db8:1234:690::/60

一个/60可以划分为 16 个/64子网。在这个例子中，范围是：

1
2
3
4

2001:db8:1234:690::/64
2001:db8:1234:691::/64
……
2001:db8:1234:69f::/64

光猫使用第一个690::/64作为自己的 LAN 网段，通过 RA 广播给直连设备。但在修改前，下游 OpenWrt 的 WAN6 状态只有一个地址：

1

2001:db8:1234:690:6c59:4eff:fecb:61f4/64

容易产生误解的是，这只是 OpenWrt WAN 接口通过 SLAAC 获得的一个 IPv6 地址，并不是可供 OpenWrt 继续划分给 LAN 的前缀。检查 WAN6 状态时可以看到：

1

"ipv6-prefix": []

由于没有获得 IA_PD，OpenWrt 的 LAN 只能继续使用 ULA 地址，日志中还会出现：

1

A default route is present but there is no public prefix on lan

最近重新梳理了一遍光猫、机顶盒和组播之间的关系，终于实现了以下目标：

• 原装 IPTV 机顶盒继续正常使用，直播和点播均不受影响；
• 局域网中的其他设备（电视、电脑、手机等）可以收看直播。

本文记录的是我在湖北武汉电信网络中的实际配置。不同地区的 VLAN 和认证方式都可能不同，请不要直接照抄参数。修改光猫前，建议先备份配置，并记录每一处原始设置。

原始网络结构

光猫中原本有两项主要业务：

1. 上网业务，采用路由模式，本文不讨论；
2. iTV 业务，采用桥接模式，仅绑定到光猫的 LAN2 口。

iTV 桥接连接的关键参数如下：

在这一结构下，电信机顶盒连接 LAN2，并由机顶盒自己进行 PPPoE 拨号。机顶盒的网络设置中可以看到 IPTV 账号，但密码通常不会直接显示。

这里有一个容易踩的坑：IPTV 密码可能由机房或装维系统下发。即使通过 10000 客服重置或查询到了一个密码，也不一定能在现网环境中成功拨号。如果确认账号无误但始终认证失败，最好直接联系当地装维人员，获取当前线路实际使用的 IPTV 密码。

失败的尝试：让两个设备分别拨号

我最初的思路很直接：在光猫的 iTV 桥接连接中，除 LAN2 外再绑定一个 LAN3，让原装机顶盒连接 LAN2，另一个路由器或小主机连接 LAN3。两台设备分别使用同一组 IPTV 账号、密码拨号，小主机负责运行 igmpproxy，就可以实现局域网组播。

实际测试发现，这种方式行不通：只要其中一台设备已经拨号成功，第二台设备的拨号就会被拒绝。至少在我的线路上，同一个 IPTV 账号无法同时建立两个 PPPoE 会话。这意味着如果光猫桥接，让下游设备拨号，原装机顶盒和独立组播代理只能二选一。

关键调整：改由光猫拨号

进一步查看机顶盒设置时，我发现它除了 PPPoE，还支持 DHCP 联网。由此可以换一种思路：

不再让机顶盒直接拨号，而是让光猫建立 IPTV PPPoE 连接，再通过 DHCP 给 LAN2、LAN3 下游设备分配地址。

我将光猫中的 iTV 连接从桥接模式改为路由模式，填写 IPTV PPPoE 账号和密码，并同时绑定 LAN2、LAN3。

修改后，光猫成功获得了运营商 IPTV 网络中的 10.x.x.x 地址，机顶盒改为 DHCP 后也能取得光猫下发的局域网地址。

此时测试结果如下：

• IPTV 平台登录正常；
• 菜单和业务页面正常；
• 点播节目可以播放；
• 直播频道仍然黑屏。

这个现象很有价值。它说明 PPPoE 认证、DHCP 和普通 IP 通信已经正常，机顶盒也没有被限制为必须自行拨号；但直播所需的组播链路尚未打通。点播通常走普通单播，而直播依赖 IGMP 和运营商的组播 VLAN，因此两者完全可能出现一个正常、另一个黑屏的情况。

xiaoai-agent 想解决的正是这个问题：让小爱音箱不只是一个云端语音入口，而是变成一台可以常驻运行的端侧语音 Agent 设备。

项目地址：github.com/stevenjoezhang/xiaoai-agent

背景：小爱音箱还有很多潜力

小爱音箱本身是一类很适合承载语音 Agent 的设备。它有麦克风阵列，有扬声器，有唤醒能力，也有成熟的音频播放和 TTS 链路。换句话说，它的硬件形态已经非常接近「家里的 AI 入口」。

但现实使用中会遇到几个限制：

• 原生小爱同学的对话能力和可扩展性有限，很难按自己的偏好接入新的大模型、ASR 或工具。
• 一些改造方案需要额外部署服务器或桥接服务，链路变长，维护成本也会变高。
• 原生小爱同学仍然可能监听麦克风，出现抢麦、抢答，甚至触发小米云端控制的情况。
• 音频体验很难做好，比如唤醒、录音、回声消除、连续对话、中途打断等细节，任何一个环节不稳都会影响日常可用性。

xiaoai-agent 的方向，是尽量把这些能力收回到音箱端侧，让音箱自己完成唤醒、录音、识别、思考、工具调用和回复。

现有方案与不足

在 xiaoai-agent 之前，已经有不少项目尝试把小爱音箱和大模型连接起来。这些探索证明了小爱音箱的可玩性，也把很多底层路径跑通了。

比如原生小爱同学提供了稳定的唤醒、TTS、设备控制和生态接入能力，适合普通用户日常使用。但它的对话能力、模型选择和工具扩展都比较固定，用户很难把自己的 ASR、大模型或智能家居工作流接进去。

Open-XiaoAI 这类项目则打开了更底层的设备改造路径，让音箱具备 SSH、启动脚本和自定义部署的可能。它解决的是「能不能进入设备、能不能运行自己的东西」的问题，为后续折腾提供了基础。

MiGPT 等桥接类方案则更进一步，把大模型对话接入到小爱音箱体验里，让用户可以用自然语言和 AI 聊天。这类方案的优势是思路清晰、上手相对友好，但通常需要额外服务端或桥接层来承载 Agent 逻辑，音箱本身更像前端入口。

这些方案各有价值，但也留下了一些共同痛点：语音链路复杂、部署组件偏多、原生小爱可能抢麦或抢答、云端控制可能被误触发，音频细节也容易受多层转发影响。xiaoai-agent 正是在这些探索之上，尝试把 Agent 主流程进一步收回到音箱端侧。

它解决了什么痛点

xiaoai-agent 最核心的价值，是把小爱音箱改造成一个更开放、更可控的语音 Agent 载体。

首先，它避免了「两个助手同时工作」的混乱。项目会让原生小爱同学的麦克风输入静音，由 xiaoai-agent 接管真实麦克风音频。这样可以减少抢麦、抢答，以及误触发小米云端控制的问题。

其次，它降低了长期运行的复杂度。传统方案常常需要在局域网里额外跑一个服务，音箱和服务之间再做消息转发。xiaoai-agent 选择直接在音箱端侧运行 Agent，部署链路更短，也更像一台独立设备。

第三，它复用了音箱原本已经做好的音频能力。唤醒、VPM 音频回调、TTS 播报、播放控制等能力都来自设备原生系统，日常交互会更接近「真正的音箱体验」，而不是把音箱当作一个简单的外设。

最后，它给用户留下了足够多的选择空间。ASR 可以使用兼容 OpenAI POST /v1/audio/transcriptions 的服务，大模型也可以接入 OpenAI-compatible API。你可以按自己的预算、延迟和隐私偏好选择服务，而不是被固定在单一路径里。

主要特性

xiaoai-agent 是一个非官方技术研究项目，核心 Agent 使用 Rust 编写，运行在小爱音箱端侧。目前项目已经在 Xiaomi 智能音箱 Pro（OH2P）固件 1.62.2 上测试成功。

它目前已经具备一套完整的语音 Agent 闭环：

• 端侧常驻运行：Agent 直接运行在音箱上，不需要额外部署专门服务端。
• 完整语音流程：支持唤醒、录音、ASR、大模型对话、工具调用和 TTS 回复。
• 更自然的交互：支持连续对话、VAD、中途打断、回声消除和播放时录音。
• 开放模型接入：ASR 和 LLM 均可配置为兼容 OpenAI API 的服务。
• 工具与设备控制：内置时间、天气、音乐播放等工具，并可通过 Home Assistant MCP 控制智能家居。
• 保留部分系统能力：语音对话由 Agent 接管，但蓝牙网关等非语音服务不应受到影响。
• 可自定义体验：可以调整唤醒响应、LED 状态、音乐服务和运行参数。

项目仓库中也包含补丁固件制作、刷机辅助、示例配置和部署说明，方便用户从设备准备一路走到 Agent 常驻运行。需要特别说明的是，它不是官方项目，也不是面向所有型号的一键通用方案；现阶段更适合愿意折腾、理解刷机风险，并且手上有对应设备的用户尝试。

这套能力组合起来，小爱音箱就不再只是一个固定功能的智能音箱，而更像是家里可以听、可以说、可以调用工具的 AI 节点。

笔者很久以前在 Mac 上通过 Boot Camp 安装了 Windows 系统，最近计划将这个系统迁移到 ESXi]]>

本文介绍如何在 Ubuntu]]>

本文实验成功的环境：

• 路由器：OpenWRT（系统版本 24.10）
• TFTP/HTTP 服务器：一台内网 Linux 服务器（安装 Ubuntu 系统）
• 客户端：支持 UEFI PXE 的服务器主板

PXE 启动原理

PXE（Preboot eXecution Environment）启动主要由以下步骤组成：

1. 客户端通过网络发送 DHCP Discover
2. DHCP 服务器返回 IP 地址，并附加 PXE 相关字段：
   • next-server（TFTP server 的 IP）
   • filename（要下载的启动文件，如 snponly.efi）
3. 客户端向 TFTP 服务器请求文件
4. 使用下载到的引导器加载后续启动流程，例如：
   • iPXE（支持 HTTP、iSCSI 等）
   • Linux kernel + initrd

OpenWRT 的 dnsmasq 内置了 PXE 支持，并且可以方便地通过 LuCI 界面配置。

配置 TFTP 服务

首先，在内网 Linux 服务器上安装 TFTP 服务，用于提供必要的文件。以 tftpd-hpa 为例：

1

sudo apt install tftpd-hpa

编辑 /etc/default/tftpd-hpa：

1
2
3
4

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure"

重启服务：

1

sudo systemctl restart tftpd-hpa

配置 HTTP 服务

以 Nginx 为例：

1

sudo apt install nginx

重启服务：

1

sudo systemctl restart nginx

购买辅助蓄电池

通过咨询多家淘宝上售卖相关电瓶配件的店铺，得知需要更换的电瓶外观如下所示。这款电瓶售价普遍在 200 多元。笔者挑选了一家看上去比较靠谱的店铺进行购买，但是也没有很好的办法验证真伪，毕竟这个电瓶看上去就很容易用旧的翻新。只能希望不要出现安全隐患。

更换过程

与其它一些奔驰汽车不同，CLA200 的辅助蓄电池位于副驾驶的脚底，而不是后备箱中。在更换时，需要先将副驾驶侧的地垫揭开。

这时，地垫下面的情况就很清楚了，左上角部分的塑料保护盖下方就是辅助蓄电池，还可以看到两侧的接线端子。

Enigma 机是二战时德军使用的加密装置。它拥有三个可以转动的转子，一个固定的反射器，插线板，键盘，灯板等组件。插线板能够交换两个字母，转子可以将一个字母映射为另一个字母。这都是通过电路实现的。使用者点击键盘上的按键输入明文字母后，机器中电池产生的电流将通过插线板、三个转子、反射器，然后折返，再次通过三个转子和插线板，将灯板上的密文字母对应的灯泡点亮。每次按下按键时，转子会产生旋转，并且在到达特定位置时会产生进位。因此，每次加密时导通的电路会发生变化，使得 Enigma 机的加密过程难以被破解。Enigma 的实现和软件模拟器可以参考前面的文章自己打造一台恩尼格玛密码机。

在二战后期，德军使用的 Enigma 机允许操作者从多个转子中选择 3 个，每个转子有 26 种初始位置，并且插线板上可以交换 10 组字母。这产生了一个巨大的密钥空间，看上去使 Enigma 机坚不可摧。然而，波兰数学家 Rejewski 在 30 年代就发现了 Enigma 机操作流程上存在的弱点，并针对其设计了破解方法。在二战爆发后，相关的技术被共享给了盟军的情报机构，但德军也加强了 Enigma 密码的安全性。英国数学家和计算机科学家 Turing 进一步地设计了已知明文攻击的方法，成功破解了 Enigma 机，为世界反法西斯战争的胜利做出了重要的贡献。笔者复现了 Rejewski 和 Turing 破解 Enigma 机使用的方法，并将在本文中详细介绍。

算法原理

Rejewski 的破解方法

在上世纪三十年代，Enigma 机的操作流程是：每天所有人都会使用相同的日密钥，但日密钥不用于加密信息；在发送一条信息时，操作者需要先随机生成三个字母的信息密钥。操作者会首先使用日密钥，将信息密钥输入两次，产生的 6 个字母的密文作为开头。随后，操作者将机器的转子调整为信息密钥所对应的转子位置，并开始加密信息。信息密钥输入两次的原因是为了避免信息传输中因为干扰出现错误，收信方如果发现通过日密钥解码出的前 6 个字母明文不是重复两次的格式，则可以发现问题。但是，重复是加密的敌人，Rejewski 敏锐地观察到了这一点。第一个字母和第四个字母是同一个明文加密出来的，并且输入第一个字母时，转子的设置都是日密钥，是完全相同的。于是，在某一天中收到的所有由 Enigma 机加密的密文，都会满足类似这样的规则：

• 如果第 1 个字母为 A，那么第 4 个字母为 E；
• 如果第 1 个字母为 B，那么第 4 个字母为 L；
• 如果第 1 个字母为 C，那么第 4 个字母为 C；
• …

表：密文的第一个字母和第四个字母的对应表格（部分）

将结果列出，如上表所示。Rejewski 发现，表中的字母存在一些 “链”，例如，上一行的字母 A 对应下一行的字母 E，上一行的字母 E 对应下一行的字母 N，以此类推，最后又回到字母 A。这样就产生了字母链 AENHI。同时，也可以找到其它的字母链：BLSJP，C，DOFWVG，K，MZURTY，Q，X。如果机器的初始状态相同，那么得到的字母链自然也是相同的。更重要的是，Rejewski 发现，插线板的存在只会改变字母链中的字母，但不会影响各个字母链的长度。
例如，在上面的场景中，额外将 A 和 C 之间加入一条接线，那么，原先的 AENHI 链会变为 CENHI，C 链会变为 A 链；但两条链的长度是不变的。因此，字母链的长度特征是插线板作用下的不变量，它只和转子的初始位置有关，由此可以将插线板的作用和转子的初始位置解耦合。波兰的破译团队用了一年的时间进行预计算，得到了所有转子初始位置与字母链的长度的对应关系。此后，在收到新的密文后，破译者可以查表，将字母链的长度与预计算的结果进行比较，得到可能的转子的初始位置。在成功恢复出转子初始位置后，破译者可以对密文进行解密，之后进一步地分析插线板的状态。具体的算法原理如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

输入：前6个密文字母的对应表格 T
输出：解集 Solutions

预计算阶段：
----------------------------------------
# 由波兰 Bomba 机模拟的 Enigma 机
E ← Enigma()

# 存储的数据库，用于之后查表
Database ← Map()

for each S in PossibleSettings:
    E.setPosition(S)
    C ← FindChainsByEnigma(E)
    Database.store(S, C)

破解过程：
----------------------------------------
Solutions ← Set()

for each S in PossibleSettings:
    Matched ← true

    for i ← 1 to 3:
        Chain ← FindChainsInTableRow(T[i], T[i+3])
        Expected ← Database.get(S + i)

        if Chain ≠ Expected:
            # 字母链没有通过检验
            Matched ← false

    if Matched = true:
        # 当前初始状态对应的字母链通过了检验
        # 将可能的解加入解集
        Solutions.add(S)