The root cause of this problem is an unfortunate choice made in the Linux kernel a very long time ago. In contrast to most other systems, Linux will not always use the first available configuration if a device supports multiple alternatives. Linux prefers configurations with class functions over configurations with vendor specific functions (only the first function of each configuration is considered in case of a multi-function device). The background is probably the complete lack of support for vendor defined functions when this code was written. The problem today is that we cannot change it without breaking expected behaviour for all the devices and users having adapted to this.
The different configurations have a "C" prefix in the "devices" dump. Functions (or actually interfaces) are prefixed with "I". The active choices are marked with *
The failing device supports three configurations with one function each::
- vendor class, supported by the r8152 driver
- CDC NCM ("Network Control Model") class
- CDC ECM ("Ethernet Control Model") class
Your working device supports two configurations with one function each:
- vendor class, supported by the r8152 driver
- CDC ECM ("Ethernet Control Model") class
Give what I wrote above, we expect Linux to choose configuration #2 in both cases, ending up with an NCM device in the first case and an ECM device in the second. And this is what happens when Linux probes these devices.
Why is the second device then using configuration #1 supported by the r8152 driver? Because something has changed it back to that configuration after the initial probing. This "something" is the r8152 driver. The problem with that is that the r8152 driver doesn't support this device unless it's in configuration #1.
And now we finally get to the explanation why it works in one case and not in the other: To work around that problem, the r8152 driver pretends to support CDC ECM class devices too, provided they have a matching device ID. But tthe driver dioesn't pretend to support CDC NCM devices, which makes the hack fail to work with the first device.
Pretending to support a function just to get a chance to modify the USB device is a horrible hack and has always been so.. To make it fly, they also had to blacklist these devices in the CDC ECM class driver - causing that driver to carry a loing list of blacklisted device IDs. And even worse: Forcing that driver fail with these devices.
I'm really hoping we can avoid extending this hack to the CDC NCM driver. Or maybe that's too late? I don't follow the USB discussions closely anymore. Probably should...
Anyway, long story. Short solution: You should be able to make your device work with the r8152 driver by simply switching it to configuration #1. You can do that from the command line by something like
echo 1 >/sys/bus/usb/devices/1-1.3/bConfigurationValue
provided it is plugged into the same USB port you showed us above. Otherwise you'll have to adapt the 1-1.3 to the bus and port where the device is.
In theory, the device should also work as an NCM device if you install kmod-usb-net-cdc-ncm. But I assume there is a reason these devices want to be handled as vendor specific, and that you will lose some functionality with the class drivers.
Note that neither of these devices will work as ECM devices due to the mentioned blacklisting.
I believe it's time to figure out some generic and better workaround for this problem....