Thanks for the feedback @knc1,
I have pulled the zip archive and published a second version of the package.
To me it's not as huge an issue as stated because the private key is passphrased with a long enough password, but I understand what you mean and generated a fresh set of keys to sign the driver and did not distribute the private key this time
As for it being the normal procedure, that's what I thought before I actually tried; I previously "forced" the RNDIS driver for a tethered android phone in Windows 7 and it worked. However, I don't know if you have a W10 system lying around to test, but if I want to change the driver for this #!@*@ COM port device, unticking the "Show compatible hardware" checkbox won't let me select the RNDIS built-in driver.
It's possible Windows enacts some kind of enforcement and won't allow to set the driver for some unknown VID/PID couple. If you can provide some insight here, I'd gladly take it.
EDIT: the problem is mentioned at the
MS forums. Apparently dlech on Sept 1, 2015 nails it:
Quote:
|
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.
|
Apparently, I provide a mix of solutions 3 & 4 (custom inf + self-signed).