前言：看似就绪，实则断网的绝望

在本次软件工程项目实训中，我们团队的核心任务是将 OpenHarmony 6.1 系统移植到基于 RISC-V 架构的 musepaper2 开发板上。系统底层的坑一个接一个，在修复了深度休眠导致 USB 掉线的致命 Bug 后，我终于把目光转向了这块板子的“心腹大患”——WiFi 模块。

通过串口查看内核日志，系统其实已经成功识别了 rtl8852bs 网卡驱动，ifconfig -a 也能看到 wlan0 节点。本以为这已经是胜利的曙光，但我很快发现了一个令人头疼的问题：空有网卡，系统里居然没有配置网络的上层工具！

默认编译出的精简版系统里，没有网络管理界面，没有 DHCP 客户端，甚至连最基础的 WiFi 认证工具 wpa_supplicant 都因为缺少运行目录而一启动就闪退。

本篇记录了尝试修改wifi模块适配的过程。

阶段一：为 wpa_supplicant “手搓”地基

wpa_supplicant 是 Linux 下最核心的无线网络认证守护进程。当我在终端尝试启动它时，立刻收获了一个冷冰冰的 No such file or directory 报错。

经过排查，原因非常死板：这个程序硬编码要求系统中必须存在特定的工作目录和通信套接字（socket）目录，哪怕是一个空的配置文件，找不到它就会直接罢工。既然系统没给我们建，那就自己动手。

通过 hdc shell 进入板子终端，我开始了一层层的目录构建：

# 创建配置和运行所需的专属目录
mkdir -p /data/service/el1/public/wifi/wpa_supplicant/
mkdir -p /data/service/el1/public/wifi/sockets/

目录有了，还得给它一份基础的“说明书”。在没有 vim 的精简终端里，echo 命令成了最强大的武器：

# 指定控制接口（让后续的 wpa_cli 能找到它）
echo "ctrl_interface=/data/service/el1/public/wifi/sockets/wpa" > /data/service/el1/public/wifi/wpa_supplicant/wpa_supplicant.conf
# 允许更新配置
echo "update_config=1" >> /data/service/el1/public/wifi/wpa_supplicant/wpa_supplicant.conf

地基打好后，唤醒网卡，带上刚才手写的配置文件，再次发起冲击：

ifconfig wlan0 up
cd /vendor/bin/
./wpa_supplicant -B -i wlan0 -c /data/service/el1/public/wifi/wpa_supplicant/wpa_supplicant.conf

执行 ps -ef | grep wpa。看到两条进程稳稳地驻留在后台，那一刻，我知道物理链路的门已经被撬开了。

阶段二：命令行里的“遥控器”与一个经典的乌龙

服务跑起来了，接下来要用 wpa_cli（可以理解为操作 wpa_supplicant 的遥控器）去连接我手机的个人热点。

输入 ./wpa_cli -p /data/service/el1/public/wifi/sockets/wpa，终端提示符变成了 >，顺利进入交互模式。

我熟练地敲下 add_network，拿到序号 0。接着配置 SSID 和密码：

> set_network 0 ssid "iPhone12138"
> Unknown command '>'

这里出现了一个非常经典的“复制粘贴乌龙”。我当时直接把别人教程里的 > 提示符一起复制了进去，导致系统不认识这个命令，直接被踢出了交互模式退回了 #。

思考与总结： 这种看似低级的错误，恰恰是底层调试中最耗人精力的。在 Linux 交互式终端中，必须时刻清楚自己处于哪一层 Shell 中。重新进入 wpa_cli，老老实实地纯手打：

set_network 0 ssid "iPhone12138"
set_network 0 psk "真实的密码"
enable_network 0

几秒钟后，终端刷出了一行极其美妙的日志：<3>CTRL-EVENT-CONNECTED。同时，我看了眼手机，状态栏显示“1 个设备已连接”。物理层，通了！

阶段三：绝境逢生，iPhone 热点的“神仙后门”

连上 WiFi 只是“拉通了网线”，板子现在还是个没有 IP 的黑户。正常逻辑下，我们应该运行 udhcpc -i wlan0 自动获取 IP。

现实又给我泼了一盆冷水：/bin/sh: udhcpc: inaccessible or not found。系统太精简，连 DHCP 客户端都没打包！如果没有 DHCP，我就无法拿到合法的 IP 和网关，依然上不了网。难道一切都要推倒重来，去重新编译内核工具吗？

就在这时，我突然想到我连接的是 iPhone 热点！苹果 iOS 系统的个人热点有一个雷打不动的死规律：它分配的局域网网段永远是 172.20.10.x，并且手机自身的网关 IP 永远是 172.20.10.1。

既然规则是死的，为什么还要工具去动态获取？我完全可以直接给开发板强行写死一个合法的静态 IP！这是本次 Debug 中最让我兴奋的一个思路跳跃。

直接在终端敲入底层网络配置指令：

# 强行抢占一个没人用的 IP
ifconfig wlan0 172.20.10.10 netmask 255.255.255.240 up
# 指明去往互联网的路（默认网关指向 iPhone）
route add default gw 172.20.10.1

配置完毕，深吸一口气，敲下终极测试命令：

ping -c 4 8.8.8.8

终端停顿了大概 0.5 秒，紧接着： 

通了！！数据包终于冲出了局域网，从开发板的网卡发出，经过 iPhone 的基带，跨越了无数个路由器，到达了 Google 的 DNS 服务器并成功返回。

验证结束，但这只是工程的起点，在板子上通过命令行“手搓”出来的成功，只要一重启就会失效，但是我们已经找到问题所在，下一篇将记录源码解决方案。

这只是一次“热修复验证”，它证明了硬件没坏、驱动没错，缺的只是系统级的自动化配置。接下来的任务，就是要把我刚才敲下的这一堆指令，全部转化为 OpenHarmony 的源码构建规则，彻底固化进系统镜像中。这将是我下一篇文章的主题。