Nut upsuser - Jun 2017 - Unable to use nut-2.7.4 with Eaton 5E1500I USB

On 06/19/2017 11:02 AM, Manuel Wolfshant wrote:
> Thank a lot !
> Now, conclusions after attempting builds ( with no docs included since 
> attempting to enable them triggers the errors related to missing or 
> too old tools mentioned by me in an earlier message )
> - building against libsub 1.0 triggers the following 2 errors :
> nutdrv_qx-nutdrv_qx.o: In function `ippon_command':
>
/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:679:
> undefined reference to `libusb_strerror'
>
/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:692:
> undefined reference to `libusb_strerror'
> nutdrv_qx-nutdrv_qx.o: In function `fabula_command':
>
/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:907:
> undefined reference to `libusb_strerror'
> nutdrv_qx-nutdrv_qx.o: In function `krauler_command':
>
/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:770:
> undefined reference to `libusb_strerror'
> nutdrv_qx-nutdrv_qx.o: In function `sgs_command':
>
/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:542:
> undefined reference to `libusb_strerror'
>
nutdrv_qx-nutdrv_qx.o:/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:568:
> more undefined references to `libusb_strerror' follow
> [...]
> libusb1.o: In function `nut_libusb_strerror':
> /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:484:
> undefined reference to `libusb_strerror'
> /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:469:
> undefined reference to `libusb_strerror'
> /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:479:
> undefined reference to `libusb_strerror'
> libusb1.o: In function `nut_libusb_open':
> /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:181:
> undefined reference to `libusb_strerror'
> /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:282:
> undefined reference to `libusb_strerror'
>
libusb1.o:/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:289:
> more undefined references to `libusb_strerror' follow
I did some more digging. It turns out that the version of libusb 1.0 ( 
1.0.9 ) included by RH in RHEL 6 misses the libusr_strerror function 
completely. I bypassed that by building against libusbx ( oldish but 
good enough, I think -- 1.0.19). Unfortunately there not much gain as 
the usbhid driver still cannot access that f*ing interface:

[root at belgrade ~]# usbhid-ups -DDDD -u root -x explore -x 
vendorid="0463" -a eaton
Network UPS Tools - Generic HID driver 0.42 (v2.7.4-418-gb1314c62.7.4.1)
USB communication driver (libusb 1.0) 0.02
    0.000000     [D1] debug level is '4'
    0.001696     [D1] upsdrv_initups...
    0.011580     [D2] Checking device (0463/FFFF)
    1.012644     [D2] - VendorID: 0463
    1.012669     [D2] - ProductID: ffff
    1.012681     [D2] - Manufacturer: unknown
    1.012693     [D2] - Product: unknown
    1.012767     [D2] - Serial Number: unknown
    1.012777     [D2] - Bus: 002
    1.012786     [D2] - Device release number: 0001
    1.012797     [D2] Trying to match device
    1.012836     [D2] Device matches
    1.012842     [D2] Reading first configuration descriptor
    1.012851     [D2] auto detached kernel driver from USB device
    1.013972     [D2] Claimed interface 0 successfully
    1.013983     [D3] nut_usb_set_altinterface: skipped 
libusb_set_interface_alt_setting(udev, 0, 0)
    1.014501     [D2] Unable to get HID descriptor (Pipe error)
    1.014511     [D3] HID descriptor length (method 1) -1
    1.014517     [D4] i=0, extra[i]=09, extra[i+1]=21
    1.014525     [D3] HID descriptor, method 2: (9 bytes) => 09 21 10 01 
21 01 22 25 02
    1.014532     [D3] HID descriptor length (method 2) 549
    1.014538     [D2] HID descriptor length 549
    1.015007     [D2] Unable to get Report descriptor: Resource 
temporarily unavailable


Short of updating the kernel, anything else I can do ?

On Jun 19, 2017, at 4:27 AM, Manuel Wolfshant wrote:
> 
>   1.014501     [D2] Unable to get HID descriptor (Pipe error)
>   1.014511     [D3] HID descriptor length (method 1) -1
So at this point in the logs, the kernel USB HID driver is detached from the UPS
HID interface (until the UPS USB cable is unplugged and reattached). If you run
"lsusb -vvv -d 0463:ffff", does it print the HID report descriptor?
(Normally, lsusb will only print descriptors for interfaces that are not claimed
by a kernel driver or userspace library.)

If so, then it is worth checking to see how usbutils is talking to the UPS.

If not (lsusb returns "Report Descriptors:" / "** UNAVAILABLE
**"), it seems like the two options are to upgrade the kernel (which I
understand is an issue), or try to roll back the userspace tools to match what
was current when the kernel was current.

On 06/19/2017 05:33 PM, Charles Lepple wrote:
> On Jun 19, 2017, at 4:27 AM, Manuel Wolfshant wrote:
>>    1.014501     [D2] Unable to get HID descriptor (Pipe error)
>>    1.014511     [D3] HID descriptor length (method 1) -1
> So at this point in the logs, the kernel USB HID driver is detached from
the UPS HID interface (until the UPS USB cable is unplugged and reattached). If
you run "lsusb -vvv -d 0463:ffff", does it print the HID report
descriptor? (Normally, lsusb will only print descriptors for interfaces that are
not claimed by a kernel driver or userspace library.)
>
> If so, then it is worth checking to see how usbutils is talking to the UPS.
This is what I get:

#lsusb -vvv -d 0463:ffff

Bus 002 Device 012: ID 0463:ffff MGE UPS Systems UPS
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               1.10
   bDeviceClass            0 (Defined at Interface level)
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0         8
   idVendor           0x0463 MGE UPS Systems
   idProduct          0xffff UPS
   bcdDevice            0.01
   iManufacturer           1
   iProduct                2
   iSerial                 0
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength           34
     bNumInterfaces          1
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0xa0
       (Bus Powered)
       Remote Wakeup
     MaxPower               20mA
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       0
       bNumEndpoints           1
       bInterfaceClass         3 Human Interface Device
       bInterfaceSubClass      0 No Subclass
       bInterfaceProtocol      0 None
       iInterface              0
         HID Device Descriptor:
           bLength                 9
           bDescriptorType        33
           bcdHID               1.10
           bCountryCode           33 US
           bNumDescriptors         1
           bDescriptorType        34 Report
           wDescriptorLength     549
           Warning: incomplete report descriptor
           Report Descriptor: (length is 9)
             Item(Main  ): (null), data=none
             Item(Main  ): (null), data=none
             Item(Main  ): (null), data=none
             Item(Main  ): (null), data=none
             Item(Main  ): (null), data=none
             Item(Main  ): (null), data=none
             Item(Main  ): (null), data=none
             Item(Main  ): (null), data=none
             Item(Main  ): (null), data=none
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0008  1x 8 bytes
         bInterval              20
Device Status:     0x0001
   Self Powered
>
> If not (lsusb returns "Report Descriptors:" / "**
UNAVAILABLE **"), it seems like the two options are to upgrade the kernel
(which I understand is an issue),
unfortunately it is. If mandatory I guess I can do some tricks with cron 
to rollback a known good situation but given that I have no idea what 
failed during the previous attempt ( nothing got logged -- I suspect a 
kernel panic although I have no idea why would this happen ) I'd prefer 
to avoid, if possible.

>   or try to roll back the userspace tools to match what was current when
the kernel was current.
>
I am afraid I did not understand this part...



Thanks for assistance

     M.