Nut upsdev - Feb 2011 - Bug/Patch for NUT 2.6.0 ; usbhid-ups (libhid.c)

Hello All-

First, my apologies if this is not the correct place/procedure for
reporting a bug.

I have a Cyberpower  850AVRLCD ups, and I'm running  NUT 2.6.0 (and
also tried 2.4.1 and 2.4.3).  I suspect that the problem I was having
would affect anyone using the usbhid-ups driver, but since I have only
the one UPS, I don't know for sure.
In NUT 2.4.1  the driver starts up OK, and  upsc client gives me
values for 39 variables/parameters.
In NUT 2.4.3 and 2.6.0,  level 1 debug from the driver shows lots of
errors and upsc client gives me only 22 variables/parameters.
I narrowed the problem down to one function call in libhid.c:

r = comm_driver->get_report(udev, id, buf, sizeof(buf));

Below is the patch that fixes the problem.   With this change, I get
no errors in the level 1 driver debug output, and upsd and all the
clients seem to work properly.
Once I found that this fixed my problems, I didn't look into it
further.   But I expect that whoever is responsible for this part of
the code will probably know right away if it is a reasonable change or
if there is a better fix.
If you need more details on my system/setup, please let me know;  I'll
be happy to provide more info.
And finally,  thank you all for giving us NUT -- it's very useful!

Regards,
Richard Gerth


===================================================--- libhid.c    2011-02-02
20:35:39.862569743 -0600
+++ libhid.c.rg 2011-02-02 20:41:41.716570500 -0600
@@ -149,7 +149,7 @@
                return 0;
        }

-       r = comm_driver->get_report(udev, id, buf, sizeof(buf));
+       r = comm_driver->get_report(udev, id, buf, rbuf->len[id]);
        if (r <= 0) {
                return -1;
        }
=====================================================

Citeren Richard Gerth <r.gerth.phd op gmail.com>:
> I have a Cyberpower  850AVRLCD ups, and I'm running  NUT 2.6.0 (and
> also tried 2.4.1 and 2.4.3).  I suspect that the problem I was having
> would affect anyone using the usbhid-ups driver, but since I have only
> the one UPS, I don't know for sure.
It doesn't affect anyone. We (the developers) don't run into this  
(otherwise we wouldn't release it, would we?).
> In NUT 2.4.1  the driver starts up OK, and  upsc client gives me
> values for 39 variables/parameters.
This would request an estimate for the amount of data, based the  
report descriptor. Sadly, this is badly broken for many devices.
> In NUT 2.4.3 and 2.6.0,  level 1 debug from the driver shows lots of
> errors and upsc client gives me only 22 variables/parameters.
> I narrowed the problem down to one function call in libhid.c:
>
> r = comm_driver->get_report(udev, id, buf, sizeof(buf));
This should request the report 'id' from the device connected through  
'udev' and store the result in 'buf' and we request
'sizeof(buf)'
octets (bytes).
> Below is the patch that fixes the problem.   With this change, I get
> no errors in the level 1 driver debug output, and upsd and all the
> clients seem to work properly.
What apparently isn't working for you, is that either the libusb  
library or the UPS isn't happy if we request (many) more octets than  
it has for us. If we ask for 512 octets and it only has 8 for us, it  
should return just that. But I suspect it attempts to fill the full  
contents of the buffer and fails along the way (the debug output  
should tell us precisely).
> Once I found that this fixed my problems, I didn't look into it
> further.   But I expect that whoever is responsible for this part of
> the code will probably know right away if it is a reasonable change or
> if there is a better fix.
What you did, is what we did up to (and including) nut-2.4.1.
> If you need more details on my system/setup, please let me know;  I'll
> be happy to provide more info.
I'd like to know which version of libusb you're using (native  
libusb-0.1 or a wrapper around libusb-1.0) and which OS you're using.  
Furthermore, some debug output at level 5 (-DDDDD) to show as much  
information as possible what happens around the time this triggers an  
error. If the syslog shows something, that might help too.

Best regards, Arjen
-- 
Please keep list traffic on the list (off-list replies will be rejected)