Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cdc_acm 3-4:1.0: Zero length descriptor references #1

Open
rikus-- opened this Issue Oct 7, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@rikus--
Copy link
Owner

rikus-- commented Oct 7, 2018

This issue was discovered and reported directly to me by by @craigerl. I'm just documenting it here so others are aware of it if they're trying to use bc125at-perl.

When you plug the device in, you get this, and then the /dev/ttyUSB0 device is not usable even after loading the usbserial driver with the correct arguments:

[ 750.512281] usb 3-4: new full-speed USB device number 7 using xhci_hcd
[ 750.677643] usb 3-4: New USB device found, idVendor=1965, idProduct=0017
[ 750.677654] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 750.677661] usb 3-4: Product: BC125AT
[ 750.677666] usb 3-4: Manufacturer: Uniden America Corp.
[ 750.677671] usb 3-4: SerialNumber: 0001
[ 750.728732] cdc_acm 3-4:1.0: Zero length descriptor references
[ 750.728747] cdc_acm: probe of 3-4:1.0 failed with error -22

Based on the report from @craigerl, it sounds like a kernel patch that resolved the issue with the BC125XLT may also be relevant for the BC125AT:

https://lore.kernel.org/patchwork/patch/959876/

I haven't had a chance to test this out yet, but I will update this issue with more info as I learn about it. If the kernel patch works, I'll at least document it in the README file. If there's a workaround that can be applied short of patching the kernel, I'll try to automate it somehow.

@rikus-- rikus-- self-assigned this Oct 7, 2018

@rikus--

This comment has been minimized.

Copy link
Owner Author

rikus-- commented Oct 7, 2018

I was able to get bc125at-perl to work again WITHOUT a kernel patch using a tip I found here:

https://www.spinics.net/lists/linux-usb/msg158942.html

The command, adjusted for the Uniden vendor/product ids is:

echo 1965 0017 2 076d 0006 > /sys/bus/usb/drivers/cdc_acm/new_id

Then I needed to patch bc125at-perl to be aware of the /dev/ttyACM0 device name instead of /dev/ttyUSB0.

rikus-- referenced this issue Oct 7, 2018

Rikus Goodell
Workaround for "cdc_acm 3-4:1.0: Zero length descriptor references".
Issue 1: https://github.com/rikus--/bc125at-perl/issues/1

Due to an apparent limitation of the Uniden hardware, this device, at
least on more recent kernels, needs the NO_UNION_NORMAL quirk.
A kernel patch was submitted to automatically apply this quirk for the
BC125XLT, but the kernel is not patched for the BC125AT yet.

Based on a suggestion found on a mailing list, I found that the kernel
patch is not necessary after all if you want to apply a simple workaround
to the already-running system.

See: https://www.spinics.net/lists/linux-usb/msg158942.html
@rikus--

This comment has been minimized.

Copy link
Owner Author

rikus-- commented Oct 7, 2018

This should be working now. I'm still running into a problem with the driver helper (setuid program that attempts to set up the driver for you), but the bc125at-perl program works overall as long as you've applied this cdc_acm workaround manually beforehand and chowned the ttyACM0 device to the user as which you run bc125at-perl. Obviously this is something you'll need to do as root.

@craigerl

This comment has been minimized.

Copy link

craigerl commented Oct 7, 2018

Confirmed, Ubuntu 18.04 works perfectly.

Additionally, from my notes:

add user to dialout in /etc/group a/o chmod 666 /dev/ttyACM0
I didn't checkout the patched bc125at-perl, but I did hand edit Serial.pm default tty to use ttyACM0.
modprobe cdc_acm
modprobe usbserial
echo 1965 0017 2 076d 0006 > /sys/bus/usb/drivers/cdc_acm/new_id

@rikus--

This comment has been minimized.

Copy link
Owner Author

rikus-- commented Oct 7, 2018

Awesome. Thanks for confirming.

I'll work on improving the automated device setup for permissions, etc., but hopefully the manual workaround will at least allow you to use it the way you need to.

Also, thank you for bringing this issue to my attention in the first place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.