Nut upsuser - May 2017 - TrippLite HID 0.82: libusb_get_interrupt: Function not implemented

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)


# 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


# 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





# cat ups.conf
# Network UPS Tools: example ups.conf
[usb]
        driver = usbhid-ups
        port = auto
        desc = "Example USB UPS"



# cat upsd.conf
# Network UPS Tools: example upsd configuration file



# cat upsd.users
# Network UPS Tools: Example upsd.users
[admin]
                password = mypass
                actions = SET
                instcmds = ALL

======================================================

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

What should I try next?

thanks.

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.)

On 5/13/2017 10:20 AM, Charles Lepple wrote:
> 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.)
> 

Thanks for the reply.

I need to investigate this further.  I found that the USB port on the PC
I was using seemed to be a bit flaky.   When I plugged the Tripp-Lite
into another USB port on the same box, it worked a lot better.  I'll
have another PC to use sometime next week, and I'll get into it again.

Until I get to the bottom of all this, I've put into use a CyberPower
UPS.  I should get around to posting the various data on it this weekend.

Thanks again for the reply.