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

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.

On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote:
> 
> #lsusb -vvv -d 0463:ffff
> 
> Bus 002 Device 012: ID 0463:ffff MGE UPS Systems UPS
...
>       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
> 
If I recall, this is equivalent to the usbhid-ups "method 2" approach
to retrieving the descriptor.

>> 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...
If there are newer kernels out there, it is possible that some of the userspace
tools (usbutils, libusb, etc.) are expecting a newer kernel. Is it possible to
downgrade any of them, to test with package versions that were released at the
same time as the 2.6.32 kernel?

On 06/20/2017 02:27 AM, Charles Lepple wrote:
> On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote:
>> #lsusb -vvv -d 0463:ffff
>>
>> Bus 002 Device 012: ID 0463:ffff MGE UPS Systems UPS
> ...
>>        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
>>
> If I recall, this is equivalent to the usbhid-ups "method 2"
approach to retrieving the descriptor.
That's greek to me, I am completely unfamiliar to any of nut ( and its 
drivers ) internals :) But if I can configure usbhid-ups in a different 
manner which I did not spot from the docs, please point me to the 
correct docs.


>>>   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...
> If there are newer kernels out there, it is possible that some of the
userspace tools (usbutils, libusb, etc.) are expecting a newer kernel. Is it
possible to downgrade any of them, to test with package versions that were
released at the same time as the 2.6.32 kernel?
If you mean the applications/libraries running on that server, I can 
guarantee that every one (minus libusb 1.0.19 -- see below) of them is 
compatible with the running kernel. Everything but nut is stock CentOS 6 
and fully updated. I am 100% positive that libsub0.1 which was used 
until yesterday ( and 1.0.9 which proved to be incompatible with nut ) 
are 100% compatible with the kernel. I cannot guarantee for libusbx 
1.0.19  (which I used instead of 1.0.9) because I built it myself. 
However I am using the very same package on my personal workstation 
(which is also running CentOS 6 but has a whole lot of packages 
installed either from 3rd party repos or built by me  ) since Fri 09 Jan 
2015 (I needed it for heimdall <http://glassechidna.com.au/heimdall/> ) 
and I had zero issues so far.

As of newer kernels: RH does not introduce incompatibilities between 
kernel and userspace. For the whole 10 years of life of a major version 
of a distribution, the major release of the kernel (and of most packages 
-- which is why both libsub and libusb1 aka 1.0.9 are oldish ) is frozen 
to the version used at launch date. It was 2.6.32 4.5 years ago when 6.0 
was launched and it will claim to be 2.6.32 when it will be EOLed 4 
years from now. They do backport stuff into the kernel ( actually the 
current kernel has huge backports from 3.10 ),  but breaking the ABI is 
extremely rare and normally never affects the packages from the distro 
itself because they are tested for months prior to any minor release of 
the distro. The newer kernels that exist and are let's say reputable are 
provided by a 3rd party repository ( ElRepo.org ). Over there there is 
one person who maintains two sets of kernels, the most recent one that 
is available from kernel.org ( "kernel mainline" ) and one long term 
version ( kernel-lt ). The kernel-lt is the one that failed for me.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170620/11aa99c6/attachment.html>