目录
NETGEAR RAX40 NMRP 恢复边界指南
这是一篇面向 NETGEAR RAX40 与 RAX40v2 的恢复边界知识页，不是 Router Recovery for macOS 的标准支持页面。
RAX40v2 适合作为现代 NETGEAR 参考设备，因为它清楚展示了一个边界：很多 NETGEAR 场景应先按 NMRP 或厂商特定恢复路径判断，而不是直接进入通用 TFTP Server 流程。Router Recovery for macOS 当前不执行 NMRP，也不应被包装成 NETGEAR NMRP 恢复工具。
这篇页面的用途是帮助你判断：当前设备是否仍属于标准 TFTP/Web Recovery 路径，还是应该离开 Router Recovery 产品路径，改用 NETGEAR 官方资料加型号级 NMRP 调查。
范围与证据等级
| 项目 | 当前证据 |
|---|---|
| 已观察设备 | NETGEAR Nighthawk RAX40v2。设备标签和本地 Web UI 均识别为 RAX40v2。 |
| 官方正常基线 | 本地管理地址 192.168.1.1，DHCP 启用，观察到 DHCP 范围为 192.168.1.2 至 192.168.1.254。 |
| 固件基线 | NMRP 实验更新前为 V1.0.17.142_2.0.100。 |
| NMRP 实验更新后固件 | 一次实验室更新后为 V1.0.17.144_2.0.101，使用 NETGEAR 官方固件和第三方 nmrpflash。 |
| 配置备份 | 恢复测试前创建过私有 NETGEAR_RAX40v2.cfg 备份。备份文件本身不公开。 |
| 设置异常 | 浏览器设置流程可到达 start.htm 和 ads_start.htm，但同意本地条款后会跳转到 routerlogin.net/genie_index.htm 并返回 404。 |
| 恢复窗口信号 | reset-on-power 观察中出现过一次很短的 ttl=100 ping 响应，随后恢复正常 ttl=64 启动。这只是信号，不是服务证明。 |
| NMRP 结果 | 一次 RAX40v2 实验室运行通过 nmrpflash 完成官方固件更新。这是有边界的实验室证据，不是 NETGEAR 品牌级产品承诺。 |
为什么不先走通用 TFTP
NETGEAR 官方仍有关于固件更新失败、电源灯 amber 或闪烁、管理页面不可用、DHCP 失败等场景的恢复资料。部分 NETGEAR 型号或状态确实可能涉及 TFTP。
问题在于，很多 NETGEAR 型号并不适合让 Mac 开一个普通 TFTP Server 文件夹，然后等待路由器请求固件。RAX40/RAX40v2 应放入厂商特定边界路径，因为 NMRP 可能是更现实的方向。
重要边界：
- ping 响应只证明该时刻 IP 层可见。
ttl=100可能是 bootloader 或类似恢复窗口信号，但不证明可用的 TFTP Server 路径。- 如果某个型号做过 ACK-only TFTP 探测，它最多证明一个 TFTP 服务回应了很小的测试传输，不等于固件恢复。
- 本 RAX40v2 页面不声称已验证标准 TFTP 固件传输。
已观察的 RAX40v2 NMRP 实验更新
这台 RAX40v2 实验设备曾通过一次 NMRP 更新，从 V1.0.17.142_2.0.100 更新到 V1.0.17.144_2.0.101，使用：
- NETGEAR 官方固件压缩包：RAX40v2-V1.0.17.144.zip
- 解压后的固件镜像：
RAX40v2-V1.0.17.144_2.0.101.chk - 本地观察到的文件大小：
84803662bytes - Mac 有线接口：
en0 - Mac 地址/IP 路径：更新前 Mac 在 RAX40v2 LAN 上持有
192.168.1.2 - 网线连接：Mac 连接到机身标注的
LAN 1口；在这台设备上，该口是距离 WAN 口最远的 LAN 口 - WAN 已拔掉
- 操作模式：先启动
nmrpflash，再给路由器断电重插，不按 reset
完整命令形态如下：
sudo nmrpflash -i en0 -f RAX40v2-V1.0.17.144_2.0.101.chk
参数含义：
-i en0指定本次实验使用的 Mac 有线接口。-f RAX40v2-V1.0.17.144_2.0.101.chk指定解压后的 NETGEAR 官方固件镜像。- 命令先启动，再给路由器断电重插，这样工具才能捕捉很短的 NMRP 恢复窗口。
运行中，路由器发出 NMRP configuration request，接受临时配置 10.164.183.253/24，随后发出 upload request，固件镜像上传完成。nmrpflash 打印过 TFTP block rollover warning，但上传仍显示 OK，远端也完成会话。
工具报告完成后，操作者等待约一到两分钟，然后断电重插。之后确认设备正常启动、DHCP 返回、192.168.1.1/start.htm 管理页面可访问，并显示固件 V1.0.17.144_2.0.101。
这个结果对 RAX40v2 很有价值，但在重复验证或独立复核前，仍应视为单台设备、单次固件更新路径证据。
NMRP 边界
NETGEAR 官方资料应优先用于确认准确型号、硬件版本、固件文件、release notes 和正常设置/管理行为。在本项目已复核的证据中，未找到 NETGEAR 官方把 NMRP 作为官方恢复方法来说明的资料。
实用 NMRP 流程证据来自社区工具 nmrpflash。该项目有价值之处在于，它记录了 NETGEAR NMRP 行为、接口选择、固件上传和 post-upload 等待等流程。但它仍是第三方工具，所以兼容性应被视为调查线索，而不是产品支持声明。
Router Recovery 在这里不做什么
Router Recovery for macOS 当前不做：
- 执行 NMRP
- 把 NETGEAR RAX40/RAX40v2 包装成标准商业恢复流程
- 根据这些证据声称 RAX40/RAX40v2 支持标准 TFTP
- 执行厂商特定的主动恢复上传
- 把这次实验室运行扩展成 NETGEAR 通用支持承诺
这篇页面存在的目的，是避免用户在 NETGEAR 型号更可能需要 NMRP 或其他厂商特定流程时，误启动错误的恢复路径。
什么时候回到 Router Recovery
只有在准确型号和硬件版本已经确认，并且该型号明确使用 Router Recovery 当前支持的标准 TFTP Server 或 Web Recovery 路径时，才回到 Router Recovery 流程。
对 RAX40/RAX40v2，应先把本页作为边界参考。如果后续发现某个具体状态确实会从标准 TFTP Server 请求固件，应把该证据与 NMRP 结果分开记录，并明确固件文件名、IP 地址、时间窗口、ACK 行为、上传完成、post-upload 等待、DHCP 返回和管理页面结果。
FAQ
RAX40 一定是 NMRP 吗？
不是。这篇页面表达的是：不要把 RAX40/RAX40v2 默认当成通用 TFTP 机型。一台 RAX40v2 实验设备已经通过 NMRP 完成官方固件更新，但仍需要检查准确硬件版本、固件文件、设备状态和官方资料。
ttl=100 是否代表恢复模式？
不是。已观察的 RAX40v2 在 reset-on-power 过程中只出现过一次很短的 ttl=100 响应，随后正常启动并返回 ttl=64。应把 ttl=100 当成调查信号，而不是固件服务已准备好的证明。
ACK block 0 是否代表恢复成功？
不是。小型 TFTP 测试传输的 ACK 只能说明有服务回应，不证明路由器接受、写入并从固件镜像成功启动。恢复证据需要完整链条：传输、post-upload 等待、重启、DHCP 或链路返回、固件和管理页面确认。
实验室是否完成过 RAX40v2 NMRP 更新？
是，完成过一次。实验室使用 NETGEAR 官方固件和 nmrpflash，将一台 RAX40v2 从 V1.0.17.142_2.0.100 更新到 V1.0.17.144_2.0.101。这应作为 RAX40v2 实验室证据，而不是 NETGEAR 品牌级产品声明。
为什么不先运行通用 TFTP 恢复？
因为对很多 NETGEAR 设备来说，通用 TFTP 可能不是正确的第一路径。如果设备需要 NMRP 或其他厂商特定流程，反复重试通用 TFTP 只会增加混乱，不能证明正确恢复路径。
相关页面
来源与证据类别
- NETGEAR Support，用于官方型号、固件、设置和恢复资料。
- NETGEAR RAX40v2 V1.0.17.144 固件压缩包，用于本次实验更新。
- nmrpflash，作为第三方 NMRP 流程证据。
- Router Recovery reference-device 项目的本地实验室证据：官方基线、设置跳转异常、恢复窗口观察，以及一次完成的 RAX40v2 NMRP 官方固件更新。