Nut upsdev - Aug 2006 - newhidups subdriver_matcher incorrectly matches USB hub

I ran into the following issue today and would like some feedback from
the group.

Setup:
I am using a MGE Pulsar Evolution 2200 UPS connected through a Belkin
(F5U218-MOB) 4-Port USB Hub.

Scenario:
The newhidups subdriver_matcher function calls
belkin_subdriver->belkin_claim. The belkin_claim function in
belkin-hid.c matches the VendorID of the hub to Belkin's VendorID
(0x050d), causing the hub to be recognized as a UPS. The newhidups
driver (libusb.c) then attempts to claim the device and detatches the
kernel driver. When the hub fails to provide a HID descriptor, the
newhidups driver moves on to the next device and correctly locates the
MGE UPS. The problem is that the hub is now non-functional as the hub
kernel driver has been detatched. 

Problem:
The belkin_claim function should not assume that because the VendorID is
Belkin's the device is a UPS. Belkin makes several USB devices and
starting newhidups with them connected could leave them inoperable until
they are removed an reconnected.  Even if the UPS is not connected
through the hub, the hub can still get disabled if it is matched before
the UPS.

If MGE made a USB hub, the mge_claim function in mge-hid.c would have
the same issue.


Output:

:/tmp# /tmp/newhidups -DDD /dev/usb/hid/hiddev0
Network UPS Tools: New USB/HID UPS driver 0.28 (2.0.4)

debug level is '3'
Checking device (0000/0000) (001/001)
- VendorID: 0000
- ProductID: 0000
- Manufacturer: unknown
- Product: USB OHCI Root Hub
- Serial Number: c64ffc00
- Bus: 001
Trying to match device
Device does not match - skipping
Checking device (050D/0218) (001/014)
- VendorID: 050d
- ProductID: 0218
- Manufacturer: unknown
- Product: unknown
- Serial Number: unknown
- Bus: 001
Trying to match device
Device matches
failed to claim USB device, trying 2 more time(s)...
detaching kernel driver from USB device...
trying again to claim USB device...
Unable to get HID descriptor (error sending control message: Broken
pipe)
Checking device (0463/FFFF) (001/015)
- VendorID: 0463
- ProductID: ffff
- Manufacturer: MGE UPS SYSTEMS
- Product: Evolution
- Serial Number: AH2G10067
- Bus: 001
Trying to match device
Device matches
HID descriptor retrieved (Reportlen = 1620)
Size read for the report descriptor: 1620
Report descriptor retrieved (Reportlen = 1620)
Found HID device
Report Descriptor size = 1620
Report Descriptor: (200 bytes) => 05 84 09 04 A1 01 09 10 A1 00 85 01 09
11 75 08
Detected a UPS: MGE UPS SYSTEMS/Evolution
Using subdriver: MGE HID 0.9
......cut......



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20060815/f7390475/attachment.htm

On 8/15/06, Schmier, Jacob <Jacob_Schmier@inter-tel.com>
wrote:
>  :/tmp# /tmp/newhidups -DDD /dev/usb/hid/hiddev0
(Note that you do not need to specify the /dev node for newhidups.)

One way to avoid this is to run the driver as an unprivileged user,
and set up udev/hotplug to only give NUT read/write access to the UPS.

IIRC, most distributions use mode 0644 on /proc/bus/usb/* nodes by
default, so creating a 'nut' user and running 'chown nut ...' in
the
hotplug script would do the trick. See scripts/hotplug or
scripts/hotplug-ng (udev) for more information.

-- 
- Charles Lepple

> > :/tmp# /tmp/newhidups -DDD /dev/usb/hid/hiddev0 
> (Note that you do not need to specify the /dev node for newhidups.) 
According to the usage info, the /dev node is only optional when 
using -a.  Although running the following works just fine:
:/tmp# /tmp/newhidups -u nut /etc/passwd

Having to provide SOMETHING in the device option even though newhidups 
is going to scan the usb bus for a device anyway seems a bit ridiculous 
to me, but that is another issue ;)
> One way to avoid this is to run the driver as an unprivileged user, 
> and set up udev/hotplug to only give NUT read/write access to the UPS.
> IIRC, most distributions use mode 0644 on /proc/bus/usb/* nodes by 
> default, so creating a 'nut' user and running 'chown nut
...' in the
> hotplug script would do the trick. See scripts/hotplug or 
> scripts/hotplug-ng (udev) for more information.
> -- 
> - Charles Lepple
Thanks for the suggestion.  It definitely does the trick.  However,
this is really just a work around to the underlying problem.  The hub
is still matched, it just cannot be claimed due to permissions.  The 
hub really shouldn't be matched at all.

I could just as easily change belkin_claim in drivers/belkin-hid.c so 
that it never reports a match since I don't use a Belkin UPS.

~Jacob