Windows 10 vs Remote NDIS - Ethernet USB/Gadget not recognized

I'm using a similar "Linux USB Ethernet/RNDIS Gadget" device. On Windows 7/8/10, it is detected and windows installs an Acer RNDIS driver, which does not work and causes the Network and Sharing center to lock up.

In Windows 7/8, I was able to select the "Microsoft Corporation" "Remote NDIS Compatible Device" driver (via Device Manager, right-click and select "Update Driver...") and get it working. Presumably, this is the same driver as the C:\Windows\INF\rndiscmp.inf mentioned above. However, this is not listed even when you uncheck "Show Compatible Drivers" in Windows 10. I wonder if maybe there is another way to install drivers, e.g. via PowerShell?

If have the same problem with a BEAGLE board like device.

It is exactly the same behavior, tested on two machines (Windows 10 Pro German 32 and 64 bit, but in test mode, 32 bit machine with internet connection and running on latest patch level)

But I found a new device in device manager:

"Serial USB-Device (COM3"

or in German

"Serielles USB-Gerät (COM3)"

Up to now I wasn't able to convince Windows, that this is an network card....

Indeed, same with my ODROID, havent recognized that, or it came with the latest Windows 10 patch which claimed to do something with rndis. 

I extended my tests.

1st Setup: Windows 10,  GE,  64 bit,  no patches, not registered. Guest on ESXI 5.5 server with VMware workstation 10> FAIL

2nd Setup: Windows 10 GE 64 bit latest patches, not registered. Guest onVMware workstation 11> FAIL

3rd Setup: Windows 10 En 64 bit latest patches, registed. Guest on Visual Box > OK

4th setup: Windows 10 EN 64 bit, latest patches, registed. Dell latitude > OK

Conclusion: Is there an issue with Windows 10 guest OS and VMware?

Could you confirm this?

I have the same problem here (also with BeagleBone Black). Running Windows 10 Pro German x64.

Till now I was not able to solve this. Can not get Windows to detect it as RNDIS Network Interface. In Windows 7 and 8.1 the same board was working without a problem and RNDIS was detected.

UPDATE:

I've done some more poking around and have found a few possible "better" solutions.

First, some more insight: The Linux rndis gadget function has USB class of 2 and subclass of 2, which matches "USB\Class_02&SubClass_02" in the usbser.inf file. This is why for some people, their device is initially detected as a COM port instead of RNDIS.

Solution 1: If you are one of the people that found this because your device is showing up as a COM port instead of RNDIS, you may be able to get away using the RNDIS 5.1 driver. Find your device under Ports (COM & LTP) in Device Manager. Right-click it and select Update Driver Software..., then Browse my computer for driver software and then Let me pick from a list of device drivers on my computer and finally choose Remote NDIS Compatible Device. This should install the Microsoft RNDIS 5.1 driver (shows "Acer" as the manufacturer). If this works great. If it causes Network and Settings and other network related things to lock up, then you need the RNDIS 6.0 driver instead. Try one of the other solutions.

Solution 2: If you have control over the RNDIS device and it runs Linux (i.e. BeagleBone), you can tweak the driver to get along with Windows better. For example, if you have a 3.16 kernel or newer, you can setup your gadget using configfs and include os descriptors. This is actually what I ended up doing for my case. You can find my fully documented script here. The key was specifying the compatible and subcompatible ids so that it matches "USB\MS_COMP_RNDIS&MS_SUBCOMP_5162001" in rndiscmp.inf. This causes the Microsoft RNDIS 6.0 driver to be installed for this device. With this driver, I have not seen the same lockup as I have with the 5.1 (Acer) driver. I also changed the vendor and product ids so that it wouldn't match the "Acer" driver.

Solution 3: If the RNDIS 5.1 (Acer) driver is causing problems and you can't modify the remote device, then you can reboot into a mode that allows you to install unsigned drivers. The you can install this unsigned linux.inf file. However, if you reboot without enabling unsigned drivers again, Windows will not load the driver anymore. For a more permanent solution, you could self-sign that .inf file.

Solution 4: This one is for Microsoft (and better than the suggestion below)... Add "USB\Class_02&SubClass_02&Prot_FF" to rndiscmp.inf.

ORIGINAL MESSAGE:

Here is the workaround that I came up with for my particular case. Assuming your device has the same USB Vendor and Product ID's it should work for you. If not, you can modify the .inf file (see link) accordingly.

http://www.ev3dev.org/docs/tutorials/connecting-to-the-internet-via-usb/?os=Windows&os-version=10

It would be really nice if Microsoft could make it so that rndiscmp.inf shows up as compatible with USB\VID_0525&PID_a4a2.

Unfortunatelly this does not work for me for the beaglebone black (Debian and QNX). Thx anyway. Hope Microsoft is Fixing this soon.

EDIT: I stand corrected. It works for Debian! thank you very much!

For me this is working, too.

After a reboot the solution is gone. So this procedure is too painful, so I will not recommend it to my customers.

> It would be really nice if Microsoft could make it so that rndiscmp.inf shows up as compatible with USB\VID_0525&PID_a4a2.

I have another update.

It works for Windows 10 32 bit (where the driver enforcement is not active). It work for Windows 10 64 bit, if you upgrade from Windows 7.

BUT IT IS SOLVED FOR ME!

Microsoft offers the Acer driver for Windows Vista on their website (with IE 6 or higher only) This one works for Windows 10 64 bit:

http://catalog.update.microsoft.com/v7/site/ScopedViewRedirect.aspx?updateid=37e35bd4-d788-4b83-9416-f78e439f90a2

Still it remains: > It would be really nice if Microsoft add this driver for plug & play for Windows 10 64 bit!