On Jan 16, 2014, at 4:51 PM, Ariel Wainer wrote:> One small comment: > When the driver has no permission to access the device, it exits with a > segmentation fault, it would be nice to have a more informative error. > I'm not really sure if the issue is speciffic to this driver or is it > general.Good point. I forgot that the permissions errors would happen after the numeric device IDs were matched. I just pushed 3c13603. Tested by telling the driver to match a random USB device instead of 0001:0000, and sure enough, when the driver didn't have write access, the unpatched code crashed. Not sure I want to try and send UPS polling commands to either a working UPS, or the mouse or keyboard, so I'll leave the rest of the testing to you :-) scripts/udev/nut-usbups.rules should have an entry for 0001:0000 (although the comments mention a different driver). You may have to refresh udev somehow to get it to fix the permissions on the UPS, although we have had reports that the rules file silently fails on non-Debian-derived systems. -- Charles Lepple clepple at gmail
On 17/01/14 01:13, Charles Lepple wrote:> > Good point. I forgot that the permissions errors would happen after the numeric device IDs were matched. > > I just pushed 3c13603. Tested by telling the driver to match a random USB device instead of 0001:0000, and sure enough, when the driver didn't have write access, the unpatched code crashed. Not sure I want to try and send UPS polling commands to either a working UPS, or the mouse or keyboard, so I'll leave the rest of the testing to you :-)I see that the commit belongs to the master branch :) It correctly informs there's a permission error now.> scripts/udev/nut-usbups.rules should have an entry for 0001:0000 (although the comments mention a different driver). You may have to refresh udev somehow to get it to fix the permissions on the UPS, although we have had reports that the rules file silently fails on non-Debian-derived systems. >The rule in my config was: ATTR{idVendor}=="0001", ATTR{idProduct}=="0000", MODE="664", GROUP="nobody" I have to add OWNER=nobody or change the mode to make it work, upsd is running under the user nobody, but I see all the rules looks the same, probably I'm doing something wrong.
On Jan 17, 2014, at 6:31 PM, Ariel Wainer wrote:> On 17/01/14 01:13, Charles Lepple wrote: >> >> Good point. I forgot that the permissions errors would happen after the numeric device IDs were matched. >> >> I just pushed 3c13603. Tested by telling the driver to match a random USB device instead of 0001:0000, and sure enough, when the driver didn't have write access, the unpatched code crashed. Not sure I want to try and send UPS polling commands to either a working UPS, or the mouse or keyboard, so I'll leave the rest of the testing to you :-) > > I see that the commit belongs to the master branch :) > It correctly informs there's a permission error now.Oops, forgot to mention that it was merged. Once drivers start to work well enough for testing, I like to merge them in sooner rather than later. If we need to do any major refactoring, that would go on a branch temporarily.>> scripts/udev/nut-usbups.rules should have an entry for 0001:0000 (although the comments mention a different driver). You may have to refresh udev somehow to get it to fix the permissions on the UPS, although we have had reports that the rules file silently fails on non-Debian-derived systems. >> > > The rule in my config was: > > ATTR{idVendor}=="0001", ATTR{idProduct}=="0000", MODE="664", GROUP="nobody" > > I have to add OWNER=nobody or change the mode to make it work, upsd is > running under the user nobody, but I see all the rules looks the same, > probably I'm doing something wrong.Is that the working rule, or if not, which mode works? Also, what are the final permissions? The non-Debian udev problem seems to be that the entire rule was getting skipped, but it sounds like this might be a more subtle permissions mismatch. -- Charles Lepple clepple at gmail