企业官网建设流程全解析

简介：面向Windows CE嵌入式开发者的Wi-Fi功能实现工程，以WifiDemo示例项目为载体，围绕无线网卡驱动集成、WLAN API调用与应用程序开发三个层面，完整演示从驱动接入到连接管理的编码思路。压缩包共21个文件、约68KB，以7个h与4个cpp源文件为核心，辅以API链接库、Visual Studio解决方案与工程文件、rc资源文件及说明文档，各类文件分工明确，便于按模块对照学习。示例覆盖无线网络扫描、网络选择、连接与断开操作，以及对话框交互界面与错误处理的完整流程，可直接借鉴WlanScan、WlanConnect等API调用方式，理解Wince下无线驱动与上层应用的协作机制。已有317人学习使用，配套说明文档还提供进一步获取参考资料的外部线索，适合初次接触Wince无线网络编程、希望以最小代价快速跑通Wi-Fi功能，或正在做相关移植评估的嵌入式开发者。

1. WinCE下的WiFi实现：从一台三天连不上AP的手持设备说起

一个月前，我在给一台基于WinCE 6.0的工业手持终端加装WiFi功能。硬件预留了SDIO接口，驱动SDK也齐全，可WiFi始终扫描不到热点，折腾到第三天才发现是注册表里中断号写错了。后来调通模组，又接连遭遇WPA2连接超时、睡眠唤醒后网卡假死、漫游时IP地址一直按老AP的网关去发等一连串问题。这份笔记是这次调机的完整复盘，把WinCE下WiFi实现涉及的驱动加载、OID配置、WZC参数、连接调试和五个高频坑都整理出来，适合正在把某块WinCE开发板接上WiFi，却不知道从哪里下手的嵌入式工程师。如果你也有类似场景，建议先看完第5章再动手。

2. 软件栈：NDIS、miniport与WZC是怎么协同工作的

WinCE的网络体系跟桌面Windows不一样。它不是直接把驱动挂在某个设备目录下，然后应用就能用socket。WiFi功能要从底层网卡驱动开始，逐层向上注册。我一开始拿到的驱动包里有一个DLL，以为把它加进BSP编进去就行，结果系统起来后控制面板里根本没有无线网卡。所以得先把整条软件栈理清楚。

2.1 驱动模型：为什么WiFi驱动必须挂在NDIS下

WinCE的网络驱动模型分四层：最上面是应用层的Winsock，下面依次是TCP/IP协议栈、NDIS（Network Driver Interface Specification）库和最底层的网卡驱动。NDIS是一个中间层，它给上层一个统一的接口，给下层驱动一套回调函数。普通的以太网驱动只要实现发送、接收、中断处理就够了，但WiFi驱动不一样，它还要处理扫描、关联、认证、密钥管理这些802.11特有的行为。所以Windows Embedded CE要求WiFi驱动以NDIS miniport角色存在，向上暴露“无线接口”，向下通过SDIO、SPI或USB总线跟模组通信。

我当时用的是SDIO接口的WiFi模组。选SDIO而不是USB，理由很简单：这类模组主控通过内置SDIO控制器直接连，不需要外挂USB Host，而且模组内部自带了协议栈，中断和DMA都由同一根时钟线驱动，实时性比USB好。但代价是，SDIO驱动的调试要比USB麻烦得多，因为SDIO没有枚举过程，所有基地址、中断号都靠注册表告诉驱动，写错一个系统就看不见网卡。

NDIS库为WiFi驱动准备了一组专门的OID（Object Identifier）命令。例如OID_802_11_BSSID_LIST_SCAN触发扫描，OID_802_11_SSID设置目标SSID，OID_802_11_DESIRED_SSID指定要连接的网络。应用程序很少直接发这些OID，而是通过WZC服务来间接操作。WZC在WinCE里叫Wireless Zero Configuration，它负责监听用户配置，维护一个无线配置文件列表，并按需调用NDIS的OID接口。如果你的BSP里没有包含WZC模块，那就得自己写一个服务，直接用DeviceIoControl把OID发给网卡。

2.2 用DeviceIoControl发送OID：扫描、连接和断开

在调试没有WZC或者WZC配置不生效的环境时，我习惯写一个小工具直接和NDIS通信。这样做的好处是能绕过系统服务，把问题精确定位到驱动层。下面是一个在WinCE下触发无线扫描的代码片段。

// 打开NDIS网卡设备，WinCE下第一个无线网卡通常命名为NDS0: HANDLE hNdis = CreateFile(_T("NDS0:"), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); if (hNdis == INVALID_HANDLE_VALUE) { // 如果打开失败，先查驱动的注册表服务键是否加载 RETAILMSG(1, (_T("NDS0: open failed, err=%d\r\n"), GetLastError())); return -1; } // 构造NDIS_OID结构，触发扫描 NDIS_OID scanOid; scanOid.Oid = OID_802_11_BSSID_LIST_SCAN; scanOid.hDevice = (NDIS_HANDLE)hNdis; // 部分驱动不检查这个字段 BYTE scanBuf[256] = {0}; // 存放扫描结果，实际结果可能比这个大 DWORD bytesReturned = 0; BOOL bRet = DeviceIoControl(hNdis, IOCTL_NDIS_OID, &scanOid, sizeof(NDIS_OID), scanBuf, sizeof(scanBuf), &bytesReturned, NULL); if (!bRet) { // 常见失败原因是驱动没有实现该OID，或当前正在别的操作中 RETAILMSG(1, (_T("scan OID failed, err=%d\r\n"), GetLastError())); } CloseHandle(hNdis);

代码里有一个容易踩坑的地方：scanBuf只有256字节，但扫描结果需要按BSSID数量动态变化。真正项目里应该先查询OID_802_11_BSSID_LIST的长度，再分配合适的缓冲区，否则驱动把数据写过来时直接溢出。更好的做法是第一次调用传空缓冲区，拿到返回长度，第二次再传完整缓冲区。IOCTL_NDIS_OID是系统定义的控制码，不要自己创造。NDIS_OID结构里的Oid字段才是关键，不同的OID对应不同的功能。

连接操作类似，差别是你得先设置SSID和认证模式。很多新上手的朋友以为连接就是发一个OID_802_11_ASSOCIATE，实际上驱动首先要设置加密方式，再设置SSID，再设置密钥，最后触发关联。顺序错了，前面的设置会被后面的覆盖，导致连接始终失败。

2.3 查询BSSID列表：解析扫描结果的标准姿势

扫描只是第一步，要拿到可连接的热点列表，还需要查询OID_802_11_BSSID_LIST。这个OID返回一个结构体数组，每个NDIS_WLAN_BSSID里包含BSSID、SSID、Channel、RSSI、SupportedRates等。解析时注意结构体是紧凑排列还是自然对齐，不同驱动实现不一样。我用的驱动是自然对齐，直接按结构体大小加偏移就行，但有的驱动会在每个BSSID后面多填充4字节。为了安全，你可以先打印返回长度，和计算出的理论长度对比，如果多出就很可能是填充。

// 第一次调用获取所需缓冲区大小 NDIS_OID listOid; listOid.Oid = OID_802_11_BSSID_LIST; BYTE *pBuf = NULL; DWORD sizeNeeded = 0; DeviceIoControl(hNdis, IOCTL_NDIS_OID, &listOid, sizeof(listOid), NULL, 0, &sizeNeeded, NULL); // 第二次调用真正获取列表 pBuf = (BYTE*)malloc(sizeNeeded); DeviceIoControl(hNdis, IOCTL_NDIS_OID, &listOid, sizeof(listOid), pBuf, sizeNeeded, &bytesReturned, NULL); // 解析：第一个DWORD是条目数，后面紧跟NDIS_WLAN_BSSID数组 DWORD count = *(DWORD*)pBuf; BYTE *pEntry = pBuf + sizeof(DWORD); for (DWORD i = 0; i < count; i++) { NDIS_WLAN_BSSID *bssid = (NDIS_WLAN_BSSID*)pEntry; RETAILMSG(1, (_T("BSSID:%02X-%02X, RSSI:%d, Ch:%d\r\n"), bssid->BSSID[0], bssid->BSSID[1], bssid->RSSI, bssid->Ch)); // 移动指针到下一个条目，注意按4字节对齐 pEntry += (sizeof(NDIS_WLAN_BSSID) + 3) & ~3; } free(pBuf);

这段解析逻辑里最危险的是指针移动。如果你的SDK头文件里NDIS_WLAN_BSSID已经用了#pragma pack(1)，那么填充为空，直接用sizeof加就行。但如果头文件没有设置紧凑对齐，结构体尾部会有填充，你必须按(len+3)&~3对齐。我遇到过驱动返回列表长度正好是紧凑长度，但结构体定义是自然对齐，导致解析到第三个BSSID时指针错乱，程序直接崩掉。

2.4 WZC配置的两种路径

WZC是系统级的无线配置服务。它的好处是能统一管理多个配置文件，但坏处是配置存储的注册表结构不直观。路径一：在控制面板的“网络连接”里手动添加无线网络，系统会自动把配置写到HKEY_LOCAL_MACHINE\Comm\WZCSVC\Profiles。路径二：直接修改这个注册表键，然后让WZC服务重新加载。我一般把首个配置文件固定在默认Profile上：

[HKEY_LOCAL_MACHINE\Comm\WZCSVC\Profiles\MyCorpNet] "SSID"="MyCorpNet" "AuthMode"=dword:1 ; 1表示WPA2-PSK，0表示Open "Encryption"=dword:3 ; 3表示AES "Key"="MySecretKey" "KeyIndex"=dword:0

注意AuthMode和Encryption的取值是微软头文件里定义的枚举值，不同版本的WinCE定义可能稍有差别。如果你直接用注册表导入，最好对照当前SDK的头文件确认。而且这里存的是明文密钥，适合调试环境，产品量产时要用更安全的存储方式。

除了注册表路径，还可以调用WZC的API函数，比如WZCEnumInterfaces枚举网卡，WZCSetConfiguration下发配置。这类API在wzcsapi.h里，但文档较少，调试时最好用远程过程调用监视器观察参数。我因为手头没有完整文档，走了不少弯路，所以更推荐先用注册表调通连接，再回头看API。另外注意，修改了注册表之后，要让WZC重新刷新配置，最直接的办法是重启WZC服务，或者调用WZCRefreshInterface函数。如果这两条都不做，新配置不会在现网卡上生效。

3. 移植SDIO WiFi驱动：编译、加载与注册表配置

驱动源码从芯片原厂SDK里拿到手，往往不能直接编译进你的BSP。原厂默认配置是针对某一块公板的，主控芯片、SDIO控制器基址、GPIO定义都跟你的板子不一样。我第一次把驱动编进内核，启动后控制面板里没有WiFi图标，后来在注册表里一项一项对，才找到问题。

3.1 拿到驱动源码后先改哪些文件

一个标准的SDIO WiFi驱动包通常包括：驱动DLL源码、SDIO总线封装、配置文件（.rc）、以及一个注册表模板。你首先要改的是sources文件，这个文件告诉Build工具编译哪些源文件、链接哪些库。很多驱动包默认链接的库是ndis.lib，如果你的BSP是WinCE 6.0，还得注意CPU类型和ARM版本，比如ARMV4I和ARMV7对应的预处理器宏不同，搞错了编译会报找不到ARM汇编文件。

第二要改的是驱动里的平台相关头文件，常见名字是platform.h或hw_config.h。里面定义了SDIO控制器的基地址、时钟分频、中断号、电源管理GPIO。例如，某款模组的复位脚接在主控的GPIOA_5上，你就需要把GPIO_RESET_PORT改成对应的寄存器地址和位号。这里没有通用答案，只能对照你的原理图改。改完最好在驱动初始化函数里加打印，确认复位引脚有没有拉高。

第三是sources里WINCEROOT的引用路径。有些驱动包是从老平台拷贝来的，头文件引用路径还是基于相对路径，如果你的SDK目录结构不同，编译会报一堆找不到头文件的错误。我的习惯是先把所有#include路径拉出来，逐一检查是否存在。

3.2 注册表键值与中断/GPIO绑定

SDIO设备没有即插即用的枚举，必须通过注册表告诉系统“这里有张无线网卡”。这个键的位置一般在HKEY_LOCAL_MACHINE\Drivers\BuiltIn\SDIO\Wifi。下面是一个典型配置：

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\SDIO\Wifi] "Dll"="wifi_driver.dll" "Prefix"="NDS" "Index"=dword:0 "Order"=dword:0 "SDIOFunctionNumber"=dword:0 "SDIODeviceID"=dword:0x9128 "SysIntr"=dword:17 "GPIO_PowerOn"=dword:5

这里的SysIntr是系统中断号，不是物理中断号。物理中断要先用映射函数转换。GPIO_PowerOn是给WiFi模组供电的GPIO编号，不同板子引脚不同，写错会导致模组上电后死掉。SDIODeviceID对应模组的供应商和产品ID，如果你的模组没有枚举好，这个值可以暂时设0，用调试信息确认后再改。

配置写好以后，需要把注册表编进内核，或者用远程注册表编辑器直接导入。驱动DLL要放在\Windows目录下，系统启动时Device Manager会根据注册表的Dll字段加载。加载成功的标志是调试串口出现 “NDIS0: installed” 之类的打印。

为了让你对照检查，我整理了一张关键键值的说明表：

3.3 驱动加载失败的常见症状

驱动没加载成功，现象五花八门。最常见的是控制面板里没有“网络连接”里的无线网卡图标；其次是CreateFile打开NDS0:失败，错误码是ERROR_FILE_NOT_FOUND。这时不要急着怀疑驱动源码，先查注册表有没有被正确编入NK。我在调试时发现，改好的注册表在冷启动后被系统重置，原因是BSP的数据库文件（.db）没更新，Build时用了旧库。

另一个症状是驱动DLL加载了，但初始化函数停在某个位置，系统启动变得很慢。这通常是GPIO或中断配置不对，驱动在等待模组响应时卡死。解决方法是临时用CeLog或RETAILMSG在初始化函数里打印每一步的时间戳，看到底是卡在SDIO的读寄存器还是卡的等待固件下载。

还有种情况是网卡驱动已经成功，但扫描不到任何AP。这不一定是你配置的问题，可能模组的天线没焊好或者射频电路没供上电。下一章我会专门讲参数和安全配置，但这里要记住一条：驱动加载成功只代表软件链路通了，射频前端不工作，后面的事全白扯。

4. 连接参数与安全设置：WEP/WPA2的配置陷阱

当网卡驱动能正常扫到AP，接下来的工作集中在连接参数上。WinCE对无线网络的支持很老，早期版本对WPA2支持不完整，需要安装补丁。我在调试过程中就遇到一个怪问题：同一个SSID，用手机能连上，WinCE设备总是提示密码错误，后来发现是密码后面的不可见字符在作怪。

4.1 配置文件中SSID的字符编码陷阱

SSID在WinCE内部是以ASCII字符串处理的，但很多项目把SSID写在Unicode的配置文件里。比如用记事本把注册表文件保存为UTF-16 LE，WZC读取时会把它当ASCII，字符串中间混入00，驱动拿到的SSID变成了 “M”“y”“\0”“N”“e”…当然连不上。解决方法是：注册表文件保存为ANSI编码，并且在代码里定义TCHAR数组时要注意，WinCE的TCHAR默认是UTF-16，传给WZC之前要转成窄字符。

还有一种情况是SSID尾部有多余的空格。我遇到过AP配置的SSID是 “AP-CORP” 后面带一个不可见空格，Windows设备自动忽略，WinCE设备却很较真。排查时用十六进制查看密钥和SSID，不要用眼睛看。

// 转换SSID到窄字符，并去掉尾部的空格 char szSsid[33] = {0}; WideCharToMultiByte(CP_ACP, 0, pWideSsid, wcslen(pWideSsid), szSsid, sizeof(szSsid) - 1, NULL, NULL); int len = strlen(szSsid); while (len > 0 && szSsid[len - 1] == ' ') { szSsid[--len] = '\0'; }

这段代码先把宽字符串转成ANSI，再用一个循环剔除尾部空格。注意WideCharToMultiByte参数里最后一个布尔值是转换失败标志，在WinCE上通常传NULL。去掉空格不仅解决了连接问题，也避免了后续配置管理工具的坑。

4.2 WPA2-PSK的设置与认证时序

WPA2-PSK认证流程是四步握手：AP发送随机数，STA生成密钥，然后交换MIC和分组密钥。这个流程依赖网卡驱动正确处理EAPOL帧。WinCE需要注册表告诉NDIS去处理WPA2。不知道你有没有遇到过这种情况：配置成WPA2-AES后，连接时驱动提示“成功”，但IP地址一直是169.254.x.x，这往往说明关联成功但认证没完成。

认证没完成通常有三个原因：第一，驱动不支持WPA2，只支持WEP或WPA1。第二，注册表里的AuthMode枚举值写错，我用的SDK里WPA2-PSK的值是3，而不是1。第三，密钥长度和格式不对。WPA2-PSK要求密码至少8个字符，最多63个。如果你的密码是纯数字，部分驱动会尝试把它当作Hex密钥解析，你需要显式设置KeyFormat为ASCII。

下面是我在项目里用的连接序列：

// 1. 设置认证模式为WPA2-PSK NDIS_OID authOid; authOid.Oid = OID_802_11_AUTHENTICATION_MODE; authOid.Value = AUTH_WPA2_PSK; DeviceIoControl(hNdis, IOCTL_NDIS_OID, &authOid, sizeof(authOid), NULL, 0, &ret, NULL); // 2. 设置加密方式为AES authOid.Oid = OID_802_11_ENCRYPTION_STATUS; authOid.Value = Ndis802_11Encryption3Enabled; // AES DeviceIoControl(hNdis, IOCTL_NDIS_OID, &authOid, sizeof(authOid), NULL, 0, &ret, NULL); // 3. 设置目标SSID // 注意驱动在关联时会把SSID和已有的密钥匹配，顺序不能反 authOid.Oid = OID_802_11_SSID; memcpy(authOid.Value, szSsid, strlen(szSsid)); DeviceIoControl(hNdis, IOCTL_NDIS_OID, &authOid, sizeof(authOid), NULL, 0, &ret, NULL); // 4. 设置预共享密钥 authOid.Oid = OID_802_11_WPA_PSK; memcpy(authOid.Value, szKey, strlen(szKey)); DeviceIoControl(hNdis, IOCTL_NDIS_OID, &authOid, sizeof(authOid), NULL, 0, &ret, NULL); // 5. 触发重新关联 authOid.Oid = OID_802_11_RELOAD_DEFAULTS; DeviceIoControl(hNdis, IOCTL_NDIS_OID, &authOid, sizeof(authOid), NULL, 0, &ret, NULL);

这里有几个参数值得说明：OID_802_11_AUTHENTICATION_MODE的值必须和WZC服务期望的枚举一致，不同SDK头文件可能差异，最好在驱动源码里找定义核对。OID_802_11_ENCRYPTION_STATUS设置成AES，但有些老驱动只认Ndis802_11Encryption2Enabled（即TKIP），你却要连一个只支持WPA2-AES的AP，那就会一直失败。如果AP同时支持TKIP/AES，可以先选TKIP调通，再切换AES验证。

4.3 连接状态的轮询与超时处理

连接是异步的，发出关联请求后不能马上认为成功。我习惯的做法是每隔300ms查一次OID_802_11_ASSOCIATION_INFORMATION，最多等10秒。若超时，就先断开，再重新配置SSID。这是因为驱动在失败状态机里可能卡住，重新触发扫描会更快恢复。

轮询代码如下：

// 查询关联状态，循环10次，每次300ms for (int i = 0; i < 10; i++) { NDIS_OID assocOid; assocOid.Oid = OID_802_11_ASSOCIATION_INFORMATION; memset(&assocOid, 0, sizeof(assocOid)); DWORD ret = 0; BOOL ok = DeviceIoControl(hNdis, IOCTL_NDIS_OID, &assocOid, sizeof(assocOid), &assocOid, sizeof(assocOid), &ret, NULL); if (ok && assocOid.Value) { // Value里包含了关联成功的BSSID和速率集合 break; } Sleep(300); }

这个循环里最容易被忽视的是assocOid.Value的类型，它不是DWORD，而是一个指向NDIS_802_11_ASSOCIATION_INFORMATION结构体的指针。正确做法是先查询大小，再申请缓冲区。如果直接使用栈上的assocOid，驱动写入时可能越界，导致系统崩溃。很多项目里“WiFi连接后系统重启”的病根就在这。

5. 避坑指南：WinCE WiFi调试中的五个高频翻车点

WiFi在WinCE上是最容易产生玄学问题的模块。下面五条都是我自己踩过、也看到身边同事踩过的坑，每条按“现象→原因→解决”写，方便你对着排查。

5.1 现象：驱动加载成功但扫描不到AP

驱动初始化打印正常，控制面板显示无线网卡符号，但扫描列表永远是空的。原因通常有两个方向：一是射频前端供电没打开。我用某模组时，驱动要求先通过GPIO拉高功放使能脚，但BSP的GPIO复用表把该脚配成了普通输出，导致天线口没信号。二是扫描信道被限制。有些驱动默认只扫描1-6信道，而AP在11信道，自然扫不到。解决方法是给驱动加一个信道集配置项，在注册表里指定"ChannelMask"=dword:0x07FF把11个信道全打开。

5.2 现象：连接成功但Ping不通网关

连接状态显示关联成功，IP地址也拿到了，但往网关一个包都发不出去。这个问题很隐蔽，我排查了两天才发现是NDIS中间层驱动的封包格式不匹配。WiFi驱动的发送缓冲区要求带8字节的头部，记录带无线电尺寸（Radio Header），而系统TCP/IP下发的是普通以太网帧。如果驱动没有正确设置NDIS_MAC_OPTION_NO_LOOPBACK或者Medium类型错误的处理，报文就会被网卡丢弃。解决方法是检查驱动初始化时是否正确上报了NdisMedium802_11，并且OID_GEN_MAC_OPTIONS里有没有声明NDIS_MAC_OPTION_COPY_LOOKAHEAD_DATA。

5.3 现象：睡眠唤醒后WiFi掉线且无法重连

这是WinCE电源管理的老毛病。系统休眠时，WiFi模组被断电，唤醒后驱动没有重新下载固件，寄存器状态全丢，导致扫描、关联全部异常。原因在于驱动没有实现IOCTL_NDIS_PM相关的电源回调，或者PowerHandler里只是清了标志位，没重做初始化。解决方法是强制在唤醒后重新调用MDL加载流程。一个不体面但有效的办法是：在唤醒函数里卸载驱动再重新加载，我后来因为时间紧，直接在OAL里退出休眠时对WiFi模组执行一次硬件复位。从那以后每次退出休眠，我都强制走一遍复位和重新初始化，再没出现过“网卡假死”。

5.4 现象：WZC老是弹出密码错误

密码完全正确，但WZC配置工具一连接就报密码错误。这种问题多半是驱动收到的密钥不是ASCII而是宽字符。WZC在WinCE里处理配置文件时，会把密钥转换成宽字符再调用WZC API，驱动如果把它当作窄字符直接复制，字节序就乱了。解决方法是检查驱动里对OID_802_11_WPA_PSK的处理，强制以字节方式拷贝，并且在拷贝前检查KeyLength是不是字节数而不是宽字符数。另外一个常见点是密钥尾部的Null终止符，多传或漏传都会让握手失败。

5.5 现象：升级系统后WiFi速率掉到1Mbps

有一次我在新Build的内核上测试WiFi，发现上传速率只有1Mbps，下载却正常。查了半天发现是系统把无线网卡当成了普通以太网卡，ndis库分配的发送描述符长度不对，导致它不断重传。原因很可能是新SDK的NDIS版本升级了，驱动还在用旧的封包方式。解决方法是重新检查驱动源代码里所有NDIS_PACKET的结构体定义，确保和当前SDK头文件一致。还有一个可能：天线分集被禁止。如果模组支持两个天线接口，驱动里有一个AntennaSelection值默认设为0，只使用了主天线。而你的板子在远距离场景下第二路天线信号更好。把注册表里"Antenna"=dword:2打开，速率就恢复了。

6. 验证连接与进阶技巧：脚本化测试与抓包定位

把WiFi调通只是第一步，产品交付前你需要证明它在各种环境下都稳定。我常用三种手段：脚本化连接测试、抓包看握手、调整漫游参数。

6.1 用批处理循环做连接稳定性测试

在WinCE设备上写一个循环脚本，反复断开、重连、Ping网关，能快速暴露驱动和电源管理的问题。WinCE自带命令行工具ping.exe和ifconfig.exe，但没有“无线扫描”的命令行工具，你得先用自己写的OID工具扫描到AP，再用WZC配置连接。脚本内容可以这样写：

@echo off rem 循环10次，每次连接后ping网关，记录结果 set /a count=0 :loop if %count% geq 10 goto end echo === round %count% === cmd /c "wzctool connect SSID=MyCorpNet key=12345678" ping -n 3 192.168.1.1 set /a count+=1 sleep 5 goto loop :end echo done

这个脚本里wzctool是我自己写的一个命令行辅助程序，内部调用WZC API。ping -n 3表示发3个包，这些参数在WinCE的ping命令里都有。要注意的是，WinCE的批处理不支持%的延迟展开，所以计数器变量用set /a可以，但每次循环都会读到新值。如果你在循环里用了for，就得注意变量展开规则。

6.2 抓包看EAPOL四步握手

当连接认证失败时，抓包是最直接的定位手段。WinCE平台可以用微软Network Monitor的远程抓包工具，但驱动兼容性不太好。我用的是在AP端用有线抓包镜像WiFi报文，或者在WinCE上用第三方抓包驱动。抓包重点看EAPOL帧：如果只看到EAPOL-Start，没有AP回应的EAPOL帧，说明AP根本没收到你的报文，多半是信道或加密参数不对。如果看到EAPOL 1/4和2/4，但没有3/4，问题通常出在密钥交换上，检查MIC校验。我遇到过驱动把PMK算错的情况，后来在驱动源码里临时加了打印，把EAPOL的成对密钥导出，和PC计算的值对比才找到问题。

6.3 漫游阈值调整的技巧

如果你的设备需要在多个AP之间移动，WinCE默认的漫游触发信号阈值是 -75dBm，这个值偏保守。在室内空旷环境，可能直到信号已经差到丢包才触发扫描。调优时可以借助OID_802_11_ROAMING_THRESHOLD把阈值提高到 -65dBm，但要注意，阈值太高会导致频繁漫游，反而时断时续。我最终的做法是两级阈值：当信号低于 -70dBm 时先增加扫描间隔，低于 -80dBm 时才切换AP。这样既保留了漫游能力，又避免了乒乓效应。

漫游参数设置示例：

NDIS_OID roamOid; roamOid.Oid = OID_802_11_ROAMING_THRESHOLD; roamOid.Value = -70; // 单位是dBm，注意是负数，类型是signed DeviceIoControl(hNdis, IOCTL_NDIS_OID, &roamOid, sizeof(roamOid), NULL, 0, &ret, NULL);

设置这个参数后，驱动会在信号电平低于阈值时自动发起后台扫描。注意roamOid.Value是有符号整数，写入时需要把负数语义保留好，很多人在这里把它当无符号数，结果设置成了失败值。

那次调机结束后，我把所有经验写进了一份环境搭建和调试手册，从那以后每次拿到新板子，我都会先按“注册表→驱动扫描→连接→抓包验证”的顺序强制走一遍，这套流程直接让后面的项目少走了好多弯路。希望帮到你。

本文还有配套的精品资源，点击获取