USB Connect Failed : cdc_subset and netdev timeout usb0

There is currently an issue in the usb gadget driver that makes the usb appear on boot for a short period, then deactivate and then appear again.
It is very tricky since it all points to it being a kernel driver issue (on the dwarf side)

If you boot the dwarf without it being connected to the PC, and only connect once it finishes booting up, all should work.
Can you confirm please? Thanks

2 Likes

As per steps above, I was actually booting Dwarf/Laptop, and then connecting cable… and it wasn’t working. Re-verified now, that letting Dwarf boot (USB cable disconnected), and then plugging in is not working here.

What I don’t really understand is how ping works to 192.168.51.1, and nmap can see the various open ports (22,80 and 8081), but pointing a browser to 192.168.51.1 doesn’t work, and neither does SSH-ing in via port 22…

Does the cdc probe error logically explain that?

(Also, is there any easy place to share diffs (in the git diff sense) with yee? I’m diffing dmesg output to just strip to the interesting parts - would be nice to easily share them?)

Full boot, then connect USB cable dmesg output: Dwarf USB 1st Connect After Full Boot - Pastebin.com
Multiple-replugs without rebooting MOD: Dwarf USB Multi Replugs - Pastebin.com

On the full-boot, then connect dmesg output, notice this

+[ 2033.824517] cdc_subset: probe of 1-1:2.0 failed with error -22
+[ 2033.825805] cdc_subset 1-1:2.1 usb0: register 'cdc_subset' at usb-0000:00:14.0-1, Linux Device, d2:1a:ac:66:58:46
+[ 2033.825860] usbcore: registered new interface driver cdc_subset

bit in particular - the cdc probe error occurs, but it does register a new interface for cdc_subset.

In the multi-replug case, it does this instead

+[ 2603.078512] cdc_subset: probe of 1-2:2.0 failed with error -22
+[ 2603.079979] rndis_host 1-2:2.0 usb0: register 'rndis_host' at usb-0000:00:14.0-2, RNDIS device, 3a:b4:a2:a4:af:5c

which has the cdc_subset error, but then does NOT register a cdc interface.

So indeed it seems like 1st plug vs re-plugs does make a difference here. Perhaps this was already known - just stating my findings/learnings.

I’ll try on a Windows machine, and see how that goes, -Harry

Update: Win10 machine, plug and play confirmed. This seems to be an issue with my Linux/Ubuntu 20.10 laptop only. Replugging (while still booted) and clicking the “Reload” purple button in the UI working to refresh & reconnect successfully.

After using with the Win10 machine, I tried connecting to a Linux laptop. Linux has same issue as above, with cdc_subset probe error, ping working, but no UI or SSH available.

Upon re-plugging into the Win10 machine after connecting to Linux (with Dwarf still powered-on), Windows is now also not working!dwarf_usb_malfunc

So I guess that plugging into Linux (vs Win10) causes something different to occur on the Dwarf side, which causes it to freeze up/malfunction on Win10 later too.

Confirmed that a reboot of the Dwarf and plugging into Win10 is plug&rock again.

1 Like

Renamed topic (removing [Linux]) to make the issue more generic, as windows also saw errors. Another Windows error was reported in the discussion of this thread: 404 for Quistart and problems connecting to browser - #6

1 Like

Hi Harry.

Can you try with the USB MODE set to NET+MIDI and see if the issue is still present?
At least it should change in behavior a bit.

So,after changing usb to net and midi the behavior changed a bit. Now if got a device called cdc ecm (error code 28 - The drivers for this device are not installed)

If you put it as default, you should be able to get it to work with https://modclouddownloadprod.blob.core.windows.net/shared/mod-rndis-driver-windows.zip

For more info Troubleshooting Windows Connection - MOD Wiki

EDIT: for windows you should use the last option. Windows does not support the 2nd/middle one.

Hello, unfortunately I had already tried this without success. Windows tells me that it can not find a suitable driver, although I have specified the directory in which the drivers you mentioned.For me it does not appear under com&lpt but under other devices and is called CDC ECM. (but only after I have set the Dwarf to USB and Midi).

The NET+MIDI option does not, and will not ever, work on Windows. This is known and not fixable.
It is either the 1st option (which is default) or the last one for the Windows compatibility mode.

1 Like

With option 1 and 3 I have in both cases the error 23 (unknown USB device in the category USB controller). I cannot install the mentioned driver because Windows 10 thinks that the best driver is already installed. So the solution from the wiki unfortunately does not work for me. I have tried all the methods like deactivate, delete, cable out and in, reboot the computer, reboot the Dwarf, restart Dwarf and only then plug it in and so on without success. Does anyone have any other solutions?

Interestingly, I have already had success with a Windows computer. However, the Windows had not been updated for 1 to 1.5 years. After the part has updated itself, it has unfortunately disassembled the installation there. With current Windows10 systems (19042.746) I have the same problem everywhere.

@falkTX, yes I can test another USB mode with Linux. Updated to v1968, switched USB-B mode in Device-settings (2/2) to NET+MIDI. (Cable was unplugged at this point).

Connecting cable, i see the same dmesg output (with cdc probe error):

[62579.615177] usb 1-2: new high-speed USB device number 45 using xhci_hcd
[62579.765424] usb 1-2: New USB device found, idVendor=0525, idProduct=a4a2, bcdDevice= 5.10
[62579.765427] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[62579.765429] usb 1-2: Product: Dwarf Ethernet
[62579.765431] usb 1-2: Manufacturer: Linux 5.10.10-rt24-moddwarf with ff300000.usb
[62579.767853] cdc_subset: probe of 1-2:2.0 failed with error -22
[62579.769495] rndis_host 1-2:2.0 usb0: register 'rndis_host' at usb-0000:00:14.0-2, RNDIS device, c2:6b:7e:81:2b:e9

Gonna reboot both the MOD and the Linux machine now, wait for boot to complete on both, and connect cable. Result is 2nd probe error, this time on the rndis_host path. Dmesg output

[HVH] WARNING: ON REBOOT MOD reset to "network default", so this output was *NOT* with NET+MIDI. See next dmesg output for that!!
[   34.037218] usb 1-2: new high-speed USB device number 4 using xhci_hcd
[   34.187282] usb 1-2: New USB device found, idVendor=0525, idProduct=a4a2, bcdDevice= 5.10
[   34.187285] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   34.187286] usb 1-2: Product: Dwarf Ethernet
[   34.187288] usb 1-2: Manufacturer: Linux 5.10.10-rt24-moddwarf with ff300000.usb
[   34.267383] usbcore: registered new interface driver cdc_ether
[   34.268133] cdc_subset: probe of 1-2:2.0 failed with error -22
[   34.269341] cdc_subset 1-2:2.1 usb0: register 'cdc_subset' at usb-0000:00:14.0-2, Linux Device, fa:fd:48:08:27:67
[   34.269390] usbcore: registered new interface driver cdc_subset
[   34.269503] rndis_host: probe of 1-2:2.0 failed with error -16
[   34.269518] usbcore: registered new interface driver rndis_host

Next steps:

  1. How can I confirm that NET+MIDI mode is active?
  2. Should there be a cable connected when changing this setting on the Dwarf?
  3. Should I see different dmesg output?
  4. If the cdc_subset probe failed with -22 dmesg output is listed, is it expected not to work? (Aka, do I have to test each time (like I am now…) or is just the dmesg crc probe fail enough to know its broken?)

Changing this mode requires reboot. Just click once over the USB-MODE and the device will ask if it is okay to reboot.

If you want to really confirm that this works, just check the files inside the system, in /data/
Should be obvious if you have something like “enable-usb-composite-gadget” file in there.
boot activates different things depending on what is present.

I think the reboot-needed led to some confusion here.

1 Like

After a reboot into NET+MIDI mode, dmesg says

[ 3063.257084] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3063.257086] usb 1-2: Product: MOD Dwarf
[ 3063.257087] usb 1-2: Manufacturer: MOD Devices
[ 3063.257088] usb 1-2: SerialNumber: 00001
[ 3063.262330] cdc_ether 1-2:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-2, CDC Ethernet Device, 12:00:00:ff:ff:ff
[ 3063.300561] cdc_ether 1-2:1.0 enx120000ffffff: renamed from usb0
[ 3063.316198] usbcore: registered new interface driver snd-usb-audio

At this point, ping works to the device, but ssh does not, neither does the UI load in the browser when pointed at 192.168.51.1. (I’ve not had moddwarf.local work yet, so I’m trying the raw-IP route to simplify).

Upon cable unplug, it says:

[ 3169.042453] usb 1-2: USB disconnect, device number 6
[ 3169.042653] cdc_ether 1-2:1.0 enx120000ffffff: unregister 'cdc_ether' usb-0000:00:14.0-2, CDC Ethernet Device

That all seems ok, however on re-connect (no reboot of Linux/MOD), I get

[ 3269.414562] usb 1-1: new high-speed USB device number 8 using xhci_hcd
[ 3269.564462] usb 1-1: New USB device found, idVendor=1d6b, idProduct=0104, bcdDevice=32.10
[ 3269.564464] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3269.564466] usb 1-1: Product: MOD Dwarf
[ 3269.564467] usb 1-1: Manufacturer: MOD Devices
[ 3269.564468] usb 1-1: SerialNumber: 00001
[ 3269.568315] usb 1-1: can't set config #1, error -32

So although it doesn’t show the cdc subset probe error, the NET+MIDI mode does not work on replugging in again.

Gonna do two full reboots now, and re-test to be certain.
[Update: Reboots done, same results].

Just to verify, These are my steps:

  1. boot linux laptop
  2. boot dwarf
  3. wait until dwarf is showing home screen (twiddle a knob to ensure its alive : )
  4. connect cable
  5. Check dmesg outputs
  6. run sudo ifconfig <eth_name> 192.168.51.23 (eth name was usb0 in default Network mode, but now gets renamed by OS from usb0 to enx120000ffffff).
  7. Run ping 192.168.51.1 to check connection
  8. Run ssh 192.168.51.1 to check if login is possible
  9. Run browser at 192.168.51.1 to try open MOD page

Very odd.
So it ought to work at least when first plugged in.

That ifconfig is missing an “up” argument at the end though, no?

Also for ssh, you should use root@192.168.51.1

ifconfig was missing an up, yes correct it was. Re-tested, same issue still exists.

Yes for actually “getting in” the root@ was missing in, however just to test connectivity the above command is enough. Good to be clear for future readers though.

Wondering what the roadmap looks like to fix this issue. If I’m right, this issue is likely to be seen by all Linux users/kickstarter-backers?

Context: I can’t use Dwarf on my Linux PC at all right now - have to use Windows. That limitation does not make me happy… :slight_smile:

you are the only one I know that has this issue.

so technically, I do not know how to start to debug this.

OK - I thought you had seen previous issues (but not 100% reproducible?).

Anyway - that means that perhaps this laptop has a strange network config.
Its a pretty-much standard Ubuntu 20.10, with a different desktop running (Lubuntu, with my DWM setup on top). Didn’t change any of the network backend/config stuff… so would expect it to work transparently.

Are linux users expected to have to run sudo ifconfig <dwarf_ethdev_name> 192.168.51.1 up?
Without that, I can’t even ping the Dwarf. With that command, ping and nmap work fine, but ssh and web UI don’t work as expected…

DMesg (with NET+MIDI mode) doesn’t show issues with latest build:

[  347.485978] usb 1-2: new high-speed USB device number 6 using xhci_hcd
[  347.636138] usb 1-2: New USB device found, idVendor=1d6b, idProduct=0104, bcdDevice=32.10
[  347.636141] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  347.636142] usb 1-2: Product: MOD Dwarf
[  347.636144] usb 1-2: Manufacturer: MOD Devices
[  347.636145] usb 1-2: SerialNumber: 00001
[  347.641591] cdc_ether 1-2:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-2, CDC Ethernet Device, 12:00:00:ff:ff:ff
[  347.654491] cdc_ether 1-2:1.0 enx120000ffffff: renamed from usb0

So it seems the cdc_error can be ruled out with this config/build: but the problem remains - why doesn’t it work as expected?