Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
On 3/17/2011 12:17, Arjen de Korte wrote: This patch (committed after 2.6.0 was released) claims to restore 2.4.1 behavior: http://trac.networkupstools.org/projects/nut/changeset/2893 All of the above are irrelevant here. The driver runs fine when started as root, so this must be a permissions problem. The original problem that r2407 addressed (which I also experienced) manifested similarly, in that running as root it would work, running as non-root it would not. I don't know enough about usb/libusb to have any clue why that would be, but it was. So I tried applying the diff from r2893 to the Debian nut 2.6.0-1 source package and building that, and lo and behold it now works as non-root! Also, when running as root before, it spat out a lot of warnings while fetching the reports, now it spits out none. While I didn't really understand the warnings before, I'd assume that not generating them is a sign of things working better. Given that there doesn't seem to have been a new release of libusb0 in something like four or five years, then if this really does need to be fixed at the libusb level, I suspect the first thing that will have to happen is nut moving to libusb1. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
Citeren Charles Lepple : If I run it under strace, the ioctls on the /dev/bus/usb file descriptor preceeding each "operation not permitted" error return 0, not an error code such as EPERM. That seems strange. Would you please compress and send the strace output (without "-u root")? Attached. Looks like Ubuntu fixed 2.4.3 here: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/572262 That was committed to NUT here: http://trac.networkupstools.org/projects/nut/changeset/2407 This breaks reading larger reports, so it was reverted: http://trac.networkupstools.org/projects/nut/changeset/2719 This patch (committed after 2.6.0 was released) claims to restore 2.4.1 behavior: http://trac.networkupstools.org/projects/nut/changeset/2893 All of the above are irrelevant here. The driver runs fine when started as root, so this must be a permissions problem. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
2011/3/17 Arjen de Korte > Citeren Charles Lepple : > > > Arjen: do we actually have any cases of reports larger than 8 bytes? >> > > Yes. At least the MGE Evolution series uses reports that are larger than 8 > bytes. some Eaton and Dell models too > > If so, should we mark this as a quirk for CyberPower devices? >> > > Well, I still don't understand why we can't read with an arbitrary buffer > length in the libusb call in the first place. This should be handled by the > library (not the application). > > > Also, it >> seems like we need to distinguish between returning 0 and <0 from the >> libusb call. Currently, we are reading errno when a zero-length packet >> is being read. >> > > This too is broken. If we attempt to read a report and libusb can't return > any data, it should at least give us a hint why. I really feel that this > should be handled by the library, not NUT. > seconded. I've not had a look at libusb-1 to see if the situation has improved, but I hope so... cheers, Arnaud -- Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
Citeren Charles Lepple : Arjen: do we actually have any cases of reports larger than 8 bytes? Yes. At least the MGE Evolution series uses reports that are larger than 8 bytes. If so, should we mark this as a quirk for CyberPower devices? Well, I still don't understand why we can't read with an arbitrary buffer length in the libusb call in the first place. This should be handled by the library (not the application). Also, it seems like we need to distinguish between returning 0 and <0 from the libusb call. Currently, we are reading errno when a zero-length packet is being read. This too is broken. If we attempt to read a report and libusb can't return any data, it should at least give us a hint why. I really feel that this should be handled by the library, not NUT. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
On Wed, Mar 16, 2011 at 5:02 PM, Cheetah wrote: > On 3/15/2011 6:22, Charles Lepple wrote: >> >> On Mar 14, 2011, at 1:20 AM, Cheetah wrote: >> >>> If I run it under strace, the ioctls on the /dev/bus/usb file descriptor >>> preceeding each "operation not permitted" error return 0, not an error code >>> such as EPERM. >> >> That seems strange. Would you please compress and send the strace output >> (without "-u root")? > > Attached. Looks like Ubuntu fixed 2.4.3 here: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/572262 That was committed to NUT here: http://trac.networkupstools.org/projects/nut/changeset/2407 This breaks reading larger reports, so it was reverted: http://trac.networkupstools.org/projects/nut/changeset/2719 This patch (committed after 2.6.0 was released) claims to restore 2.4.1 behavior: http://trac.networkupstools.org/projects/nut/changeset/2893 Arjen: do we actually have any cases of reports larger than 8 bytes? If so, should we mark this as a quirk for CyberPower devices? Also, it seems like we need to distinguish between returning 0 and <0 from the libusb call. Currently, we are reading errno when a zero-length packet is being read. -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
On 3/15/2011 6:22, Charles Lepple wrote: On Mar 14, 2011, at 1:20 AM, Cheetah wrote: If I run it under strace, the ioctls on the /dev/bus/usb file descriptor preceeding each "operation not permitted" error return 0, not an error code such as EPERM. That seems strange. Would you please compress and send the strace output (without "-u root")? Attached. Also, what architecture is this running on? x86_64, Intel X58 chipset, core i7 series processor. usbhid-ups.strace.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
On Mar 14, 2011, at 1:20 AM, Cheetah wrote: If I run it under strace, the ioctls on the /dev/bus/usb file descriptor preceeding each "operation not permitted" error return 0, not an error code such as EPERM. That seems strange. Would you please compress and send the strace output (without "-u root")? Also, what architecture is this running on? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
I've been running the Debian packaged 2.4.3 for a while, working find. When 2.6.0-1 just pushed through to debian, things have stopped working :( I checked what had been the usual suspects in past problems, namely permissions problems in /dev/bus/usb, but all seems in order: $ lsusb ... Bus 009 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS $ ls -l /dev/bus/usb/009/002 crw-rw-r-- 1 root nut 189, 1025 Mar 14 00:50 /dev/bus/usb/009/002 But if I run the driver with debugging enabled, it gives this: $ sudo /lib/nut/usbhid-ups -a cp1500 -D -D -D ... 0.135837 Checking device (0764/0501) (009/002) 0.158857 - VendorID: 0764 0.158870 - ProductID: 0501 0.158876 - Manufacturer: CPS 0.158882 - Product: CP 1500C 0.158887 - Serial Number: unknown 0.158891 - Bus: 009 0.158896 Trying to match device 0.158933 Device matches 0.166875 HID descriptor, method 1: (9 bytes) => 09 21 10 01 21 01 22 83 01 0.166892 HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 01 22 83 01 0.166899 HID descriptor length 387 0.21 Report Descriptor size = 387 0.218907 Report Descriptor: (387 bytes) => ... ... 0.219118 Using subdriver: CyberPower HID 0.3 0.223871 libusb_get_report: error sending control message: Operation not permitted 0.223890 Can't retrieve Report 01: Operation not permitted 0.223902 Path: UPS.PowerSummary.iProduct, Type: Feature, ReportID: 0x01, Offset: 0, Size: 8 0.228837 libusb_get_report: error sending control message: Operation not permitted 0.228860 Can't retrieve Report 02: Operation not permitted ... much repeating of stuff like this for many "Path"s ... 0.448872 Report descriptor retrieved (Reportlen = 387) 0.448878 Found HID device 0.448882 Detected a UPS: CPS/ CP 1500C 0.453873 libusb_get_report: error sending control message: Operation not permitted 0.453890 Can't retrieve Report 03: Operation not permitted 0.453898 Can't initialize data from HID UPS If I run it under strace, the ioctls on the /dev/bus/usb file descriptor preceeding each "operation not permitted" error return 0, not an error code such as EPERM. If I run it with -u root so that it doesn't drop permissions, it seems to work OK. That doesn't work from ups.conf, though, and running the driver as root changes the permissions for the socket in /var/run such that the rest of nut can't talk to the driver! I can fix that by manually chmod'ing the socket after startup, but that leaves things in a bit of a mess. Exact versions of related packages: nut 2.6.0-1 libupsclient1 2.6.0-1 libusb-0.1-4 2:0.1.12-17 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser