Issue with Akri Recognizing USB Devices Connected via USB Hub/Switch

[lnguy1933]

Hi team,
I’m encountering an issue where Akri works perfectly for exposing USB devices connected directly to the host, but it fails to recognize devices that are connected via a USB hub or switch. Here are the details:

Setup:

• I am using the udev discovery handler to expose USB devices to Kubernetes pods.
• The Akri configuration works as expected when the USB device is connected directly to the host.
• However, if the same device is connected to the host via a USB hub or switch (e.g., Acroname USBHub3p), the pod cannot detect the device.

Observed Behavior:

• Akri discovers the device and creates an instance, as seen in kubectl get instances.akri.sh.
• However, the pod consuming the instance fails to interact with the device.
• Logs from the broker or application in the pod show errors like LIBUSB_ERROR_BUSY or missing device paths.

Additional Details:

• Running udevadm info shows additional attributes like DRIVER=apple-mfi-fastcharge for the device when connected through the hub, which might indicate that a kernel driver is interfering with the device.
• The device hierarchy as seen in lsusb -t confirms the device is under the hub, and the hub itself is correctly recognized by the host.

Questions:

1. Is there a specific configuration or udev rule required to ensure Akri handles devices connected via USB hubs or switches?
2. Could the issue be related to the kernel driver automatically binding to the device? If so, how can Akri work with such devices without manual unbinding?
3. Are there any known limitations of Akri when dealing with USB devices connected via hubs, and are there recommended workarounds?

What I’ve Tried:

1. Adding udev rules to ignore the kernel driver for the device.
2. Manually unbinding the kernel driver before connecting the pod.
3. Restarting the Akri agent and udev discovery handler.

Any guidance on resolving this issue would be greatly appreciated!
Thank you in advance!

[yujinkim-msft]

hi @lnguy1933 thank you so much for submitting this bug -- I will see if someone with udev experience can help with this bug asap!