[Nut-upsuser] TrippLite HID 0.82: libusb_get_interrupt: Function not implemented [3016]

[Charles Lepple]

On May 12, 2017, at 10:06 AM, Mike <the.lists at mgm51.com> wrote:
> 
> 
> OpenBSD 6.1/amd64
> nut-2.7.4p0 (from OpenBSD package)
> UPS: Tripp-Lite OMNI1500LCDT
> 
> I cannot get the driver for the UPS to load without error.
> 
> Here are the commands, with the output, and the config files:
> 
> =======================================================
> # upsdrvctl start
> Network UPS Tools - UPS driver controller 2.7.4
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
> No matching HID UPS found - check permissions on /dev/ugen* and /dev/usb*
> Driver failed to start (exit status=1)
> 
This seems to be different behavior than below. Did anything else change?

> 
> # ls -al /dev/usb*
> crw-rw----  1 root  wheel   61,   0 May 11 15:45 /dev/usb0
> crw-rw----  1 root  wheel   61,   1 May 11 15:45 /dev/usb1
> crw-rw----  1 root  wheel   61,   2 May 11 15:45 /dev/usb2
> crw-rw----  1 root  wheel   61,   3 May 11 15:45 /dev/usb3
> crw-rw----  1 root  wheel   61,   4 May 11 15:45 /dev/usb4
> crw-rw----  1 root  wheel   61,   5 May 11 15:45 /dev/usb5
> crw-rw----  1 root  wheel   61,   6 May 11 15:45 /dev/usb6
> crw-rw----  1 root  wheel   61,   7 May 11 15:45 /dev/usb7
> 
> 
> [/dev/ugen* has the same permissions as above]
> 
> # grep _ups /etc/group
> wheel:*:0:root,_ups
> 
> 
> 
> # upsdrvctl -D start
> Network UPS Tools - UPS driver controller 2.7.4
>   0.000000     Starting UPS: usb
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
> Using subdriver: TrippLite HID 0.82
> libusb_get_interrupt: Function not implemented

The last line is just a warning - usbhid-ups can use both interrupt requests and EP0 control requests. The driver was probably running in the background, per the "Duplicate driver instance" message below.
> 
> 
> # upsdrvctl -DD start
> Network UPS Tools - UPS driver controller 2.7.4
>   0.000000
> If you're not a NUT core developer, chances are that you're told to
> enable debugging
> to see why a driver isn't working for you. We're sorry for the
> confusion, but this is
> the 'upsdrvctl' wrapper, not the driver you're interested in.
> 
> Below you'll find one or more lines starting with 'exec:' followed by an
> absolute
> path to the driver binary and some command line option. This is what the
> driver
> starts and you need to copy and paste that line and append the debug
> flags to that
> line (less the 'exec:' prefix).
> 
>   0.000323     Starting UPS: usb
>   0.000360     1 remaining attempts
>   0.000378     exec:  /usr/local/bin/usbhid-ups -a usb
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
> Duplicate driver instance detected! Terminating other driver!
> [about a 20 second delay]
> Using subdriver: TrippLite HID 0.82
> libusb_get_interrupt: Function not implemented
> 
> 
> 
> # /usr/local/bin/usbhid-ups -a usb
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
> Using subdriver: TrippLite HID 0.82
> libusb_get_interrupt: Function not implemented

The usbhid-ups command line is where you could add '-D' to increase debug output.

> If I run upsdrvctl with -D flags, it appears to loop.  I can make
> available that extensive output, if needed.

Per the message from upsdrvctl, the debug flags need to be passed directly to the driver, not to upsdrvctl.

What happens when you start "upsd" and run "upsc ups"?

That said, we have had no end of trouble with Tripp-Lite 3016 protocol devices. For instance:

https://github.com/networkupstools/nut/pull/122 (SMART1500LCDT in this case, but seems similar in many regards)

I don't have a physical OpenBSD box to test with, but extrapolating from the Linux devices I have tested against, you might see USB disconnect messages in dmesg. While it could be argued that the NUT driver is doing something to trigger these disconnections, I have seen them on Linux systems when NUT is not loaded.

We have been in contact with Tripp-Lite about this over the past few years, and this issue is complicated by the fact that it seems to be motherboard-dependent: older USB host controllers do not trigger the disconnections. ARM boards such as the Raspberry Pi sometimes fare better, but their USB controllers seem to be more flaky in the long term than x86-based systems.

Fortunately, the USB interface on these UPS models seems to be somewhat isolated from the power control circuitry. The SMART1500LCDT powering my primary desktop seems to handle brief power outages just fine, but I got tired of dealing with the disconnect/reconnect messages, and stopped trying to debug the NUT driver.

My personal recommendation (and I do not speak for my employer, or Tripp-Lite) is that if you need shutdown notifications to the OS, choose a different UPS. (This UPS should be okay for filtering power to non-core network infrastructure.)