Red Hat Bugzilla – Bug 668932
upowerd steals FT-232 USB serial ports
Last modified: 2012-08-16 16:04:00 EDT
Description of problem: If one plugs in an FT-232-based USB serial port, upower will try to claim it as a "Watts Up Pro" device. This is paricularly obnoxious since upower cannot be removed due to core GNOME dependencies. Version-Release number of selected component (if applicable): upower-0.9.5-7.fc14.x86_64 How reproducible: 100% Steps to Reproduce: 1. Plug in a USB serial port of type: Bus 004 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC 2. Try to use said serial port Actual results: USB port busy due to having been stolen by upowerd Expected results: Usable serial port Additional info: This is due to the following statement in /lib/udev/rules.d/95-upower-wup.rules: SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A80?????", ENV{UPOWER_VENDOR}="Watts Up, Inc.", ENV{UPOWER_PRODUCT}="Watts Up? Pro", ENV{UP_MONITOR_TYPE}="wup" Note that the device ID is a stock serial port device ID, and that the serial number match is completely spurious, because it is not qualified by a *product name*. In my case: Bus 004 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 FTDI iProduct 2 FT232R USB UART iSerial 3 A8003QII bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 90mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 FT232R USB UART 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 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered)
(Additional note: this is, to my counting, at least the third non-removable daemon stealing USB serial ports on F14.)
Watts Up Pro really screwed things up when they used the default VID and PID for the USB -> serial chip in their design. That said, upower shouldn't steal the device. Doesn't upower release the device when it fails to return sensible data? Or if the issue that upower tries to squirt "foreign" data into a RS232 connection that's not expecting it?
upower does not release the device.
It might be possible to distinguish WUP based on iManufacturer or iProduct, but if not, then it would have to be configured manually. Squirting "foreign" data into an RS232 connection is hostile at best.
This bug is back/still there in upower-0.9.10-1.fc15.x86_64. This is an incredibly serious bug for anyone who uses the second most common USB serial port adapter on the planet.
You can actually fix this by changing EnableWattsUpPro=false in /etc/UPower/UPower.conf
I would strongly suggest enabling this by default in the package, since the assumption that FTDI serial = WUP is likely to be false for more people than it is true for, and it is probably *very* confusing for those people.
This also affects me - the FTDI is the old standard for Arduino. This should be disabled by default in the conf or elsewhere - even a fix could confuse things as I don't want things going out the serial port probing by default.
There is an identical problem with /etc/udev/rules.d/99-gpsd.rules the FTDI 8U232AM similarly will have GPSD try to grab it. GPSD might release it but the probes can screw up a lot of things. Should I file this as a separate report?
I don't know if it is related, but modem-manager grabs the port too and I don't have a way to disable it, but I don't know if it probes or does anything else bad. It may have been launched by gpsd or something. There needs to be a way to shut off all these subtasks all trying to figure out what is attached. Also, upowerd seems to turn off the USB port when it doesn't find the watts up so I've found myself plugging and unplugging, but it may be fixed now with the changes
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping