Hi everyone,
I would appreciate help investigating a regression in the Mudi 7’s built-in USB networking function.
Affected feature: The Mudi 7 shares its LAN/internet connection to a Windows PC over USB, using the router’s built-in RNDIS function. This is not a phone providing a USB WAN connection to the router.
Upgrade route and observed behavior
I upgraded to 4.10.0 through the Mudi 7’s built-in online update / OTA mechanism on 1 September 2026. I did not manually download and flash a beta image.
With 4.10.0, the Windows RNDIS device fails to start with Code 10, and USB networking is unusable. The issue also reproduces under stock settings.
Returning the same router to 4.8.5 release2, using the same respective cables and USB ports, restores operation on both Windows computers.
Test systems
| Computer | 4.10.0 | 4.8.5 release2 |
|---|---|---|
| Windows 11 workstation — Pro 25H2, build 26200.9168 | RNDIS Code 10; no usable USB networking | Device starts and USB networking works; diagnostic verification is included |
| Windows 11 24H2 laptop — Pro 24H2, build 26100.7462 | Same Code 10 failure | Networking restored; these are my test observations |
The physical connection is USB-A on the PC to the Mudi 7’s data-capable USB-C port.
On the workstation, the recorded driver is Microsoft rndiscmp.inf, version 10.0.26100.1, automatically bound. The device reports VID_2C7C / PID_0133, with CM_PROB_FAILED_START and Kernel-PnP status 0xC0000001.
The successful post-downgrade verification includes a connectivity test sourced from the USB adapter’s address, successful DNS, and rndis0 traffic counters—not just successful USB enumeration.
Firmware identification and diagnostic limits
The working firmware is:
e5800-4.8.5_release2-996-0603-1780458650
My retained record of the failing firmware shows glversion = 4.10.0; its full release/build suffix has not yet been recovered. I would appreciate GL.iNet’s help identifying the corresponding OTA build so the correct versions can be compared.
The report includes RNDIS/IPA-related kernel errors from separately labelled capture windows. They are investigation leads, not a complete continuous trace or a proven root-cause explanation.
Support request
I emailed GL.iNet support on 8 September 2026, attaching English and Chinese reports and diagnostic evidence. I am posting here to ask whether anyone has encountered the same problem and to help connect the report with the appropriate E5800 team.
Could the E5800 USB/RNDIS team please investigate this firmware-dependent failure and advise on a 4.10.x fix or official interim patch? Downgrading restores operation on my setup, but I would appreciate a fix in the newer firmware.
If the team cannot reproduce it, the exact firmware build, Windows version, and USB connection used for their test would help us compare environments.
Thank you for any guidance or assistance.