RNDIS errors on IMXRT1050-EVK: skipping garbage

[maaikez]

We want to enable RNDIS in our project, but since Zephyr 3.7, we have problems with RNDIS. In Linux, when connecting the device, we see skipping garbage in the dmesg log. The Zephyr main branch shows the same.

To test this, I used the zperf sample (samples/net/zperf), changed the overlay-netusb.conf so it does not use ECM but RNDIS:

CONFIG_USB_DEVICE_NETWORK_RNDIS=y
instead of
CONFIG_USB_DEVICE_NETWORK_ECM=y

For Zephyr 4, I built with:

west build -p always -b mimxrt1050_evk/mimxrt1052/qspi zephyr/samples/net/zperf -DOVERLAY_CONFIG="overlay-netusb.conf"

I also enabled dhcp and I do not get an IP address with RNDIS, but with ECM I do.

dmesg for RNDIS:

[13150.734330] usb 5-1.1.2.3: new high-speed USB device number 53 using xhci_hcd
[13150.837579] usb 5-1.1.2.3: New USB device found, idVendor=2fe3, idProduct=0100, bcdDevice= 4.02
[13150.837592] usb 5-1.1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[13150.837596] usb 5-1.1.2.3: Product: USB-DEV
[13150.837599] usb 5-1.1.2.3: Manufacturer: ZEPHYR
[13150.837602] usb 5-1.1.2.3: SerialNumber: 500100C53D1649D2
[13150.900600] rndis_host 5-1.1.2.3:1.0: skipping garbage
[13150.903354] rndis_host 5-1.1.2.3:1.0 wwan0: register 'rndis_host' at usb-0000:07:00.4-1.1.2.3, Mobile Broadband RNDIS device, 00:00:5e:00:53:01
[13150.928662] rndis_host 5-1.1.2.3:1.0 wwx00005e005301: renamed from wwan0

It is also strange that it is 'renamed from wwan0'.

For comparison, this is the dmesg log for ECM:

[12997.138393] usb 5-1.1.2.3: new high-speed USB device number 52 using xhci_hcd
[12997.239879] usb 5-1.1.2.3: New USB device found, idVendor=2fe3, idProduct=0100, bcdDevice= 4.02
[12997.239889] usb 5-1.1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[12997.239893] usb 5-1.1.2.3: Product: USB-DEV
[12997.239896] usb 5-1.1.2.3: Manufacturer: ZEPHYR
[12997.239899] usb 5-1.1.2.3: SerialNumber: 500100C53D1649D2
[12997.302170] cdc_ether 5-1.1.2.3:1.0 eth0: register 'cdc_ether' at usb-0000:07:00.4-1.1.2.3, CDC Ethernet Device, 00:00:5e:00:53:01
[12997.331981] cdc_ether 5-1.1.2.3:1.0 enx00005e005301: renamed from eth0

We tried to analyze the USB messages with a USB sniffer and get a lot of Invalid PID Sequence errors (mostly Unconfigured Device (0) (BusIdx:0)).

Is there something wrong with the RNDIS implementation or is it a wrong configuration?

[maaikez]

If I revert two commits:

d7cf297
3055a83

then it seems to work again (?).

How can I find the discussion that belongs to those commits? I'd like to know why they are done.

[DerekSnell]

How can I find the discussion that belongs to those commits? I'd like to know why they are done.

Hi @maaikez ,
I have not yet looked into this issue, but those commits are part of this pull request #54611 from @GeorgeCGV . You can read more about the change and Issue it resolved there.

Best regards

[maaikez]

Hello Derek,

Thank you for your response, I didn't find that discussion yet indeed.

Unfortunately, after this change, like I said, RNDIS is not working on Linux anymore.

[maaikez]

With the above changes, Windows indeed sees the device as RNDIS. However, it does not work in Linux anymore.

https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/supported-usb-classes

In this link, Microsoft recommends using NCM (the old situation). So I'm wondering why this change is done (and if we can't just revert it).

[GeorgeCGV]

@maaikez, the changes were implemented to have at least one network USB class working on Windows "out of the box". Linux can easily use ECM, while RNDIS is primarily used on Windows & Mac (didn't test that one). At the time, the NCM was not available in the old USB stack (still isn't).

[maaikez]

@GeorgeCGV Thank you for the explanation. So it actually means with this change, it indeed does not work in Linux anymore? So that was intended?

I saw indeed that NCM was added later, but we are still on 3.7.1 so NCM is not yet an option. Good to keep it in mind for the future though.

[GeorgeCGV]

@maaikez unintentional, the Linux part wasn't tested because it usually relies on ECM. The NCM is supported in the new USB stack.

A bit of a dilemma: reverting the changes fixes Linux but breaks Windows, requiring Windows users to manually set the RNDIS driver to the device (if they have the rights). However, if we don't revert, Linux users are forced to manually bind the device to a specific driver (i.e, via udev) or use a fully working ECM.

One alternative, likely the most appropriate, is the development of a composite device that supports multiple configurations, specifically RNDIS and ECM.

[maaikez]

Thank you for your explanation!