[Jetson TX2 NX] USB Gadget issue in Windows Host Machine

I am currently working with an NVIDIA Jetson TX2 NX SOM module, configured as a USB gadget on a Linux system. When I connect this device to a Windows 11 Pro machine, I encounter repeated log messages as shown below:

[ 4063.017258] configfs-gadget gadget: Wrong NDP SIGN
[ 4063.406043] configfs-gadget gadget: Wrong NDP SIGN
[ 4063.775656] configfs-gadget gadget: Wrong NDP SIGN
[ 4063.775746] configfs-gadget gadget: Wrong NDP SIGN
[ 4063.775885] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.535806] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.535917] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.546919] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.547073] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.547280] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.547465] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.547589] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.547968] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.548321] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.548956] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.549205] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.549511] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.549591] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.912840] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.912920] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.963059] configfs-gadget gadget: Wrong NDP SIGN
[ 4064.963210] configfs-gadget gadget: Wrong NDP SIGN
[ 4065.557756] configfs-gadget gadget: Wrong NDP SIGN
[ 4065.557833] configfs-gadget gadget: Wrong NDP SIGN
[ 4065.558061] configfs-gadget gadget: Wrong NDP SIGN
[ 4065.558265] configfs-gadget gadget: Wrong NDP SIGN
[ 4065.558403] configfs-gadget gadget: Wrong NDP SIGN
[ 4065.558666] configfs-gadget gadget: Wrong NDP SIGN
[ 4065.558823] configfs-gadget gadget: Wrong NDP SIGN
[ 4065.559227] configfs-gadget gadget: Wrong NDP SIGN
[ 4065.706458] extcon-gpio-states external-connection:extcon@1: Cable state:0, cable id:0
[ 4065.706483] tegra-xudc-new 3550000.xudc: vbus state: 0
[ 4065.706502] tegra-xudc-new 3550000.xudc: device mode off: 0
[ 4065.707135] tegra-xudc-new 3550000.xudc: ep 3 disabled
[ 4065.707173] tegra-xudc-new 3550000.xudc: ep 2 disabled
[ 4065.707208] tegra-xudc-new 3550000.xudc: ep 5 disabled
[ 4065.707237] tegra-xudc-new 3550000.xudc: ep 4 disabled
[ 4065.707262] tegra-xudc-new 3550000.xudc: ep 7 disabled
[ 4065.707324] tegra-xudc-new 3550000.xudc: ep 9 disabled
[ 4065.707352] tegra-xudc-new 3550000.xudc: ep 11 disabled
[ 4065.707386] tegra-xudc-new 3550000.xudc: ep 6 disabled
[ 4065.707417] tegra-xudc-new 3550000.xudc: ep 13 disabled
[ 4065.707528] tegra-xudc-new 3550000.xudc: active: 1 => 0
[ 4065.707647] android_work: sent uevent USB_STATE=DISCONNECTED
[ 4065.708115] tegra-xudc-new 3550000.xudc: entering ELPG
[ 4065.708213] l4tbr0: port 1(rndis0) entered disabled state
[ 4065.708793] l4tbr0: port 2(usb0) entered disabled state

These messages appear continuously when using the configfs-gadget with Windows 11 Pro. I would appreciate your guidance on specific steps or configurations to resolve this issue, including any potential updates or workarounds.

I don’t personally know anything about the issue. I did see in the kernel source it is a checksum failure related to something which works with a single “NDP”, but fails for the case of multiple “NDP” (an “NTB” apparently contains one or more "NDP"s; when more than one it fails due to the bug in the kernel). I see a patch which is here:
https://lore.kernel.org/all/1401383543-10181-2-git-send-email-jim_baxter@mentor.com/

Within the kernel source it is this file:
drivers/usb/gadget/f_ncm.c

However, I did not see which kernel this applies to. On your Jetson, what is the result of “uname -r”? Which L4T release is it? L4T release can be found via:
head -n 1 /etc/nv_tegra_release

Basically you will need to find the kernel source for your running kernel, and then examine it to see if that patch has already been applied or not applied. Then, if the patch has not been applied, it will involve patching and then rebuilding the kernel (that is something to talk about when you get to it; there are easier or more difficult ways of doing that).

The URL for a specific L4T release has the kernel code used in that release (painfully, it is a source code package within another source package). You can cross reference the web location from here:
https://developer.nvidia.com/linux-tegra

Hello
Applied it, but the issue persists. The “configfs-gadget gadget: Wrong NDP SIGN” error still appears repeatedly. I am using NVIDIA Jetpack version 4.6 and L4T version 32.6.1. What should I try next to resolve this issue?

Someone from NVIDIA may have to respond, but do be certain your edit made it in. It isn’t unusual for edits of the kernel to somehow end up being the old kernel.

Maybe @WayneWWW or @KevinFFF can check this bug and see if this already is fixed:
https://lore.kernel.org/all/1401383543-10181-2-git-send-email-jim_baxter@mentor.com/

It is possible the cause is something else, but the bug output suggests that is the specific bug and that the given patch would work. If this patch does not work, then I’m not sure where to go from there.

@JerryChang
Could you please look into the queries raised above? Any suggestions or guidance on resolving this issue would be very helpful.

hello rahul.pp,

it’s error reported by below.

  		if (get_unaligned_le32(tmp) != ncm->ndp_sign) {
  			INFO(port->func.config->cdev, "Wrong NDP SIGN\n");
  			goto err;
  		}

according to the driver, did you configure CRC mode?
or… please check below code snippets has executed.

static int ncm_setup(struct usb_function *f, const struct usb_ctrlrequest *ctrl)
{
...
           case ((USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE) << 8)
                | USB_CDC_SET_CRC_MODE:

                ...
                ncm->ndp_sign = ncm->parser_opts->ndp_sign | ndp_hdr_crc;

@JerryChang

I checked this code, but the program is not executing this case and does not switch to CRC mode. How can this be rectified?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.