udevadm info reports wrong ID_MODEL_ID and ID_VENDOR_ID for USB serial port

Bug #1539348 reported by Julien on 2016-01-29
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
qtserialport-opensource-src (Ubuntu)
High
Unassigned
systemd (Ubuntu)
High
Unassigned

Bug Description

Running udevadm info with the device path of a virtual serial port created by a USB device (in this case a Particle Photon development board) returns the ID_MODEL_ID and ID_VENDOR_ID for the USB host controller instead of the Particle device.

The consequence is mis-detection of the device associated with a virtual serial port in applications.

udevadm info with the virtual serial port. Expect ID_MODEL_ID=c00a and ID_VENDOR_ID=2b04

$ udevadm info --query=property -p /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/tty/ttyACM0
DEVLINKS=/dev/serial/by-id/pci-Particle_Electron_00000000050C-if00 /dev/serial/by-path/pci-0000:00:14.0-usb-0:1:1.0
DEVNAME=/dev/ttyACM0
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/tty/ttyACM0
ID_BUS=pci
ID_MODEL=Electron
ID_MODEL_ENC=Electron
ID_MODEL_FROM_DATABASE=7 Series/C210 Series Chipset Family USB xHCI Host Controller (Zenbook Prime UX31A)
ID_MODEL_ID=0x1e31
ID_PATH=pci-0000:00:14.0-usb-0:1:1.0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_1_1_0
ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
ID_PCI_INTERFACE_FROM_DATABASE=XHCI
ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
ID_REVISION=0200
ID_SERIAL=Particle_Electron_00000000050C
ID_SERIAL_SHORT=00000000050C
ID_TYPE=generic
ID_USB_CLASS_FROM_DATABASE=Communications
ID_USB_DRIVER=cdc_acm
ID_USB_INTERFACES=:020201:0a0000:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=Particle
ID_VENDOR_ENC=Particle
ID_VENDOR_FROM_DATABASE=Intel Corporation
ID_VENDOR_ID=0x8086
MAJOR=166
MINOR=0
SUBSYSTEM=tty
TAGS=:systemd:
USEC_INITIALIZED=4586285779

Running udevadm info with the base device path gives expected IDs

$ udevadm info --query=property -p /devices/pci0000:00/0000:00:14.0/usb1/1-1
BUSNUM=001
DEVNAME=/dev/bus/usb/001/008
DEVNUM=008
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=Electron
ID_MODEL_ENC=Electron
ID_MODEL_ID=c00a
ID_REVISION=0200
ID_SERIAL=Particle_Electron_00000000050C
ID_SERIAL_SHORT=00000000050C
ID_USB_INTERFACES=:020201:0a0000:
ID_VENDOR=Particle
ID_VENDOR_ENC=Particle
ID_VENDOR_ID=2b04
MAJOR=189
MINOR=7
PRODUCT=2b04/c00a/200
SUBSYSTEM=usb
TYPE=2/0/0
USEC_INITIALIZED=4585731209

Running lsusb gives the expected IDs.

$ lsusb -v
Bus 001 Device 008: ID 2b04:c00a
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 2 Communications
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x2b04
  idProduct 0xc00a
  bcdDevice 2.00
  iManufacturer 1 Particle
  iProduct 2 Electron
  iSerial 3 00000000050C
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 67
    bNumInterfaces 2
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xc0
      Self Powered
    MaxPower 100mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 2 Communications
      bInterfaceSubClass 2 Abstract (modem)
      bInterfaceProtocol 1 AT-commands (v.25ter)
      iInterface 0
      CDC Header:
        bcdCDC 1.10
      CDC Call Management:
        bmCapabilities 0x00
        bDataInterface 1
      CDC ACM:
        bmCapabilities 0x02
          line coding and serial state
      CDC Union:
        bMasterInterface 0
        bSlaveInterface 1
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x82 EP 2 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0008 1x 8 bytes
        bInterval 255
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 1
      bAlternateSetting 0
      bNumEndpoints 2
      bInterfaceClass 10 CDC Data
      bInterfaceSubClass 0 Unused
      bInterfaceProtocol 0
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x01 EP 1 OUT
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 0
Device Status: 0x0001
  Self Powered

$ lsb_release -rd
Description: Ubuntu 15.10
Release: 15.10

$ apt-cache policy udev
udev:
  Installed: 225-1ubuntu9
  Candidate: 225-1ubuntu9
  Version table:
 *** 225-1ubuntu9 0
        500 http://archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: udev 225-1ubuntu9
ProcVersionSignature: Ubuntu 4.2.0-25.30-generic 4.2.6
Uname: Linux 4.2.0-25-generic x86_64
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
CurrentDesktop: Unity
CustomUdevRuleFiles: 50-particle.rules 10-pololu-programmer.rules 49-teensy.rules 99-openocd.rules 96-monitor-hotplug.rules 51-android.rules
Date: Thu Jan 28 15:33:38 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-05-09 (994 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MachineType: ASUSTeK COMPUTER INC. UX31A
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-25-generic root=UUID=99e110b2-cdee-4df1-ab50-25fea2fd4f30 ro splash quiet vt.handoff=7
SourcePackage: systemd
UpgradeStatus: Upgraded to wily on 2015-10-27 (93 days ago)
dmi.bios.date: 01/31/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX31A.218
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX31A
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX31A.218:bd01/31/2013:svnASUSTeKCOMPUTERINC.:pnUX31A:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX31A:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.name: UX31A
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

Julien (jvanier) wrote :
summary: - udevadm info reports wrong ID_MODEL_ID and for USB serial port
+ udevadm info reports wrong ID_MODEL_ID and ID_VENDOR_ID for USB serial
+ port
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in qtserialport-opensource-src (Ubuntu):
status: New → Confirmed
Changed in systemd (Ubuntu):
status: New → Confirmed
Aaron Brice (aaron-brice) wrote :

Qt5 QSerialPortInfo is returning the wrong vendor and product also.

Changed in systemd (Ubuntu):
importance: Undecided → High
Changed in qtserialport-opensource-src (Ubuntu):
importance: Undecided → High
Artem Astafyev (artem-astafyev) wrote :

I have this bug on Fedora 23 with systemd-222 so it isn't Ubuntu specific.

Reasoner (lnchpd-reasoner) wrote :

I have a very similar bug in Xubuntu 16.04 and 16.10. I have two small Arduino semi-compatible stm32f103c8t6 based microcontroller boards with USB ports. When I plug the idProduct=3 board in, the system fails to load the ttyACM driver and the board doesn't work. But the weird thing is that even though I disconnected the idProduct=3 board and powered down the system and rebooted, when I plug the idProduct=4 board in, the system detects and declares the presence of the idProduct=3 board and shows product id and serial number of the idProduct=3 board, even though the idProduct=3 board is not connected and has not been connected since before the last boot. Then the system seems to realize its mistake and claims to disconnect the idProduct=3 board (which is not physically connected) and it detects and connects to the idProduct=4 board correctly and loads the ACM driver correctly and the idProduct=4 board works. I was using 16.04 when I discovered this problem, so I upgraded to 16.10, but the problem is the same. This problem has persisted through several reboots and connecting the boards in different orders.

There must be some kind of cache file for USB product id and serial numbers that persists between reboots and even kernel and system version upgrades. Does anybody know how I can clear the cache?

Here's the output of tail -f /var/log/kern.log when connecting the idProduct=4 board. Remember, at the time of this log the idProduct=3 board was not and had not been plugged in since before the last boot. This is showing the false detection of the idProduct=3 board upon insertion of the idProduct=4 board.

==> /var/log/kern.log <==
Feb 12 20:07:57 mybox kernel: [ 85.064070] usb 3-4: new full-speed USB device number 2 using ohci-pci
Feb 12 20:07:58 mybox kernel: [ 85.279854] usb 3-4: New USB device found, idVendor=1eaf, idProduct=0003
Feb 12 20:07:58 mybox kernel: [ 85.279869] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 12 20:07:58 mybox kernel: [ 85.279877] usb 3-4: Product: Maple 003
Feb 12 20:07:58 mybox kernel: [ 85.279884] usb 3-4: Manufacturer: LeafLabs
Feb 12 20:07:58 mybox kernel: [ 85.279890] usb 3-4: SerialNumber: LLM 003
Feb 12 20:07:59 mybox kernel: [ 86.307465] usb 3-4: USB disconnect, device number 2
Feb 12 20:07:59 mybox kernel: [ 86.828222] usb 3-4: new full-speed USB device number 3 using ohci-pci
Feb 12 20:07:59 mybox kernel: [ 87.049880] usb 3-4: New USB device found, idVendor=1eaf, idProduct=0004
Feb 12 20:07:59 mybox kernel: [ 87.049895] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 12 20:07:59 mybox kernel: [ 87.049903] usb 3-4: Product: Maple
Feb 12 20:07:59 mybox kernel: [ 87.049910] usb 3-4: Manufacturer: LeafLabs
Feb 12 20:07:59 mybox kernel: [ 87.125930] cdc_acm 3-4:1.0: ttyACM0: USB ACM device
Feb 12 20:07:59 mybox kernel: [ 87.134810] usbcore: registered new interface driver cdc_acm
Feb 12 20:07:59 mybox kernel: [ 87.134837] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Reasoner (lnchpd-reasoner) wrote :

I got my new board working like the old board. I'm starting to think this false detection is not a problem with udev or systemd, but actually the board appearing as one device, such as a flash bootloader, then disconnecting itself and reconnecting as another ACM serial device.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers