search for: paths

Charles Lepple wrote: > > would you mind forwarding (to either me, or the list) the .txt file > showing the hidparser bug? I am trying to revamp libhid's hidparser, > and it would be helpful to have the descriptor. The text file is contained in the tarball on the patch tracker, at

I am currently having problems accesing our samba msdfs shares from Windows XP SP2, Windows 2000 and WinXP SP1 seem unaffected. I have attached the smb.conf and the exports files that define the shares. Running ethereal on the different clients seems to point to the fact that XP SP2 no longer seems to be using the netbios-ssn (139) port. for GET_DFS_REFERRAL instead its using microsoft-ds

I tested your fix (newhidups -DDD /dev/null) using both and APC Back-UPS 350 an APC Smart-UPS RT 2000 XL. No more segmentation fault due to the fixed-size array. ~Jacob -----Original Message----- From: nut-upsdev-bounces@lists.alioth.debian.org [mailto:nut-upsdev-bounces@lists.alioth.debian.org] On Behalf Of Peter Selinger Sent: Monday, October 16, 2006 12:12 PM To: Schmier, Jacob Cc: NUT

Hello, I'm using the stable amd64 port of Debian Linux. I installed (the latest) nut-2.0.1-4 and nut-usb packages for utilizing an APC Smart-UPS 1500 USB. I tried "apcupsd" first but "nut" makes an even more sophisticated impression on me and has more security options. I had problems with the newhidups driver. It didn't find a device with matching VendorID. And

On Jun 10, 2019, at 2:32 PM, Marc Finns wrote: > > Hello, I read all FAQ and other sources but I could not find this situation, so I thought of asking the experts. > I successfully configured a Raspberry NUT server to control my UPS that powers several devices (NUC with ESXI VMs, Synology NAS etc). > All works well in principle, but I have the following behaviours that I could not

Hi Peter, I got all your patches and applied them, and I wanted to say kudos for a great job done. This is the output of upsc that I'm getting right now. I had the same issue when using any cvs version (from two weeks ago) that made my UPS go into a state where it wasn't functioning normally (checking the kernel log shows that it cannot be connected and I had around a page of DEVFS_USB

My UPS is connected to a Raspberry Pi by USB. After a few hours of working, the service fails. Looking at kernel messages I noticed that the device is repeatedly disconnecting and reconnecting. I have tried using a different USB port and using a brand new USB cable. I have not had success by changing config parameters like pollfreq/pollinterval/etc. What is causing the UPS to keep disconnecting?

Gentlemen, I have a new HID USB device, that seems to be quite similar to the currently supported APC HID UPS. I append the dump-tree output, and would much appreciate advice on how to proceed. Certain entries for the current device are not available, but maybe there are some replacements that could be used. This may of course require a new table in apc-hid.h, and I would prefer not to do this

Hi I would like to be able to use this UPS with NUT please ? Product id = 53962KX Network UPS Tools - Generic HID driver 0.38 (2.7.2) USB communication driver 0.32 0.000000 debug level is '2' 0.002761 upsdrv_initups... 0.014996 Checking device (03F0/0024) (001/005) 0.032670 - VendorID: 03f0 0.032790 - ProductID: 0024 0.032955 - Manufacturer:

Hi, This might be a simple thing to fix, but I can?t figure it out. We replaced the battery for the first time in our Eaton 5PX a couple of weeks ago, but we haven?t been able to clear the ?ups.alarm: replace battery!? status. Details of our installation are: OS: Debian 6 NUT version: 2.7.4 Installation method: from source tarball UPS device: Eaton 5PX2000IRT, 240V, 1800W, 2000VA, bought in

...The search (for c32 files) is supposed to respect the following rules: > > > > 1_ The search for c32 files is performed according to the following > > rules. The search for each required c32 file is stopped once the first > > matching file name is found; remnant potential paths are not searched > > (even if the execution of the firstly-found c32 file fails in some way; > > e.g. unmatching version, unmatching firmware architecture). > > Correct. > > > 2_ Every required c32 file starts a new search (for itself); i.e. once > > a c32 fil...

Thanks for the reply. However these two FAQ are unfortunately not describing the situation. - The first issue is that NUT switches off the UPS upon reboot on low battery (not that it dies because of low battery) - The second issue is that the UPS does not recognise being online again (not that the PC does not restart) Sent from my iPhone > On 11 Jun 2019, at 02:03, Charles Lepple <clepple

...rifies a lot, as the "PATH rules" documentation is currently not clear enough about it. Now we can improve the documentation, and perform some tests. > > > And, for files referenced in the configuration files (i.e. > > non-dependencies files) using absolute notation paths, was the PATH > > directive supposed to search for them too? (If this last question is > > not clear enough, I'll post an example; please let me know.) > > Yes, the PATH directive is used as a fallback if the file denoted by an > absolute path doesn't exist. > &g...

I have a Tripp-Lite BCPERS450, connected to a system running Ubuntu 16.04.3 LTS and NUT 2.7.2-4ubuntu1.2. I had to make my own /lib/systemd/system-shutdown/nutshutdown, but now everything is working except for powering on and off the UPS. Regardless of the settings of offdelay and ondelay in upsconf, and regardless of whether the AC power is on, when I say "upsdrvctl shutdown" the UPS

Charles, It starts out good, then goes into a Connection timed out loop. If I can provide any information to fix a driver I'll do my best. Here's the output: # /usr/local/ups/bin/usbhid-ups -DD -a eaton Network UPS Tools - Generic HID driver 0.41 (2.7.4) USB communication driver 0.33 0.000000 debug level is '2' 0.002550 upsdrv_initups... 0.288229 Checking device

To all, I attempted to configure the UPS tools for the Tripp-Lite SmartOnline 1500VA 2U rackmount UPS. I followed the instructions from the 'upsdrvctl start' output and posted the diagnostic information below. Is my UPS using an unknown product ID as reported? From the mailing list archive, I have found another posting for the same UPS with device model '09AE/4003', whereas

...Matt Fleming <matt.fleming at intel.com> Date: Wed, 12 Jun 2013 13:04:44 +0100 Subject: [PATCH] PATH: Change the PATH directive syntax In retrospect, choosing the colon character as the entry separator for the PATH directive was not a smart move, as that character is also used in TFTP-style paths. This conflict manifests as PXELINUX being unable to find and load files. An example dnsmasq log looks like, dnsmasq-tftp: sent /arch/boot/syslinux/lpxelinux.0 to 192.168.0.90 dnsmasq-tftp: file /arch/ldlinux.c32 not found dnsmasq-tftp: file /arch//ldlinux.c32 not found dnsmasq-tftp: file /arch//...

On Wed, 12 Jun, at 11:17:44AM, Gerardo Exequiel Pozzi wrote: > Cool thanks!. Now looks better, but still not work. > > For some reason, "ldlinux.c32" is apparently sent but "Failed to load" > by PXELINUX and few seconds later, dnsmasq shows an error message > "failed sending": Argh! The patch was broken. I missed the new core/path.c file. My bad.

Oops... changing that to --with-user=nut solved one problem. I have the driver, upsd and upsmon running now. Thank you! Now I'm back to another issue, every 2 seconds I get in the logs: May 3 13:45:23 myhost upsd[2587]: Connected to UPS [eaton]: usbhid-ups-eaton It seems happy to do this forever. On Tue, May 3, 2016 at 8:17 AM, Charles Lepple <clepple at gmail.com> wrote: > On

..... > > > The search (for c32 files) is supposed to respect the following rules: > > 1_ The search for c32 files is performed according to the following > rules. The search for each required c32 file is stopped once the first > matching file name is found; remnant potential paths are not searched > (even if the execution of the firstly-found c32 file fails in some way; > e.g. unmatching version, unmatching firmware architecture). Correct. > 2_ Every required c32 file starts a new search (for itself); i.e. once > a c32 file is found, if additional c32 (depe...