[please use Reply-All - this list does not modify the reply-to header.] > On Oct 10, 2016, at 8:53 AM, scott.b.dor...@nasa.gov wrote: > > I have a user running centos 6.8 with a brand new Tripplite HID (protocol > 4016) > UPS. So I installed nut 6.5 from EPEL and it sometimes worked, and it > sometimes didn't, and it seemed to be very inconsistent about loading the > device driver.
Protocol 4016 is a new one for us. If you run "lsusb -d 09ae:", does it show something like this? (this is from a protocol 3016 unit) $ lsusb -d 09ae: Bus 006 Device 008: ID 09ae:3016 Tripp Lite Assuming nothing drastic has changed in this protocol, there are two places where the new protocol number needs to be added. The driver has a table of known protocol numbers (USB VendorID:ProductID pairs, really, but aside from PID 0001, Tripp Lite tends to keep the protocol numbers and ProductIDs in sync), but you can try adding the "-x productid=4016" command line option (or add "productid=4016" to ups.conf). The second place is in the udev configuration files. When the UPS is first plugged into the USB port, the system looks up the VID:PID (and possibly some more attributes) in the udev configuration directories (/lib/udev/rules.d and /etc/udev/rules.d, if it's similar to Debian's layout), and NUT adds a configuration file to change ownership of the device node to allow the unprivileged NUT driver to control the UPS. Probably the easiest test would be to reinstall the package, check for the udev file (named /lib/udev/rules.d/52-nut-usbups.rules[*] in Ubuntu 14.04) and add a line for your protocol number (copying the 3015 entry). Then you can run "udevadm trigger --subsystem-match=usb --action=change" as root to reload the new udev file. [*] yours might have 62 instead, which could also be part of the problem - the number needs to be lower in order to override some later-numbered rules. We're erring on the side of caution with the USB product IDs - in many cases, vendors have other random USB devices besides UPSes, so we don't just do a wildcard entry for everything with Tripp Lite's VendorID. Also, many Tripp Lite devices have what I would consider to be bugs in the HID descriptor, and so many values end up being reported in the wrong units (Hz*100 for frequency, microvolts for voltage measurements, etc.). When we add a product ID to the table, we also try to correct for the obvious typos. If this doesn't work, please save the logs and let us know what failed. > So, looking around and after spending some time looking at things that had > nothing to do with the real problem, I instead wiped the full install, > downloaded http://www.networkupstools.org/source/2.7/nut-2.7.4.tar.gz > and built it from source. > > The problem is, even if I do a ./configure --with-usb=yes I don't get any > usb drivers installed on the system. usbhid-ups is no where to be found. Centos probably comes with the runtime libraries for libusb installed by default, but you will also need libusb*-devel packages to build from source. We are finishing up testing a libusb-1.0 branch of NUT, and if you encounter problems with the 2.6.5 package (plus the configuration changes mentioned above), it might be worthwhile to test with the new branch. We haven't narrowed down the exact problem, but some combination of the following has been problematic: - TL Protocol 3016 - Server-class motherboards - Older Linux kernels (< 4.0?) - libusb-0.1 For some reason, our snapshots on Buildbot aren't being properly indexed by branch, but this build is what I am currently testing: http://buildbot.networkupstools.org/public/nut/builders/Debian-x64-gcc/builds/664 -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
