问题描述
我的 USB CDC-EEM 设备与运行 RaspBerry Pi OS (Debian) 的主机配合良好。但是当我尝试将此设备连接到运行 Microsoft Windows 10 的 PC 时，即使 USB 设备配置良好并开始运行，通信也会失败。
这里的第一个区别：如果 USB 设备没有正确响应 SET_CONTROL_LINE_STATE (0x22) CDC 类请求，Windows EEM 驱动程序将停止，Linux 驱动程序不需要启动。
但即使在 Windows 驱动程序成功启动并调出虚拟 NIC 后，以太网帧的通信似乎也中断了。
捕获 BULK OUT 流量（从 Win10 发送到我的设备的数据包），我们可以看到例如以下 USB 传输：
0000 00 52 33 33 f0 24 8c 11 76 50 47 a3 29 28 86 dd .R33....vP...(..
0010 60 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00 `.....:.........
0020 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 ................
0030 00 00 00 01 ff 04 9c 01 87 00 f9 d8 00 00 00 00 ................
0040 fe 80 00 00 00 00 00 00 4c dd a0 65 5d 04 9c 01 ........L..e]...
0050 de ad be ef ....
重要的是前 2 个字节（0x00、0x52），其中应包含有效的 EEM 数据包标头，如 CDC EEM 规范修订版 1.0，第 5.1.2.1 章所指定。 Windows 驱动程序似乎使用了不同的字节序。实际上是大端 (BE)，而 Linux 内核驱动程序使用小端 (LE)，可以在这里阅读：
/* EEM packet header format:
* b0..13: length of ethernet frame
* b14: bmCRC (1 == valid Ethernet CRC)
* b15: bmType (0 == data)
*/
len = skb->len;
put_unaligned_le16(BIT(14) | len,skb_push(skb,2));
似乎微软的开发者决定使用 BE，因为以太网帧有效载荷也使用了 BE。例如。 CRC 标记值 (0xDEADBEEF) 也使用 BE 存储。但这是以太网标准的一部分，而不是 CDC-EEM 或 USB。 CDC-EEM 规范不是很严格，但我将其解释为使用 LE：CDC-EEM 规范第 5.1.1 章指的是 [USB2.0] 8.4。 USB 规范定义使用 Little Endian (LE) 作为默认值，可以在第 8.1 章中阅读：
Multiple byte fields in standard descriptors,requests,and responses are interpreted as and moved over the
bus in little-endian order,i.e.,LSB to MSB.
现在我不确定是否...
如果可以等待从主机接收到的第一个以太网帧，那么从前 2 个字节检测字节序应该是一件容易的事。我认为只有少数情况是模棱两可的。但结果是，在成功检测到字节序之前，不可能将任何以太网帧传输到主机。或者使用“使用 USB 指纹识别的主机”（https://ieeexplore.ieee.org/document/6159115）并根据主机操作系统更改字节顺序也是可行的。但所有这些解决方案都带有一些肮脏的解决方法的味道。
最后，很难相信微软没有以某种方式验证他们的驱动程序。也许有一些 USB EEM 设备可以实际使用 BE 字节序？
我的 Windows 操作系统显示以下驱动程序详细信息：
Generic USB-EEM Network Adapter
Driver files: C:\WINDOWS\system32\DRIVERS\usbnet.sys
Provider: Microsoft Corporation
File version: 10.0.19041.1 (WinBuild.160101.0800)
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）