Re: [Nut-upsdev] Changes to upscli_connect
Citeren Stuart D Gathman stu...@bmsi.com: Your test is with localhost - so any non-existent socket would get immediately rejected. The nut scanner has to deal with hosts on the network. If they send an ICMP reject, then there is no need for a timeout. But it is very common for a host to simply eat attempts to connect to a port not allowed in their firewall. So nut scanner needs a non-blocking version of upscli_connect. This probably won't scale very well. On a small /24 subnet this might be feasible, but as soon as you hit /20 (or even larger) this is impractical (let alone what will happen if you happen to use a /64 IPv6). For the purpose of auto-detecting servers I'd propose to resurrect the UDP code and broadcast the servers presence once every 10 seconds or so. Yes, this has its drawbacks too (to make sure the broadcasts reach the potential clients), but this has the advantage to be setup by a (knowledgeable) network administrator instead of an aspiring NUT user that has no clue where the server (s)he needs to connect to is located. Furthermore I don't think it is a good idea to add timeouts to the existing upscli_connect and/or make it non-blocking. What we're looking for in nut-scanner is something that quickly probes a large number of hosts for the presence of a server and only then initializes a connection. So preferably we would like to split the connection of the socket and the initialization of the protocol. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Changes to upscli_connect (and general discovery)
Citeren Charles Lepple clep...@gmail.com: I guess I see the scanning code as a stopgap way to contact legacy servers (or what would be legacy after some discovery protocol like mDNS is set up), and either timeouts or non-blocking is just a kludge to make that work a little better. And isn't opening a non-blocking socket just a way to split socket connection and protocol initialization? If that's the case, this should be handled by the nut-scanner itself. For any hosts found to be listening on port 3493 it would then proceed to use the upscli_connect call to check if it really is a NUT server. I'm *very* concerned that we're even considering making changes to the upsclient library for the sake of a tool that is meant for backwards compatibility. This library should be as light weight as possible. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Changes to upscli_connect (and general discovery)
Citeren Charles Lepple clep...@gmail.com: For the purpose of auto-detecting servers I'd propose to resurrect the UDP code and broadcast the servers presence once every 10 seconds or so. Yes, this has its drawbacks too (to make sure the broadcasts reach the potential clients), but this has the advantage to be setup by a (knowledgeable) network administrator instead of an aspiring NUT user that has no clue where the server (s)he needs to connect to is located. On the other hand, broadcasting presence is the kind of feature that would need to be enabled manually in order to be useful, and if enabled by default, would be a nuisance. Not necessarily. The upsd server could *also* listen to UDP broadcasts. So a nut-scanner would send a Who's there? packet to the broadcast address and all upsd servers listening would then reply to the nut-scanner. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Changes to upscli_connect (and general discovery)
Citeren Arnaud Quette aquette@gmail.com: I guess I see the scanning code as a stopgap way to contact legacy servers (or what would be legacy after some discovery protocol like mDNS is set up), and either timeouts or non-blocking is just a kludge to make that work a little better. And isn't opening a non-blocking socket just a way to split socket connection and protocol initialization? indeed. This isn't needed. Probing ranges of hosts listening on an arbitrary port doesn't require the upsclient library. For the hits, connect through the usual upscli_connect method, which by then you know will not block. as for the compat, IIRC Fred proposed a a new _tryconnect() method, upon which the standard _connect() would be mapped, with no behavior change. It is still unclear to me what we're trying to accomplish here, since auto-configuration is never going to work in environments where it is most needed (multi-UPS). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Changes to upscli_connect
Citeren Frédéric Bohé fredericb...@eaton.com: I am currently working on the nut scanner. For detecting available upsd on the network, I rely on upscli_connect. The problem with this function is that it calls a blocking connect function. This is a serious problem, not only for the nut-scanner but for basically all nut clients we currently bundle. So the nut-scanner is blocked while waiting for the TCP timeout when trying to connect to an IP without upsd available . Since this timeout may be rather long (3 minutes on my host), I would like to add a timeout parameter to upscli_connect. I don't think this is a good idea. I propose to add a upscli_tryconnect function accepting a timeout parameter, which will be the copy of the current upscli_connect + the management of the timeout. The upscli_connect will be only a wrapper on top of upscli_tryconnect, calling it without timeout. Please let me know if this makes sense to you. The upscli_connnect() call should not block. If it does, that is a problem that needs fixing, rather than adding an timeout. On what kind of system did you test this? If I attempt to connect upsmon to a non-existing server socket, the following is shown (-DDD): 0.001902 Trying to connect to UPS [myups@localhost] 0.002667 UPS [myups@localhost]: connect failed: Connection failure: Network is unreachable 0.002690 do_notify: ntype 0x0005 (COMMBAD) 0.002704 Communications with UPS myups@localhost lost Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r3048 - branches/nut-scanner/tools/nut-scanner
Citeren Frederic BOHE fbohe-gu...@alioth.debian.org: Modified: branches/nut-scanner/tools/nut-scanner/scan_snmp.c == --- branches/nut-scanner/tools/nut-scanner/scan_snmp.c Fri Jun 17 08:12:00 2011 (r3047) +++ branches/nut-scanner/tools/nut-scanner/scan_snmp.c Tue Jun 21 07:56:55 2011 (r3048) @@ -101,8 +101,12 @@ dev-type = TYPE_SNMP; dev-driver = strdup(snmp-ups); dev-port = strdup(session-peername); - snprintf(buf,sizeof(buf),\%s\, -response-variables-val.string); + /* get the name aof the device and add */ + memset(buf,0,sizeof(buf)); + buf[0] = ''; + memcpy(buf+1,response-variables-val.string, + response-variables-val_len); + buf[1+response-variables-val_len] = ''; add_option_to_device(dev,desc,buf); add_option_to_device(dev,mibs,snmp_device_table[index].mib); /* SNMP v3 */ What is the reason to switch from the (buffer overflow) safe 'snprintf' method to the above unsafe way of doing this? I'm not too thrilled about this. If you want to copy 'response-variables-val_len' bytes, the proper way to do this is to use snprintf(buf,sizeof(buf),\%.*s\, (int)response-variables-val_len, response-variables-val.string); instead. Please remember to use the log comments to explain why a patch is submitted. We need these comments to generate the ChangeLog. Not doing this, requires someone to guess your reasons and add them manually, which is just a waste of effort. Thank you. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] UPS driver for Online USV-Systeme Zinto A
Citeren Christian \Eddie\ Dost e...@brainaid.de:
The basic differences in protocol are:
There is no I command, but a FW? command to request firmware
version. Q1 and F are there.
Is the reply format the same? If so, this is trivial to add in the
blazer.c global 'command' structure, by appending a line
{ zinto, Q1\r, F\r, FW?\r },
If not, this will have to be done via a configuration option in 'ups.conf'.
The main reason I wanted support for the Zinto UPS was to be able to
configure it. There are several settings to configure:
- ups.start.auto: Auto-Start after back online, boolean AR0,
AR1, request current setting with AR?, response will be AR0 or
AR1.
OK.
- ups.test.auto: Enable or disable automatic selftest, command
ATx, same as ARx above.
This is (too) similar to the 'ups.test.interval' we already have. I
propose to map these values to either '0' (no automatic testing) and
the number of seconds between tests (automatic testing enbled).
- battery.energysave: Turn off load when on battery and load is very
small, command GRx, same as ARx above.
OK.
- battery.discharge.longtime: Configure UPS to longtime discharge
(small load for long duration), command SDx, same as ARx above.
SD1 means standard, SD0 means long time discharge.
It's unclear to me what this actually does. Is it used to allow deep
discharging the battery (what nut calls battery.protection on/off) or
does it change the threshold when the UPS decides the battery is low
(this would need to be lower in case of high rate discharge). I
sincerely hope it is the first, otherwise the engineers at Zinto did a
lousy job. You need to measure the load when running on battery
anyway, so adjusting this automatically is trivial.
- input.sensitivity: Configure trigger points for low/high input
voltages. Command IPx, where x is N, W, G, or ? for
normal, wide, generator input and ? to request current setting.
OK.
- output.voltage.nominal: Configure output voltage when running on
battery. Command Vxxx where xxx is 220, 230, 240 or 110, 120, 127.
This setting is echoed back in the F command.
Is this auto ranging (ie, a low mains unit would allow 110, 120 and
127 and a high mains unit 220, 230 and 240)?
If we can design a probing scheme to detect the FW? command maybe
and add these settings to the blazer driver, I'd agree to integrate
the code.
Like it or not, but the chances that a separate driver with the above
properties would make it into mainstream NUT is close to zero. The
added value of these settings by no means justifies the added
maintenance burden that would be required by adding another one.
Auto detection of models in this class of UPS devices is limited. We
already know of several units that lock up if you send them
unsupported commands, so probing with a command and see what's
returned is not likely to be included. It would be less risky to add a
configuration option to select a model instead.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] on Ubuntu Developer Summit (Oneiric), NUT and 2.8.0
Citeren Charles Lepple clep...@gmail.com: This seems ambitious for a few months. Then again, there's the old quote about the person saying it can't be done shouldn't get in the way of the person who is making it happen :-) Full ack. I'm not sure how much time I can spend on NUT, but especially the Windows port integration is something that makes me very uneasy. In its present state, I'm not too thrilled about the way it is integrated in the sources. It seems we're getting back to massive amounts of #if(n)def's in many critical parts of the code. I'd rather see this being integrated by putting the functions that are UNIX / Windows / other OS specific in separate modules and link in the appropriate version when we build the binaries. [...] * I would also propose that one of the first commits on a feature branch should be a little more description of the requirements, or design ideas. I'd too like to see a roadmap (the announcement of 2.8.0 months before is a good starting point). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Environment Variables
Citeren Keven L. Ates atesc...@gmail.com: Rewrite anyone? Just a quick question, do you have a clue what PID files are used for? Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] NUT: new blazer_usb subdriver proposal
Citeren Aurélien Grenotton agren...@gmail.com: After some investigation, they almost use the krauler-type communication already supported in the blazer_usb driver. However, the UPS won't reply if the language ID is not 0x4095... Therefore, I cloned the krauler_command, adding the language ID and unicode to ASCII conversion (taken from libusb). Thanks for this patch. I also enhanced the error!retry mechanism, as the UPS fails to reply quite often. This will put you at risk for (much more severe) timeout problems with the upsd server, so this part of the patch will not be included. But since this seems to be a problem for other devices as well, there is some merit in the problem you're trying to fix. We probably shouldn't complain in the syslog for intermittent problems and only report once we have reached the MAXTRIES limit. This needs to be fixed in the 'blazer.c' base driver (which I did). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] RFC: adding new data ups.efficiency
Citeren Arnaud Quette aquette@gmail.com: we (Eaton) have created a new data to expose efficiency of the UPS (basically it is the ratio of the output current on the input current). I know that at least APC should also provide it on some units, since I've seen evidence in an EPA presentation [1]. So I'd like to create the following new data: - Name: ups.efficiency - Description: Efficiency of the UPS (ratio of the output current on the input current) (percent) - Example value: 99 As usual, comments and feedback are very welcome... Two comments: 1) What would be reported if the UPS is running on battery? There clearly would be no input power at that time. What is reported in that case? 2) Calculating the efficiency based on the ratio of input and output *current* leaves a giant loophole to artificially increase the reported efficiency. On an online UPS one could increase the 'efficiency' by setting the output voltage a few percent above the input voltage. Similarly, if a system would have a near unity power factor on the input, but a crappy one on the output, you'd also inflate the reported efficiency by using the RMS figures. I'd only see some merit in reporting this, if it would be the ratio of input and output real power values. I would be surprised if in a real world scenario however if one would get very close to 99% (if not in running in bypass mode). A more typical value of a double conversion UPS would be something between 90-95% and even then only when the UPS is properly scaled for the designed load. The good thing would be that people might be made aware how much power they are wasting, given that fact that in many cases a UPS will not be operated near the optimum efficieny load. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Patch to support GE EP series
Citeren Danilo Godec danilo.go...@agenda.si: The UPS has both RS232 and USB connection. To use the RS232 connection, I had to use the 'cablepower = none' as the UPS is using only RX, TX and GND pins. If the UPS really only uses the RX and TX pins, the setting of 'cablepower' is irrelevant. So my 'usp.conf' was a bit like that: [myups] driver = blazer_ser port = /dev/ttyS0 cablepower = none desc = Local UPS To use the USB connection required a bit more work, but I eventually found out what it takes: [myups] driver = blazer_usb port = /dev/ttyS0 # probably irrelevant vendorid = 14f0 productid = 00c9 subdriver = phoenix desc = Local UPS Have you also tried *all* the other subdrivers? The 'phoenix' subdriver was an early attempt to work around some issue we found in a particular USB to serial converter, which later turned out to be better solved in the 'ippon' subdriver. Make sure you have also tested the latter. I also made a patch so I don't need to define 'vendorid', 'productid' and 'subdriver' in config, but since I'm not a programmer, the patch is mostly 'guesswork'. The patch is against nut-2.6.0 release. I hope this list accepts attachments... We do. I'll commit the changes to the development version once we've ironed out the last things here. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Static code analysis (was: SSL test regression)
Citeren Arnaud Quette aquette@gmail.com: just to revive the static code analysis thread... It would be nice if you could expose your ideas and the results of your tests. Also, apart from Splint, have you tested any other systems? From what I see, Splint and Frama-C are probably the most interesting. Well, the situation hasn't changed much. Even with the latest splint I have tried (3.1.2), you still need a *load* of markup to get useful output. I'm not sure if this is worth the effort, as you'll have to carefully consider each time if the offending line of code should be ignored (by adding a directive) or needs changing. Most annoying problem is that sometimes even system header files (!) require markup and I really don't want to go that route... Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] HP-UX compilation warnings
Citeren Arnaud Quette aquette@gmail.com: @Arjen: if you want to test some possible fixes, you can commit on the HPUX branch, so that Chetan can test it without the need for buildbot slaves. The problem has already been fixed in the trunk, by removal of the AX_CREATE_STDINT_H macro and relying on either inttypes.h or stdint.h to provide the fixed length types. Rationale behind this is that we already require (a minimal set of) POSIX compliance for several other things. POSIX requires that inttypes.h exists, so it makes no sense to roll our own here. In the current state, all buildbots seem to be happy and compile without warnings. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2946 - in branches/windows_port/scripts/Windows/Installer: . ImageFiles/Others
Citeren Frederic BOHE fbohe-gu...@alioth.debian.org: +REM copy DLL files from system +copy /Y c:\mingw\msys\1.0\bin\msys-1.0.dll .\ImageFiles\Others +copy /Y c:\mingw\msys\1.0\bin\msys-crypto-1.0.0.dll .\ImageFiles\Others +copy /Y c:\mingw\msys\1.0\bin\msys-ssl-1.0.0.dll .\ImageFiles\Others +copy /Y c:\mingw\bin\libgnurx-0.dll .\ImageFiles\Others How can we be sure that these files are located in the c:\mingw\msys\1.0\bin\ and c:\mingw\bin\ directories? Or even that this directories exists at all? If someone decides to install this in a different location, we're toast. When it is impossible to autodetect these paths, they should at least be configurable. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
[Nut-upsdev] Remove AX_CREATE_STDINT_H
I doubt we still need to create our own fixed width integer types. We already expect IEEE Std 1003.1-2001 compliance, so the availability of either inttypes.h or stdint.h is implied. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Initialising UPS variables from ups.conf
Citeren John Bayly freebsd.po...@tipstrade.net: Are there any plans to allow us to specify UPS variables in ups.conf, eg: We already support this (as a hidden feature) since nut-2.4.0, where it is possible to set default.variable = value (default to value if UPS doesn't report this) override.variable = value (same, but override if reported by UPS) But most likely, this is not what you need. [evo_s_3000] driver = usbhid-ups port = auto desc = Eaton Evolution S 3000 vendorid = 0463 productid = ups.delay.shutdown = 120 ups.delay.start = 130 You probably missed the man page for the usbhid-ups driver. See 'offdelay' and 'ondelay' under EXTRA ARGUMENTS in 'man 8 usbhid-ups' which are meant to do what you want. Using the '(default|override).ups.delay.(start|shutdown)' mechanism might also work, but this is not recommended. The reason I ask is that I'm using FreeBSD gmirror and need to extend the gracetime for the system to shutdown. For the moment, I've created a custom shutdown script that is set in upsmon.conf that does the job. I doubt it. #!/usr/local/bin/bash /usr/local/bin/upsrw -s ups.delay.start=130 -u haltuser -p somepassword evo_s_3000 /usr/local/bin/upsrw -s ups.delay.shutdown=120 -u haltuser -p somepassword evo_s_3000 /sbin/shutdown -h +0 This most likely doesn't work, since the changed values of 'ups.delay.start' and 'ups.delay.shutdown' won't stick between invocations of the driver. Only if you keep the driver running and send the instcmd 'shutdown.return' this might work, but this is not what happens if you call 'upsdrvctl shutdown' (where the driver is restarted with the -k flag). You *must* use ondelay and offdelay instead. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Initialising UPS variables from ups.conf
Citeren John Bayly freebsd.po...@tipstrade.net: I'll look into how that works, thanks. These look like they do exactly the job for specifying the delays for the switched outlets (outlet.1.delay.start). I don't think so. Why don't you just use 'upsrw' to change these values? These are supposed to be R/W values in the UPS. Is there any reason why they're a hidden feature? Well, basically because we have not taken the time to document them. Part of the reason why this is so tricky, is that you'll also have to be careful when to use them. Note that these values only change the way how variables are stored internally in the dstate variable tree. If a driver doesn't use that tree to base decision on, you'll only change the reported values (upsc) and the driver will still use the actual values from the UPS. That will make for some interesting debugging... Should I rely on this remaining? I use it (need it, see below) so it probably will stay with us for quite some time. :-) Is it driver specific? It is not driver specific, but really only meant to provide values for variables the UPS doesn't report, but which we really want it to report (default) or for values that are obviously wrong (override). For instance, my MGE Evolution 650 happily reports battery.voltage = 13.0 battery.voltage.nominal = 24 while it actually uses a 12 V battery system (unlike it's bigger siblings, which indeed have a 24 V battery). In order correctly display the battery voltage meter in the CGI scripts, I use override.battery.voltage.nominal = 12 in my ups.conf to correct this. Obviously, this only works for (semi)static values, you can't use this for dynamic things like input voltage or temperature (you could actually, but it wouldn't make sense). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [RFC apcsmart V3 08/18] drivers/dstate: add dstate_getflags()
Citeren Michal Soltys sol...@ziu.info: In cases such as immutable flag over readable value, we have to be able to acquire this info at driver level (to e.g. avoid polling, if user defined a variable with 'override' prefix). I'm not sure I like this. While it may seem a waste of effort to poll for a variable and ignore the value later on, I'd prefer to do this in one location (the dstate_*() functions) and not in the driver as well. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [RFC apcsmart V3 09/18] drivers/apcsmart: add APC_USERCTRL and APC_CRUCIAL
Citeren Michal Soltys sol...@ziu.info: APC_USERCTRL - allows permanent overriding of the variable. Meaning even if the ups supports reading and/or writing it, the driver will not allow it (actually it will behave as if the variable wasn't supported at all). This guarantees that the value set by the user in the configuration file is respected. This is already the case. By disallowing the flags to be changed once the ST_FLAG_IMMUTABLE is set, the variable should no longer show up in the list of supported variables and the main driver code will disallow changing the value. Currently only battery.runtime.low overriding is allowed, which is necessary for proper functioning of ignorelb (if user decided to override that variable). I'm not sure if I understand correctly what you're trying to do here, but drivers should respect the ST_FLAG_IMMUTABLE at all times. Even if the set value makes no sense at all, if people deliberately override a value, this is what they should get. APC_CRUCIAL - this flag enforces checking if the variable is actually supported. That might be a good idea, but for the above reason I have not committed this patch now. Additionallly - the driver will ask user about reporting UPS models, which don't support command querying, but do support firmware query - in the other words - models which are not present in the compatibility table, but should be included there. Good idea too, but be aware that the response to such messages has typically been very low. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [RFC apcsmart V3 01/18] drivers/apcsmart.h: comsetics - adjust tabs and add basic modeline
Citeren Chuck Anderson c...@wpi.edu: On Sat, Mar 05, 2011 at 11:38:18AM +0100, Michal Soltys wrote: Signed-off-by: Michal Soltys sol...@ziu.info --- drivers/apcsmart.h | 28 +++- 1 files changed, 15 insertions(+), 13 deletions(-) Could you please integrate my minor compat additions with your patch series? I've attached that patch here, having not heard anything when I posted this separately. I'd be happy to test the entire series of patches with my Matrix-3000. Done. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [RFC apcsmart V3 13/18] drivers/apcsmart.c: update in-driver help information
Citeren Michal Soltys sol...@ziu.info: Signed-off-by: Michal Soltys sol...@ziu.info --- drivers/apcsmart.c | 93 +++- 1 files changed, 84 insertions(+), 9 deletions(-) Committed with changes. Note that we prefer to have explanations of variables in the manual pages, rather than in the drivers help option. To keep things in sync, it is better to document this in only one location. If you can explain an option in a single line, it's probably OK to add it here, but if you need a lot of text, it is more appropriate to put it in the manual. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [RFC apcsmart V3 16/18] drivers/apcsmart.c: don't overuse UPSDELAY
Citeren Michal Soltys sol...@ziu.info: This delay is meant for multicharacter commands, besides we always guarantee delay by other means - so do the stuff properly. [...] upsdebugx(1, On-line - forcing OB temporarily); ser_send_char(upsfd, 'U'); - usleep(UPSDELAY); Sleeps for 50ms. + ser_get_line(upsfd, temp, sizeof(temp), ENDCHAR, IGNCHARS, SER_WAIT_SEC, SER_WAIT_USEC); Waits for a newline character to arrive for up to 3 seconds (which is quite a bit longer). [...] - usleep(UPSDELAY); - ser_flush_in(upsfd, IGNCHARS, nut_debug_level); Sleep for 50ms and discard any character we have received in the mean time. + ser_get_line(upsfd, temp, sizeof(temp), ENDCHAR, IGNCHARS, SER_WAIT_SEC, SER_WAIT_USEC); Waits for a newline character to arrive for up to 3 seconds (which is quite a bit longer). Note that if you use a text protocol (which seems to be the case here), canonical mode input processing may be a huge time saver: http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_delays_and_ser_functions http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_canonical_input_mode_processing Using canonical input processing eliminates the need for delays between sending commands and reading back the reply line (and prevents an endless amount of selects when not all data is available on the first try). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [RFC apcsmart V3 18/18] drivers/apcsmart: use STAT_INSTCMD_{HANDLED, FAILED} for sdcmd_*()
Citeren Michal Soltys sol...@ziu.info:
As we want the user to be able do issue all shutdown methods manually,
adjust sdcmd_*() to use STAT_INSTCMD_{HANDLED,FAILED}, so they can
be used directly.
The above is a good idea.
Also minor text corrections, and APC specific command renames.
This isn't. You really should stick to the existing set of commands
and try to map the APC specific commands to existing ones. If you
think this is not possible, this should first be discussed here before
we will add them.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
[Nut-upsdev] Fwd: Ever Company UPS drivers
Please use the mailinglist to ask for support. - Forwarded message from siwin...@ever.com.pl - Date: Mon, 21 Feb 2011 13:21:28 +0100 From: Szymon Iwiński siwin...@ever.com.pl Subject: Ever Company UPS drivers To: nut-upsdev-ow...@lists.alioth.debian.org Dear NUT Developers, First of all I would like to introduce myself, my name is Simon Iwiński and for some time right now I'm working in Ever Company that design and builds UPSes from scratch. I'm responsible mostly for proper functionality of Evers IT sector but lately also for our dedicated application (called PowerSoft) testing and development. Recently I've heard about NUT from one of our clients, that uses it for a long time now. He was quite disappointed that none of our modern products, was supported by NUT Project. In order to understand how it works I've installed NUT on my Debian machine and I have to admit that its terrific. In this occasion I would like to thank (by I think everybody who uses it aswell) for making this awesome tool, I can only imagine how much time does it take to create something that works so well. Secondly I would like to kindly ask You NUT Developers is it possible to write down new drivers to our products? Of course ill send any necessary technical documentation needed for that process. Please let me know if its possible, I personally regret that we got only one star on Hardware Compatibility List. ___ Regards, Szymon Iwiński Młodszy Konstruktor - Informatyk EVER Sp. z o. o. 62-020 Swarzędz ul. Grudzińskiego 30 tel. 061 6500 400 fax 061 6510 927 http://www.ever.com.pl www.ever.eu Siedziba firmy: Swarzędz 62-020, ul. Grudzińskiego 30 Sąd Rejestrowy: Sąd Rejonowy w Poznaniu KRS 118365 Kapitał zakładowy: 90 000 PLN - opłacony w całości REGON: 631529798 NIP: 779-00-20-672 - End of forwarded message - ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [PATCH/RFC 1/1] APC smart driver update and new features.
Citeren Michal Soltys sol...@ziu.info: the likely options are: - handle this at driver level - e.g. preserve the immutable flag if already set without setting rw (if necessary, e.g. in apcsmart if ignorelb is set), ignore polling, adjust the code so it works fine, etc. - go back to minbatt/mintime - add e.g. ST_FLAG_USER_OVERRIDE which would be used for any (and only for) override.* in ups.conf (instead of ST_FLAG_USER_IMMUTABLE), while not being encumbered by must not be rw constraint The 1st option looks good ? After some more thoughts, the first suggestion indeed seems the best. We really should allow people to override values, regardless of the fact that these may be writable. An override should really be that, unlike setting a default value where the value from the UPS would take precedence. The trunk version has now been changed to do just this and also adopts your idea of setting 'ignorelb' on a global level to ignore any set_status(LB) settings by drivers. It calculates this flag instead from battery.charge (battery.runtime) and battery.charge.low (battery.runtime.low) and also warns if insufficient data is available to do so. Thanks for your feedback. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [PATCH/RFC v2 0/3] Updates to ACP smart driver
Citeren Michal Soltys sol...@ziu.info: So, any +/- comments about this approach ? The reason why it is taking me so long to adopt this, is the reason that (although you separated this is three chunks) the changes to the apcsmart driver require to change the LB processing at the same time. I'd prefer to delay that part of the patch until we have had time to really dig into this. As told before, I'm OK with the remainder of the changes you made. I'd prefer it if you could keep the LB out of this patch and let me handle this part (since this goes deep into the internals of drivers). One thing that I found out already, is that main.c is not the proper place to do this. This should really be handled in the status_commit() in dstate.c to prevent toggling between two states (this isn't pretty). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Bug/Patch for NUT 2.6.0 ; usbhid-ups (libhid.c)
Citeren Richard Gerth r.gerth@gmail.com: I'd be happy to do testing. Just let me know when... In order to get some useful feedback for the -pre versions may I suggest to subscribe people that are willing to test upcoming releases to 'nut-upsannounce'? Currently, there seems to be nothing but spam in the archives (so we probably want to clean that out some day) and use this (read-only) list for announcements of -pre and stable versions only. I would very much welcome some testing on systems other than the developers have (most crucially, with different UPS hardware) *before* we release a stable version. As of now, we get no feedback at all for the -pre versions, which means these are currently a waste of effort. I'd like to change that, since it will improve the quality of the stable versions before we release them and will prevent us from having quite broken versions in the field. Comments? Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Bug/Patch for NUT 2.6.0 ; usbhid-ups (libhid.c)
Citeren Richard Gerth r.gerth@gmail.com: I'm using openSUSE 11.2 My usblibs are thus: bach:/usr/lib # ls -l libusb* lrwxrwxrwx 1 root root19 Jan 11 2010 libusb-0.1.so.4 - libusb-0.1.so.4.4.4* -rwxr-xr-x 1 root root 17940 Oct 23 2009 libusb-0.1.so.4.4.4* lrwxrwxrwx 1 root root19 Jan 11 2010 libusb-1.0.so - libusb-1.0.so.0.0.0* lrwxrwxrwx 1 root root19 Jan 11 2010 libusb-1.0.so.0 - libusb-1.0.so.0.0.0* -rwxr-xr-x 1 root root 50884 Oct 23 2009 libusb-1.0.so.0.0.0* lrwxrwxrwx 1 root root19 Jan 11 2010 libusb.so - libusb-0.1.so.4.4.4* My computer's package manager says I have installed: libusb 1.0 and a compatibility layer libusb-1_1-4 I've used openSUSE 11.2 in the past too (using 11.3 now) and have never seen such a problem with any of the USB connected UPS'es I tried, so this pretty much rules out a libusb issue. It must be vendor/device specific, probably the reason why the developers don't see this. Since we're not able to do anything with reports that are *longer* than expected anyway, we can safely assume that anything in excess of the number of bytes that we calculated from the report descriptor can be discarded. Therefor I have restored the nut-2.4.1 behavior of only reading the number of bytes expected. Thanks for reporting this. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Bug/Patch for NUT 2.6.0 ; usbhid-ups (libhid.c)
Citeren Richard Gerth r.gerth@gmail.com: Thank you for looking into this. And thank you (to you and the other developers) for NUT -- it's fantastic to have such a great open source UPS application. Would you be willing/able to test future releases of NUT? One thing that we're currently lacking is a group of people that can check upcoming releases. Most of NUT is generic and can be tested by the developers, but when it comes to testing drivers we need the actual hardware (UPS). Since you have a device that behaves differently than the ones the developers have access to, I think it would be a good idea if you could confirm the usbhid-ups driver still works if we plan on releasing a new stable version. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Bug/Patch for NUT 2.6.0 ; usbhid-ups (libhid.c)
Citeren Richard Gerth r.gerth@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 (-D) 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) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Getting started generating new MIB-to-NUT mapping for unsupported interface
Citeren Philip Tait phi...@naoj.org: Would appreciate guidance on getting started generating a MIB-to-NUT mapping (tools, etc): OS: CentOS 5.5 NUT version 2.6.0 Assuming that you're able to successfully build NUT from sources, you're all set. Unlike USB HID PDC subdrivers, we have no automated tools available to generate a OID to NUT mapping. So basically what you need to do is create this mapping yourself. The 'ietf-mib.[ch]' files in the drivers/ directory of the sources should provide you with a starting point. With a bit of luck, you might be able to get your device supported by just modifying the entry point. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] SNMP And SuSE
Citeren Eric Wilde ewi...@gntrains.com: Fair enough. The germane portion of the config.log file is: configure:7703: checking for init_snmp configure:7703: gcc -o conftest -DINET6 -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fno-strict-aliasing -fstack-protector-all -Dlinux -I/usr/include/rpm -I/usr/include conftest.c -L/usr/lib64 -lnetsnmp -lcrypto -lm -L/usr/lib -lwrap 5 /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lwrap collect2: ld returned 1 exit status As you know, configure can be asked to test for the presence of a library by building a small program that references a well-known entry point in that library and then running it through the compiler/linker. This not only tests that the library is there but that the options given to configure actually work when compiling and/or linking. I wrote many of these test (this one too actually), so yes, I'm fully aware of that. In this case, it is the bogus -lwrap returned by net-snmp-config that is the problem, not the net-snmp library or where it is installed, etc. This problem needs to be fixed upstream and as far as I know, it has been fixed in later versions (my openSUSE 11.3 buildbot doesn't seem to include this library anymore in the net-snmp libraries). In the general case, we have no possibility to test whether or not all libraries listed by pkg-config, net-snmp-config or similar tools are really required. We allow overriding most of the auto detected values by providing them on the configure command line if you find an error in them and don't want to wait for the problem to be fixed upstream (if it ever will). This is as far as we will go in fixing this. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] SNMP And SuSE
Citeren Eric Wilde ewi...@bsmdevelopment.com: Attempting to install the SNMP driver on Enterprise SuSE 10.0. The version of NUT is 2.6.0. [...] The claim that the library doesn't exist is incorrect. The script is not able to find the required libraries, it doesn't say they don't exist. In order to find out what's wrong, we really need the 'config.log' that is generated. You also might be able to direct configure in the right direction by providing it with the --with-snmp-cflags and --with-snmp-libs options, instead of hacking configure. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [PATCH/RFC 1/1] APC smart driver update and new features.
Citeren rasengan rootish r...@relay.ppgk.com.pl: So basically what you have in mind is putting such checks in main.c's loop somewhere after upsdrv_updateinfo() call, and then updating ups.status ? Yes. That would also warrant adding options enabling such functionality (separately for charge and runtime), as not everyone might want it. No. If both 'battery.charge' and 'battery.charge.low' are present, there is no need to make this configurable. A UPS that supports them out of the box, will already set the LB flag (so there is no possibility to change that). If you don't want this added functionality, don't set a default value in 'ups.conf' (similar for runtime). In case you happen to have a UPS that does report both 'battery.charge' and 'battery.charge.low' but for some mysterious reason doesn't use that to set the LB flag, you can always use 'override.battery.charge.low=0' to disable it. I'll redo the patches with the new approach. Thanks. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2853 - in branches/windows_port: drivers include
Citeren Frederic BOHE fbohe-gu...@alioth.debian.org: Modified: branches/windows_port/include/wincompat.h == --- branches/windows_port/include/wincompat.h Wed Jan 26 15:05:16 2011 (r2852) +++ branches/windows_port/include/wincompat.h Wed Jan 26 15:16:09 2011 (r2853) @@ -28,6 +28,7 @@ #include common.h #define sleep(n) Sleep(1000 * n) +#define strtok_r(a,b,c) strtok(a,b) /* Network compatibility */ You probably want to use +#define strtok_r(a,b,c) strtok_s(a,b,c) here. I'm not sure that never tokenize multiple strings at the same time (in which case using strtok() would severely break). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [PATCH/RFC 1/1] APC smart driver update and new features.
Citeren Michal Soltys sol...@ziu.info: Summary: - new driver options: ignorelb, minbatt, mintime, wugrace, advorder - expanded: sdtype - few more types in compatibility table - minor fixes and adjustments First of all, thanks for the effort of working on this driver. The lack of an active developer for APC units has worried us for some time already, given the popularity of the brand. Most of the patches are good to go, with the exception of the 'minbatt' and 'mintime'. These are generic functions that I would prefer to see included in the main driver core, rather than in each driver individually. We already support adding missing constants (default.battery.charge.low) or overriding wrong ones (override.battery.charge.low) in 'ups.conf'. The only thing that is missing now in the driver core are the checks battery.charge battery.charge.low battery.runtime battery.runtime.low Adding the above is trivial and would then be usable for all drivers. Therefor I don't think it is a good idea to do this here. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2845 - branches/windows_port/common
Citeren Frédéric Bohé fredericb...@eaton.com: + static const char *path = getfullpath(PATH_ETC); getfullpath is allocating memory with xstrdup. Doesn't this line produce a memory leak ? Nope. Whenever you do an assignment to a static variable, this is only done once. So the getfullpath() function will be called the first time you enter this function and afterwards, the result of this call will be used. Unlike an ordinary automatic variable, static variables defined in functions are preserved between calls. We usually prefer static local variables over global ones, because it prevents namespace conflicts and also prevents other function from messing with the variables. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] apcsmart.c question
Citeren Michal Soltys sol...@ziu.info: - in upsdrv_shutdown(), there're loads of printfs - they kinda look like a leftover from older debug times. Shouldn't they be changed into upsdebugx() or upslogx() ? This is pointless. The part of the code is typically run near the end of the system halt script. By that time, you won't have write access anymore (so the syslog is no longer available). Since the system is about to power off, there is not much to gain by converting this to upsdebug calls. In many cases, you won't have the time to read them anyway. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Client certificates
Citeren Stuart D. Gathman stu...@bmsi.com: One advantage to client certs is that it avoids weak passwords - but the client could protect their private key with a weak password. In case of upsmon, this is a huge waste of effort. The upsmon client has very little (master) or none at all (slave) influence on the operation of the server. The worst that can happen, is that a upsmon master sets the FSD on the uspd server, triggering a power cycle of all connected devices. All a upsmon slave can do, is delay shutting down for a handful of seconds. You should not grant any other privileges to these users. You could also assign random strong passwords to clients to avoid weak passwords. What you need to protect, is the username/password combination for users that need more privileges on the upsd server (the ones that need to run upscmd and/or upsrw). You should *never* grant those privileges to users that run upsmon. Since we don't offer SSL in either upscmd or upsrw, these commands should only be run locally (through a secure shell for instace), where snooping passwords is not an issue. Only the administration user needs a strong password and probably be restricted to connect only through the localhost address. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] SSL certificate verification with OpenSSL in NUT trunk
Citeren emilien...@eaton.com: With a clean trunk checkout, compile and installation; and with the following config : upsmon.conf: CERTPATH /usr/local/ups/etc/cert/ CERTVERIFY 1 FORCESSL 1 First off, you're not supposed to use both CERTVERIFY and FORCESSL. FORCESSL is intended to be used in cases you can't verify the validity of a certificate, but still want to enforce the use of any presented. See the 'docs/ssl.txt' from the nut-2.4.3 branch (this file didn't make it into AsciiDoc). So, do I misunderstand CERTVERIFY directive ? Or is there a bug ? Can you reproduce such behaviour ? I'm not sure what is going on. Can you try running 'upsmon' with debugging enabled? The following are the results of my tests here. In all cases, the upsd server is running with a valid PositiveSSL certificate (so the root CA that signed this certificate is trusted without further configuration): upsmon.conf (valid): CERTPATH /etc/ssl/certs/ CERTVERIFY 1 #upsmon -DD Network UPS Tools upsmon 2.6.0-pre1-2819 0.00 UPS: mge-usb@localhost (master) (power value 1) 0.000457 Using power down flag file /etc/killpower 0.000962 debug level is '2' 0.003348 Trying to connect to UPS [mge-usb@localhost] 0.024697 Logged into UPS mge-usb@localhost 0.025804 pollups: mge-usb@localhost [SSL] 0.026283 parse_status: [OL CHRG] --- upsmon.conf (demo CA, not the one that signed the server certificate): CERTPATH /etc/ssl/certs/demo CERTVERIFY 1 #upsmon -DD Network UPS Tools upsmon 2.6.0-pre1-2819 0.00 UPS: mge-usb@localhost (master) (power value 1) 0.000465 Using power down flag file /etc/killpower 0.001071 debug level is '2' 0.003841 Trying to connect to UPS [mge-usb@localhost] 0.016105 Can't set username on [mge-usb@localhost]: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 5.016263 pollups: mge-usb@localhost 5.016345 Poll UPS [mge-usb@localhost] failed - Driver not connected 5.016368 do_notify: ntype 0x0005 (COMMBAD) 5.016402 Communications with UPS mge-usb@localhost lost 5.016771 Dropping connection to UPS [mge-usb@localhost] --- upsmon.conf (empty directory): CERTPATH /etc/ssl/certs/empty CERTVERIFY 1 # upsmon -DD Network UPS Tools upsmon 2.6.0-pre1-2819 0.00 UPS: mge-usb@localhost (master) (power value 1) 0.000481 Using power down flag file /etc/killpower 0.000942 debug level is '2' 0.004245 Trying to connect to UPS [mge-usb@localhost] 0.016430 Can't set username on [mge-usb@localhost]: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 5.016599 pollups: mge-usb@localhost 5.016682 Poll UPS [mge-usb@localhost] failed - Driver not connected 5.016705 do_notify: ntype 0x0005 (COMMBAD) 5.016724 Communications with UPS mge-usb@localhost lost 5.017086 Dropping connection to UPS [mge-usb@localhost] --- So whatever I try, if a valid certificate is not found, upsmon doesn't seem to connect. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] SSL certificate verification with OpenSSL in NUTtrunk
Citeren emilien...@eaton.com: Reverting commit r2819 seems fixing the problem. Index: /trunk/clients/upsclient.c === --- /trunk/clients/upsclient.c (revision 2724) +++ /trunk/clients/upsclient.c (revision 2819) @@ -387,5 +387,5 @@ } - SSL_set_verify(ups-ssl, ssl_mode, NULL); + SSL_CTX_set_verify(ups-ssl_ctx, ssl_mode, NULL); return 1; IMHO, as the secured socket is already instanciated, context modification is not propagated to the socket so the secured socket does not switch to verify mode. That is weird. I would also expect that the SSL_CTX_load_verify_locations() call would also be ineffective if that were the case, since that's dealing with the same Do I revert commit ? Well, since it doesn't seem to make a difference here, but it does on your side, I guess that is the most sensible thing to do. Due to the above I'm a bit worried though, that there is something else going on. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2809-branches/ssl-nss-port/server
Citeren emilien...@eaton.com: What about CERTPATH in upsmon.conf ? Don't touch that. This is indeed a path... :-) This is where the upsmon client looks for the CA that signed the certificate presented by the server. So unlike the server, this is indeed a directory that holds the trusted CA's (either 'official' ones, or your own CA in case of self-signed certificates). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2809 -branches/ssl-nss-port/server
Citeren emilien...@eaton.com: The main reason is to homogenize directive names between apps (mainly upsmon which uses CERTPATH and upsd which uses CERTNAME) to set the same property. Why? The use of CERTFILE (OpenSSL only) and CERTPATH/CERTIDENT/CERTREQUEST (NSS only) is completely different. We have nothing to gain by reducing the number of directives here, since we will need different instructions on how to fill them anyway. Using different names will help us help people much more easily, since the directives they see in upsd.conf will already tell us if NUT was build to use the OpenSSL or NSS libraries. Throughout NUT we should maintain a clear distinction whether a filename is needed (like CERTFILE) or a directory (STATEPATH, DATAPATH and CERTPATH). Note that the CERTFILE directive is working but is just flagged as deprecated. Whatever. As ssl support compilation is exclusive (only openssl or nss at the same time), I do not see any reason to keep two directives in parallel (one per compile profile) doing the same thing (pointing to the certificate database, in the form of a single file or a directory). These should be surrounded by #ifdef/#endif directives and make upsd complain loudly about directives it doesn't understand. So if someone is accidentally using CERTFILE if NUT was build with NSS, it should inform them right away (not when the certificate store is being accessed). Similar the other way around. About configuration directive, only CERTFILE/CERTPATH change of content (a directory instead of a file) but the semantic is kept unchanged. All other SSL related directives are just for NSS mode. So generate different .conf.sample files is IMHO disproportionate related to the too few alterations. Perhaps add few lines of comment in these .conf.sample files? You forget about the amount of problems we will see when people start switching over from OpenSSL to NSS. There is pretty much nothing to gain by consolidating these directives into one. What's wrong with # CERTFILE certificate file (OpenSSL only) # CERTFILE /usr/local/ups/etc/upsd.pem # CERTPATH certificate directory (NSS only) # CERTPATH /usr/local/ups/etc/cert/upsd # CERTIDENT certificate name database password (NSS only) # CERTIDENT my nut server MyPasSw0rD # CERTREQUEST certificate request level (NSS only) # CERTREQUEST [0|1|2] # - 0 to not request to clients to provide any certificate # - 1 to require to all clients a certificate # - 2 to require to all clients a valid certificate At best we would add some autoconf magic to only include the parts that are used (so that we don't clutter the configuration files with directives that are not used), but for the time being the above might be good enough. I'm one of the old dogs around here and even I already have problems setting this up (let alone the novice NUT users that try to make this work). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2809 -branches/ssl-nss-port/server
Citeren Arnaud Quette aquette@gmail.com: I would also add that documentation will also be in that way: UPGRADING will inform existing users to move to CERTPATH, and user documentation will note CERTFILE as deprecated in favor of CERTPATH. I couldn't disagree more. Using CERTPATH would hint users that they need to provide a driectory here (like STATEPATH, DATAPATH, ALTPIDPATH). We should really take care not to make the NSS configuration re-use directives from the OpenSSL configuration. Ordinary users may have no clue if the pre-build binaries they are using were build with the OpenSSL or the NSS library. The only hint they may ever see, is that the client/server complains about directives it doesn't understand. In my not so humble opinion, we really should consider surrounding the SSL related directives with #ifdef / #endif preprocessor directives. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2804 - in branches/ssl-nss-port: clients server
Citeren emilien...@eaton.com: - netssl.c provides some configuration function, one per directive, CERTREQUEST argument parsing is done in conf.c:parse_upsd_conf_args() and the dedicated nss configuration function is called with the corresponding value (IMHO best way because best decoupling between human readable configuration directive and functional storage) ? I see no benefit in using human readable directives over a numeric one here. We do the latter in many more locations and if chosen wisely, will offer more flexibility. So instead of checking for NO, REQUEST or REQUIRE, just call the levels 0, 1 and 2. It saves you from interpreting the string value in conf.c (what I really intended to say here, it should not validate input values). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] snmp-ups suicides on UPS unreachable
Citeren Turronix turro...@shiftmail.org: If snmp-ups is started when the UPS is not reachable (e.g. we have a slow switch that drops the first 30 seconds of communication at computer boot or interface startup) the snmp-ups suicides (or crashes?) and apparently there is nothing to re-launch it automatically so the connection to the UPS will never be established. This is by design, so it´s not a bug. The connection to your UPS is not nearly reliable enough to support reading status updates from it. You don't want to find this out when there is a real problem, so snmp-ups fails to start if it can't connect to the UPS after a couple of tries. It looks to me that you try to start the NUT service way to early during startup. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
[Nut-upsdev] iDowell subdriver added
I've just committed a rough version of the idowell-hid subdriver to the trunk. It is already integrated in the usbhid-ups, but I lack the time to complete the NUT to HID mapping in it. The following message on the nut-upsuser mailinglist should provide enough clues to add most of them: http://lists.alioth.debian.org/pipermail/nut-upsuser/2011-January/006506.html I would be grateful if another developer can pick this up. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Blazer upsdrv_shutdown function
Citeren Kjell Claesson kjell.claes...@epost.tidanet.se: Arjen can you enlighten me about the function of the blazer upsdrv_shutdown function. We first stop any pending shutdowns and then send it a shutdown with delay command. I think they are in the wrong order. What makes you think so? This has been like this for quite a while already. The megatec driver used the same order of commands (although it didn't test the return values) from the first version on. We've never seen any complaints about this. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] svn commit r2732
Citeren John Bayly freebsd.po...@tipstrade.net: I've discovered an issue (which may be unique to my UPS) with this commit. init_communication now returns -1, instead of 0 if it failed to read the manufacturer info, this makes sense after all. Not entirely. Previously, the init_communication() function would try to read BELKIN, but it would settle for a valid reply format (discarding the contents) after 10 retries. With my UPS (Belkin F6C1400-EUR), the response to the Manufacturer command returns only 6 spaces (rather than BELKIN), this means that init_communications fails, and the driver fails with EXIT_FAILURE Fixed in r2735. The driver seems to ignore the contents of this anyway. The value for 'ups.mfr' is even hard coded, which is already an indication that the original author wasn't sure that we should trust the value returned by the UPS. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2726 - in branches/windows_port: common drivers include
Citeren Arnaud Quette aquette@gmail.com: Date: Thu, 09 Dec 2010 14:01:14 + Subject: svn commit r2726 - in branches/windows_port: common drivers include Author: fbohe-guest Date: Thu Dec 9 14:01:07 2010 New Revision: 2726 URL: http://trac.networkupstools.org/projects/nut/changeset/2726 Log: More work on serial drivers. Still some TODOs to address but all drivers are compiling now. Successfully tested mge-shut driver. This patch seems to do away with the explicit canonical input processing some drivers require and overall there doesn't seem to be a difference anymore between canonical and non-canonical. I'm not sure if this will fly for all drivers. I foresee a challenging task to verify that drivers still work. I can probably test the 'safenet' driver, but what about the oldies that are still in the tree, but we have not heard of being used lately? Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] libusb usage
Citeren Michal Hlavinka mhlav...@redhat.com: I've been asked to find out some answers from libusb maintainer, so I'm forwarding them: - Why nut uses legacy libusb-0.1 api and not libusb 1.0 ? Well, mostly because at the time we started adding USB support to NUT, libusb-0.1 was all there is. - Is there any plan to update it to libusb 1.0? Eventually we will migrate to libusb-1.0, but there is no set date for doing so. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] APC nominal power patch
Citeren vasos noxe...@gmail.com: i just want to share a quick n dirty patch to support nominal power in APC ups's. I was not sure about the name of the nut key and put it to ups.power.nominal Thanks for your patch. The naming scheme of NUT can be found in 'docs/new-names.txt', where you'll find that the correct name for this would be 'ups.power'. Having said that, in case of extensions to usbhid-ups drivers we usually prefer to receive the output of the driver running debug mode (make sure to stop NUT before running the below command as root): /path/to/usbhid-ups -DD -a upsname APC_SmartUPS_RS_550.log 21 Let the above run for about 30 seconds and post the (gzip'ed) logfile here. We might be able to extract more useful information from it to even better support your UPS. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] AsciiDoc merge
For everybody wondering about the following warning message in all buildbots (except openSUSE): ../../server/ssl.c:134: warning: passing argument 1 of 'SSL_CTX_new' discards qualifiers from pointer target type This was changed between 0.9.8n and 1.0.0 [29 Mar 2010]: *) Let the TLSv1_method() etc. functions return a 'const' SSL_METHOD pointer and make the SSL_METHOD parameter in SSL_CTX_new, SSL_CTX_set_ssl_version and SSL_set_ssl_method 'const'. [Nils Larsch] Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [PATCH] upsd tcp_wrappers parsing and logging
Citeren Stephen Beahm stephenbe...@comcast.net: Parsing bug summary --- working /etc/hosts.allow: upsd127.0.0.1 [::1] : ALLOW broken in /etc/hosts.allow: upsdlocalhost : ALLOW It looks like upsd originally intended to match nut username with system username? No. We want to match the NUT username (as configured in upsd.users). The reason why has been discussed before on this list. This is not the case now. This is intentional. The change from RQ_CLIENT_ADDR to RQ_FILE will probably do away with some confusion for administrators setting this up, so I'll include that part of the patch. Whether or not we want additional logging, remains to be seen. It could help people setting up the server, but on the other hand might also lead to syslog flooding when logging failed attempts. At the moment I'm not convinced that we need more logging. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2708 - in branches/ssl-nss-port: clients m4 server
Citeren Arnaud Quette aquette@gmail.com: It also seems, after an update round on my side, that the standardization on nss pushed by Fedora and Suse has not yet made its way. I can't speak for Fedora, but on the latest released version of openSUSE, there is very little progress towards standardization on NSS. I have not found a single package that has been converted to use it. The only thing I could find was the mod_nss module (for Apache), but that's in the Mozilla beta repository (so not in the official builds). The nss_compat_ossl library from openSUSE 11.3 is also old, so I guess this has been put on the back burner... Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] udev versions (was Re: [Nut-upsuser] still no nut at reboot)
Citeren Charles Lepple clep...@gmail.com: Looks like Ubuntu changed to the udev which supports ATTRS sometime between 6.06 and 8.04 (2006 and 2008), but I haven't tracked down when the kernels changed over. If the system supports pkg-config, checking if the version is 098 should be able to tell if we must use SYSFS or can use ATTRS (which is supported for udev = 098). Since this change happened somewhere in 2006, I'm not sure if this is an issue anymore however, so it's probably safe to use ATTRS. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2669 - in branches/AsciiDoc: . m4
Citeren Charles Lepple clep...@gmail.com: Log: Add checking minimum required version for AsciiDoc tools I noticed that somewhere around this commit, the documentation stopped being built by default in BuildBot. Before I go digging too far, should I just add --with-doc=auto to the configure parameters, or should that eventually be included in the --with-all=auto settings? We already have '--with-doc=auto' on the configure commandline, so this isn't needed. Howevere, there seems to be a problem interpreting the versions returned by the AsciiDoc tools (from the r2672 Debian-etch build, similar for the other buildbots): checking for asciidoc... /usr/local/bin/asciidoc checking for asciiDoc version (8.6.3 minimum required)... asciidoc 8.6.3 found Here it works as expected. Even though the version string we're comparing against is 'asciidoc 8.6.3', the AX_COMPARE_VERSION macro seems to understand it should skip the initial non-numerals. checking for a2x... /usr/local/bin/a2x checking for a2x version (8.6.1 minimum required)... a2x 8.6.1 is too old Oops. The above causes the 'nut_have_asciidoc' variable to be set to 'no', which means that the prerequisites for building the documentation are not met and it will not be build regardless of any configure setting. checking for dblatex... /usr/bin/dblatex checking for dblatex version... dblatex version 0.2-2 found Here we only report the version (nothing more) so this isn't a problem. checking whether to build and install documentation... no And finally, the decision is made not to build the documentation. Most likely we'll need to strip the initial part of the return from the 'a2x 8.6.1' version string, since that will probably be treated as '2.8.6.1' now (it works when I lower the requirement to 1.0.0). I'll see what I can do... Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2669 - in branches/AsciiDoc: . m4
Citeren Arjen de Korte nut+de...@de-korte.org: Most likely we'll need to strip the initial part of the return from the 'a2x 8.6.1' version string, since that will probably be treated as '2.8.6.1' now (it works when I lower the requirement to 1.0.0). I'll see what I can do... Well, this indeed seems to be the problem looking at what happened after committing r2673. I've slightly improved this patch by stripping everything up to (and including) the last space in the version string. The documentation seems to build nicely now. The asciidoc (and related) tools on my system are too old and as a consequence, it doesn't build. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2669 - in branches/AsciiDoc: . m4
Citeren Arnaud Quette aquette@gmail.com: we could consider a slightly more complex approach where older asciidoc detection would only enable the single page html, and pdf version (if dblatex is also present). I'll see what I can do. I already noticed that at least some of the documentation will build with the (old) tools I have, so it might be interesting to do that. more recent version (once more, the not yet released 8.6.3) are only needed to build a proper chunked HTML... but I'm still unsure if it's worth. Why not? The clean version strings are available and with the AX_COMPARE_VERSION macro checking the version is easy enough. A transitional solution, to avoid the missing build deps, would be to also distribute asciidoc outputs, part of the nut tarball, or probably more as standalone archives. How big would they be? Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] segmentation fault in blazer_status().
Citeren Pawel Sikora pl...@agmk.net:
(gdb) up
#1 blazer_status (cmd=value optimized out) at blazer.c:214
(gdb) p val
$1 = 0x0
Excellent, I missed checking for a NULL pointer somewhere in the code.
Good catch!
199| for (i = 0, val = strtok_r(buf+1, , last);
status[i].var; i++, val = strtok_r(NULL, \r\n, last)) {
200|
201| if (!val) {
202| upsdebugx(2, %s: parsing failed, __func__);
203| return -1;
204| }
205|
206| if (strspn(val, 0123456789.) != strlen(val)) {
207| upsdebugx(2, %s: non numerical value
[%s], __func__, val);
208| continue;
209| }
210|
211| dstate_setinfo(status[i].var, status[i].fmt,
status[i].conv(val, NULL));
212| }
if (!val) {
upsdebugx(2, %s: parsing failed, __func__);
return -1;
}
213|
214+--- if (strspn(val, 01) != 8) {
215| upsdebugx(2, Invalid status [%s], val);
216| return -1;
217| }
except this rare segfauls the nut-2.4.3 package is great and works fine.
i can provide more debugging details if needed.
Most likely this won't be needed. It is pretty obvious from the trace
what is happening. The last chunk of data from the UPS (with the
status information) is lost and the strspn() function receives NULL
pointer indicating there is no more data). Try out the above
modification and let us know if this fixes the segfaults.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2658 - in branches/windows_port: common include server
Citeren Frederic BOHE fbohe-gu...@alioth.debian.org: +#ifdef WIN32 +intnoservice_flag = 0; +HANDLEsvc_stop = NULL; +SERVICE_STATUSSvcStatus; +SERVICE_STATUS_HANDLESvcStatusHandle; +#endif As far as I can tell, the SvcStatus and SvcStatusHanle variables are only used in conjunction within this module. In that case, consider not to export them in common.h and declare them static in common.c. This keeps the interface clean and will also prevent other modules messing with them behind your back. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Problem with starting nut
Citeren Vladimir Micovic vladi...@micovic.com: And sorry, I forgot to put log from messages, I always got this: Oct 30 21:06:25 optimus kernel: usb 5-1: usbfs: process 9808 (megatec_usb) did not claim interface 0 before use Most likely this is a problem with a broken udev setup. Try if adding user = root to the global options in ups.conf (and restarting NUT) helps. If so, the error is in the NUT package you installed and you'll need to file a bugreport with whoever packaged this. This is not a NUT problem, so we can't help you with that. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2620 - trunk/drivers
Citeren Arnaud Quette aquette@gmail.com: since we're using svn logs to generate the ChangeLog, I went on the server to modify this empty log msg with Fix compilation warnings. Yeah, I forgot to add a description here. Sorry about that... You may have noticed I'm in the process of fixing all compilation warnings I see on the openSUSE buildbot (which are quite a few). Most of the 'easy' ones are now fixed, the majority of the remaining ones require more attention. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2610 - branches/silent_build
Citeren Arnaud Quette aque...@alioth.debian.org: Log: Optionaly enable silent build rules, using AM_SILENT_RULES, only if it's supported (requires automake 1.11) Why do we need a new branch for this? As far as I can see, only the below lines are really needed +dnl Currently, we only (force) enable silent rules if available +dnl Verbose mode can be turned on using --disable-silent-rules +m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) Since the above first checks if this is available and then enables it, I don't see where this might lead to portability concerns. Even it if does, we already provide an option to disable this. So instead of creating a new branch, it probably requires just a few lines in the UPGRADING file (or equivalent) to mention the changed behavior and what can be done if it breaks compilation. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2610 - branches/silent_build
Citeren Charles Lepple clep...@gmail.com: We might want to keep the silent option off for Buildbot compilation because it hides a lot of the flags - that might make it harder to figure out things like the overlinking problem. I certainly wouldn't want to run the Buildbot compilation with silent build enabled. I'm also uncertain which audience we try to reach with this. Do packagers really complain about the build process being too verbose? In case of problems, more output is usually better than virtually no output. And if you really feel lucky, there is always the option of sending all warning messages and/or debug output to /dev/null. What is the whole point of this? Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] ORVALDI 650/750/900SP.
Citeren Paweł Sikora pl...@agmk.net: 1). connect usb cable to ups. /* on fresh 2.6.36 kernel from git */ Oct 25 20:00:09 localhost kernel: [33773.726642] usb 7-2: new low speed USB device using uhci_hcd and address 3 Oct 25 20:00:09 localhost kernel: [33773.922008] usb 7-2: New USB device found, idVendor=0665, idProduct=5161 This VID:PID combination *might* be supported by either the blazer_usb or (obsolete) megatec_usb driver. Besides trying, there is no way to conclusively tell. 2). add [orvaldi] entry to /etc/ups/ups.conf: [orvaldi] driver = megatec_usb port = /dev/input/by-id/usb-0665_WayTech_USB-RS232_Interface__V1.0__Baud_rate_2400bps-event-if00 this is a udev-maintained symlink to proper /dev/input/eventX. The value of 'port' will be ignored for USB connected drivers. Please read the man pages before posting here (we'll give people some slack on nut-upsusers, but on the nut-upsdev list not reading the documentation and/or the archives is a grievous mistake... :-) 3). test the driver: # /lib/nut/upsdrvctl -u root -D start orvaldi Same here, shame on you! ;-) The upsdrvctl wrapper doesn't pass on the -D parameter to the drivers it starts (read the archives for an explanation why), so in order to run a driver in debug mode, you must start it directly /path/to/driver -DDD -u root -a upsname First thing for you to try is if the blazer_usb driver is able to communicate with your UPS. Make sure to kill *all* NUT drivers that may be running in the background before running a driver in debug mode. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2588 - branches/windows_port/common
Citeren Frederic BOHE fbohe-gu...@alioth.debian.org: Author: fbohe-guest Date: Wed Oct 20 09:13:38 2010 New Revision: 2588 URL: http://trac.networkupstools.org/projects/nut/changeset/2588 Log: Remove hack from confpath function. You have to declare a NUT_CONFPATH environnement variable in your Windows settings This is not the intended use, it is only meant for people that wish to override the build-in default value. Provide ./configure with the path where the config files will be stored and most people will never have to touch this. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] cross-compiling the windows_port branch (socklen_t)
Citeren Frédéric Bohé fredericb...@eaton.com: Indeed, the current configure.in has a number of issues. They are related to : - libusb detection - libneon detection - linking to regex - duplication of DATADIR macro - definition of socklen_t - inet_aton detection Regarding inet_aton, this used in conjunction with the gethostbyaddr function that is now marked 'obsolete' by POSIX. We should really consider removing this old cruft from the tree, since all systems nowadays support getaddrinfo. Something similar goes for socklen_t. We should trust on sys/socket.h to provide the necessary type. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2594 - branches/bcmxcp/drivers
Citeren Chetan Agarwal chetanagarwal-gu...@alioth.debian.org: + sPartNumber[16] = 0; This is redundant. The snprintf function will take care of properly terminating the string with a '\0' character, you don't need to do that yourself. + snprintf(sPartNumber, 16, %s, answer + BCMXCP_CONFIG_BLOCK_PART_NUMBER); Don't hardcode '16' here, use 'sizeof(sPartNumber)' instead. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] cross-compiling the windows_port branch (socklen_t)
Citeren Tim Rice t...@multitalents.net: There is at least one currently shipping UNIX platform where socklen_t is not defined. Please keep the NUT_TYPE_SOCKLEN_T test. Which one? Is this system POSIX compliant (and do we fail to provide the proper flags to make it behave like one?) Nut's m4/nut_type_socklen_t.m4 could be enhanced with the recent changes to gnulib's m4/socklen.m4 I'm not sure this is a good idea. We require POSIX compliance and as far as I know, socklen_t should be defined. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r2578 - in branches/windows_port: clients common drivers include server
Frederic, Instead of adding '/c/MinGW/lib/libws2_32.a' to Makefile.am, I think it would be better to add this to the system wide LDFLAGS (or LIBS). Otherwise these changes will break compilation on non-Windows systems. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Is in in process driver for AIPTEK UPS PowerWalker VI 2000 LCD USB
Citeren Dimitar Angelov mi...@edabg.com: Are there in progress development of NUT driver that supports AIPTEK PowerWalker VI 2000 LCD - Art-No 310064 (http://www.powerwalker.com/line-interactive.html)? I don't know, as far as I know we have no specific Aiptek and/or PowerWalker projects underway. So unless it is already supported by one of the existing drivers, the answer is probably 'no'. Please provide some more information on the interface being used (serial, USB). If USB is used, post the output of 'lsusb -vvv' (run as root). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] sweex UPS 1500VA
Please subscribe to the mailinglist to prevent the moderators from having to approve each and every message you post. And don't top post. Citeren Adam Sádovský sadov...@234.cz: I have tried blazer_usb without success. But thank you anyway. Did you run it in debug mode as well? Having said that, chances are it uses an entirely different protocol. It could even be a new implementation of what the richcomm_usb driver uses, so I think you'd need to snoop the USB communication with the supplied Windows driver to find out if it is anything familiar. Search the mailinglist for ideas on how to do this. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] You lost support of Belkin Universal UPS F6C1100-UNV
Citeren Cadence cade...@rogers.com: # /lib/nut/megatec_usb -D -a belkin Network UPS Tools - Megatec protocol driver 1.6 (2.4.3) Serial-over-USB transport layer 0.10 0.00 debug level is '1' 32.427474 Starting UPS detection process... 75.263380 ser_get_line: Device detached? (error -1: error sending control message: Operation not permitted) 75.646279 Successfully reconnected 118.177387 ser_get_line: Device detached? (error -1: error sending control message: Operation not permitted) 118.562286 Successfully reconnected 161.087388 ser_get_line: Device detached? (error -1: error sending control message: Operation not permitted) 161.470290 Successfully reconnected 161.470319 Megatec protocol UPS not detected. The above is a permissions problem. Most likely you're running two instances of the driver in parallel. Make sure to kill off any drivers you've been running before starting a new one. Also note that we no longer recommend to use the megatec_usb driver. It has been replaced by the blazer_usb driver and will probably be dropped from the tree when we release the next version. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Cannot connect to APC Smart via USB under FreeBSD
Citeren Ilya Evseev ilya.evs...@gmail.com: There is FreeBSD 7.1, NUT 2.4.1, UPS APC Smart 2200 XL. [...] Any ideas? Maybe this tread provides an answer: http://lists.alioth.debian.org/pipermail/nut-upsuser/2010-September/006220.html Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Cannot connect to APC Smart via USB under FreeBSD
Citeren Daniel O'Connor docon...@gsoft.com.au: There is FreeBSD 7.1, NUT 2.4.1, UPS APC Smart 2200 XL. I haven't had much with USB UPS comms on FreeBSD before version 8. I thought there was a 'pollonly' option which I used and that helped but I can't see it in the docs now. This flag was added to the stable version in nut-2.4.2. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Dynamix 650 VA USB - broken, have rough fix
Citeren Brian R. Smith bsm...@furbium.com: Should megatec_usb.c/set_data_krauler just skip the usb subdriver function table and go straight for usb_get_string? Or should the usb subdriver be extended with a call that doesn't go through usb_get_string_simple? The 'megatec_usb' driver is no longer maintained and has been replaced by the 'blazer_usb' driver. This uses direct calls to the libusb library, so the fix you recommend should be much easier to implement. Please post some debug output before and after making these changes by running the driver with -DDD enabled (not more). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Default format for HID debugging (was Re: [Nut-upsuser] Liebert PSP)
Citeren Charles Lepple clep...@gmail.com: Any objections to changing the default format string in these debug messages from %f to %g? I know it's nice to have a constant-width output format, but the Type string is variable-length, and in this case, we had a value hiding just outside the precision of the printf output. No objections. We just might want to double check if this also requires changes to 'path-to-subdriver.sh' (but I don't think this is needed). Other than that, there should be no compatibility issues. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] HP T1500 INTL
Citeren James Harper james.har...@bendigoit.com.au:
I have a HP T1500 INTL that isn't picked up under 2.4.3. I added the USB
device ID to tripplite-hid.c like:
/* HP T1500 INTL */
{ USB_DEVICE(HP_VENDORID, 0x1f09), battery_scale_1dot0 },
and it seems to work just fine:
[...]
please consider including it in future versions.
Thanks for reporting this. I have added this device in the development
version. Note that the udev rules will be regenerated automatically if
you run 'make dist'.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] usbhid-ups causing hang on boot with 2.6.35 - any ideas?
Citeren David C. Rankin drankina...@suddenlinkmail.com: (Arjen - I apologize if you get two copies, I sent the first one to the old de-korte.org address) That address isn't old, but the mailserver is configured to only accept messages from the mailinglist server. Aug 30 20:31:03 archangel upsd[2295]: listening on 192.168.6.14 port 3493 Aug 30 20:31:03 archangel upsd[2295]: listening on 127.0.0.1 port 3493 Aug 30 20:31:03 archangel upsd[2295]: Can't connect to UPS [archangel_ups] (usbhid-ups-archangel_ups): No such file or directory This means the driver isn't running (but you probably already knew that). Aug 30 20:31:03 archangel upsd[2296]: Startup successful Aug 30 20:31:03 archangel upsmon[2298]: Startup successful Aug 30 20:31:03 archangel upsmon[2300]: Login on UPS [archangel_...@localhost] failed - got [ERR ACCESS-DENIED] Aug 30 20:31:03 archangel upsmon[2300]: Login on UPS [nirvana_...@nirvana.3111skyline.com] failed - got [ERR ACCESS-DENIED] The above two error messages indicate there is a problem with logging into the server. You could run the server in debug mode, but my guess is this has to do with either NUT being build with tcp-wrappers support and you failed setting this up properly (see 'man 8 upsd') or the credentials you're using are incorrect. [...] Looks like some type of udev issue or kernel issue, but I thought I would check here to see if you guys have any more info on the problem. Anybody seen this behavior before? This looks like the udev rules are incorrect. If memory serves, there have been some changes in the syntax (BUS was changed to SUBSYSTEMS). Other than that, there are no known issues. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [Nut-upsuser] APC Smart-UPS X 1500 Restart Issue.
Citeren Jain, Arvind aj...@dataram.com: This sleeps until AC power returns. When battery runs out, system stop and reboots when power is back. First of all, it is a terribly bad idea to run a driver in debug mode on a production system. It should be used for testing purposes only. The problem is caused by the driver failing to detect a working 'load.on.delay' command for the UPS, which is needed to create the two-step 'shutdown.return' command. Either your UPS doesn't have one, or it is put in a vendor specific HID path. Because of this, the driver will fallback to the 'shutdown.reboot' command, which seems to be horribly broken for your UPS. It would be helpful if you could post the output of /sbin/usbhid-ups -DD -a scups 21 here, so that we can see if there might be another HID path that could be used. Chances are, that we just need to call 'load.off.delay' and that the device will return power all by itself. This violates the HID Power Device Specification, but since the 'shutdown.reboot' also is non-compliant, I'm not too surprised. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com: I fixed my shutdown function: Why you just don't look into other drivers how to use the upslog* and upsdebug* functions, is beyond me... :-( [...] I ran a test and doesnt exist the /tmp/liebert-esp2_debug.log file so I think shutdown function not called but I don't know why any idea ? Read 'man 8 nutupsdrv' to see if this gives you a hint when the upsdrv_shutdown function is called. Other than that, you're not providing an awful lot of information. Again. We can't help you, if you don't meticulously describe what actions you performed and what the intended and actual results where. We're not magicians... Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com: I ran /usr/local/ups/bin/upsdrvctl start and driver didnt start I gave this error: ESP-II capable UPS not detected Most likely, the driver is still running in the background. Make sure you stop all drivers before starting (even in debug mode). Search the archives. second, I ran /usr/local/ups/bin/upsdrvctl start and ups shutdown itself and I dont know why? I don't have a clue if you don't provide more information. What version of the driver are you running? Which modifications did you make? In the past it has been running as far as I know, so if it no longer does, you probably broke it. I know that I need run the driver like this : /path/to/liebert-esp2 -DD -a liebert-esp2 but If I use this liebert-esp -DD -a liebert-esp logfile - it doesnt work You also need to redirect the stderr output. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com: I use nut rev2462 and I put shutdown commands in end of upsdrv_updateinfo before these calls status_commit(); dstate_dataok(); Well, in that case you've proven that the shutdown commands are working. The upsdrv_updateinfo() is called every pollinterval seconds (typically 2), so this will pretty much instantly kill the UPS when you start the driver. If you want to do something useful with this command, they should go into upsdrv_shutdown() and/or instcmd(). I test manual shutdown commands , If I run upsc liebert-e...@localhostcommand then call upsdrv_updateinfo if I think it right ? Not at all. Please do read the developer documentation (all of it) before making a fool of yourself. Most of this is documented in docs/new-drivers.txt, so I strongly suggest you start reading there (but please read *all* documentation before asking for help). It also helps looking at other drivers to see how they deal with shutdown commands. I'm really getting quite annoyed by your ignorance to try to figure out this yourself. I have much better things to do than explain what is already documented. This is the all modify in this driver. It helps attaching a diff. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com:
This is my shutdown function:
void upsdrv_shutdown(void)
{
int ret;
fprintf(stderr,SHUTDOWN 1);
This doesn't work. The driver backgrounds before it reaches this
point, so you can't use fprintf at this point anymore.
ret = ser_send_buf(upsfd, cmd_UPSShutdown0, SHUTDOWN_CMD_LEN);
if (ret 0) {
upsdebug_with_errno(2, send);
return -1;
}
else if (ret 6) {
upsdebug_hex(2, send: truncated, cmd_UPSShutdown0, ret);
return -1;
}
A void function can't return a value. Does the above actually compile
without errors? If it does, change the compiler flags so that it
doesn't. Also make sure that you're running your freshly compiled
driver.
[...]
These commands works other way , but in this function didnt work
And I cant found the SHUTDOWN 1,2,3 test texts in debug.log, so I think
dont sent these commands to UPS.
See above.
Best regards, Arjen
--
Please keep list traffic on the list
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com: How can I log my driver in debug mode? Please be specific in your questions. If you want to know how to log debug messages in a driver, use the upsdebug_* functions (examples are in the driver already). If you want to know how to run a driver in debug mode, try running it with -h on the command line and/or read 'man 8 nutupsdrv'. Because I work on it liebert-esp2 driver shutdown function and if I put the commands in updateinfo funciton and call it manual that it works fine. I have no idea what you mean to write here. Please be a little more specific (what did you change, which commands did you execute and what was the result). Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] problem with restarting nut
Citeren Michal Hlavinka mhlav...@redhat.com: Hi, one user found problem with restarting nut. upsdrvctl does not wait for drivers being really terminated. In init scripts we have following: killproc upsmon killproc upsd upsdrvctl stop and then upsdrvctl start upsd upsmon problem is upsdrvctl stop only sends terminating signals but does not wait for driver termination. This is by design. If the battery is low, we don't want to hang around waiting for a driver that fails to respond immediately. Instead, the system should proceed shutting down immediately (to deal with systems where stop scripts are not run concurrently). This makes driver fail to start sometimes when old driver is still running because device is locked by another process. Known issue, which has been discussed several times in the past as well. The solution is also well known. If you put a 'sleep 2' between stopping and starting of upsdrvctl, all sane drivers will have had plenty of time to notice this. If you find one that doesn't, please let us know (and we can fix it). I've prepared patch cloning stop_driver function to wait_driver_stoped which blocks until timeout or until /proc/pid disappears. This function is called after send_all_drivers(stop_driver). See attached patch. Patch is missing, but I very much doubt we would take the risk to do this anyway. I don't think we want to risk a longer delay at a time where the battery is critical, versus a minor inconvenience when restarting NUT (which can be fixed with a small delay). If you don't want to make this changes I can modify init script restart function instead to wait until all processes with pid in /var/run/nut/*.pid files are dead, but I find this quite ugly. It's not needed. Any driver that fails to respond to a signal to stop within two seconds, is not listening anymore. So if after waiting for two seconds the driver has not stopped, it never will. I doubt that adding a two second delay in a restart script is noticeable. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [PATCH] nut crashes when port= is omitted
Citeren Michal Hlavinka mhlav...@redhat.com: How to reproduce this crash: 1)add ups to ups.conf, omit port configuration 2)run upsdrvctl stop There is nothing checking ups configuration is ok for upsdrvctl. For daemon there is check in server/conf.c upsconf_add. I've moved that checking code to separate function upsconf.c : validate_upsconf and used this function from upsconf_add and from upsdrvctl.c , this was more intrusive than it seemed. See attached patch (tested). Simpler way would be just adding validate_upsconf to upsdrvctl.c but it'd lead to code duplication. Any comments? Thanks for your patch. This part of the code if used for stopping legacy drivers (up to and including nut-2.0.4), which are by now more than four years old. Newer drivers (nut-2.0.5 and later) use a different naming scheme for the driver sockets (and PID file) and the value of 'port' is no longer used anymore for those. Instead of validating the value of 'port', it is sufficient to check for NULL if the PID file is not in the nut-2.0.5 location. This also allows us to skip the 'port' variable where this is not needed (for instance the usbhid-ups driver). A revised version is now available in the SVN trunk. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com: How can I send hexa commands to UPS with nut ? Through the ser_* functions that are used by serial drivers. See 'docs/new-drivers.txt'. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com: first: What's wrong with this: dstate_setinfo(battery.runtime.low,%d,3500); it doesnt work. If you put this in the right location, this will work. But without context, I can't tell if you did. Also remember that the dstate_setinfo() function is only for setting variables in the driver that are read by the upsd server. It won't magically update these values in the UPS. That should be done in the setvar / instcmd functions (that are currently empty in this driver) and which implement a UPS specific method to change settings or initiate a command respectively. Please read *all* the developer documentation before asking for help or start hacking in the sources. second: If I figure out how can I shutdown PC and UPS that ups shutdown too and if I plug back the power PC start automatic. I put this command in upsdrv_shutdown, is it right? Maybe. Or I need put it in other function? It depends on when you need to send this command. As far as I can tell the UPS will now shutdown automatically when the power fails. Since we don't have a functional upsdrv_shutdown() function, I guess that we should tell the UPS not to do this *before* a power failure hits us. In that case, the command should be in upsdrv_initinfo(). However, if you need to send it right before the UPS should be brought down, it should be in upsdrv_shutdown(). I can't tell, I have no idea how this works on your UPS. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com: I put dstate_setinfo(battery.runtime.low,%d,3500); in the upsdrv_initinfo function. This will hardcode the 'battery.runtime.low' value that is reported to the upsd server and upsmon clients. I doubt that this is what you meant to do. I tought battery.runtime.low tell to NUT when send LOW BATTERY EVENT and after this will be happend - generates a NOTIFY_SHUTDOWN event - waits FINALDELAY seconds - typically 5 - creates the POWERDOWNFLAG file - usually /etc/killpower - calls the SHUTDOWNCMD No. The dstate_setinfo() and dstate_getinfo() functions are only used to change or read back the values that are reported to the uspd server. The upsmon client will only look at the 'ups.status' that is reported. If you want to shutdown based on the runtime remaining, your UPS must support both shutting down based on remaining runtime *and* allow you to override the build in value. You should never need to directly set 'battery.runtime.low', since this must be the actual value reported by the UPS. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com: I tried this : [r...@ibolya ~]# upscmd -l liebertg...@localhost Instant commands supported on UPS [liebertgxt2]: The command list is empty. Why? I already wrote that in previous messages in this thread. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com:
I know it,but I tried my ups On Battery with Liebert java app and when java
app shutdown PC and after shutdown UPS.
Later I plugin back the power and UPS started and after PC started automatic
too.
And I think NUT know it just I need configure NUT.
I read this instcmd :
shutdown.return | Turn off the load possibly after a delay|
| | and return when power is back
but I didn't can use it.
And if I can send other shutdown command to UPS from this NUT function :
void upsdrv_shutdown(void)
{
/* replace with a proper shutdown function */
fatalx(EXIT_FAILURE, shutdown not supported);
}
???
Is it help for me ?
When people write to the development mailing list, we expect them to
read the full thread:
http://lists.alioth.debian.org/pipermail/nut-upsdev/2010-July/004875.html
Best regards, Arjen
--
Please keep list traffic on the list
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Farkas Levente lfar...@lfarkas.org: the truth is that we don't know what's happened. we only recognize if nut is running and we just unplug the power from the ups the computer shutdown and after 2 minutes the ups turn off itself. while if we run liebert's java ups manager service and java gui the same thing is not happened. The java GUI probably switches the UPS from 'autonomous mode' (where it decides to switch off the power itself) to the 'monitored mode' (where the decision is made by an external program, like the java GUI). This is not uncommon. The trick is to find out how to tell the UPS that it is being monitored. It could be the java GUI sends an initialization command upon startup, or a command to keep running on battery when it finds the mains has failed. Assuming that Liebert isn't willing to tell us how this works, the only way to find out what to do is to listen in to the communication between java GUI and the UPS and mimic the same behavior. None of the active developers currently owns such a UPS, so if this is important to you, you'll have to provide us with this information. Using a serial port sniffer on a native serial port is probably the easiest way to go (like 'Portmon for Windows'). I don't recommend to use a USB to serial converter with 'usbsnoop' here, since that will mean that you'll have to decode both the USB to serial conversion *and* the serial communication between the java GUI and the UPS. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Robert Jobbagy jobbagy.rob...@gmail.com: I checked out the HEAD rev and tried the liebert driver. it gave wrong model,firmware,serial, mfr date value. caused by len variable in line 97 and after If you provide the debug output, this will save us looking up the last time you posted the results. I use my ups with usb - serial converter. Which one? these patches attached Did you try the liebert-esp2 driver in ON Battery mode ? I don't have one, so I can't tell. Because If I switch my ups on battery (plugged off the input) then liebert driver force shutdown PC and shutdown UPS. In it's present state, the liebert-esp2 driver can't shutdown the UPS. Battery is full charged. UPS doesnt recieve LOW BATTERY EVENT. How old are the batteries? When was the last time you ran a battery test? This sounds more like a bad battery than a driver problem. Worn out batteries are a common cause of mishaps like these, where the batteries seem to be fine when not loaded (mains present), but fail under load (mains failure) within seconds. the shutdown function is missing from liebert-esp2 driver, this is the reason the force shutdown ? The driver won't be able to shutdown the UPS if the upsdrv_shutdown function is not functional. If the UPS kills the output, it is not caused by NUT but most likely by the battery protection. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Liebert ESP II driver
Citeren Farkas Levente lfar...@lfarkas.org: I use my ups with usb - serial converter. Which one? anyone. since the usb-serial converters use in this way. and with this patch both the serial and the usb-serial connection works. Still we want to know which USB to serial converter was used. We regularly get questions which USB to serial converter to use. I know that *some* will not work with *some* drivers (usually because the added latency is more than the driver author anticipated years ago). However, if we know which ones *do* work with a certain driver, that's useful information. [...] in it's present state the liebert ups has an internal settings. and it's by default (ie. if nut's liebert-esp2 driver do not set it otherwise) if the ups plugged off the input then it _immediately_ send a LOW BATTERY EVENT. How does one change this setting? So far, we don't have instcmd's for this driver, simply because we don't know what to tell the UPS to change settings. But if you know how to change settings on the UPS, I'm all ears. in response to this nut shutdown the host computer and after 120 second turn off the liebert ups itself. Is this a fixed time interval after power failure, or is this a triggered by the UPS detecting that the load has switched off (aka battery saving mode)? so in the present state if nut with liebert-esp2 running on any computer with liebert ups even if the battery if fully charged the host will shutdown immediately. Not necessarily. You always have the option of increasing FINALDELAY a bit. Of course the system *will* go down on every power failure, but at least it will give you a little more runtime. for me it means currently nut's liebert-esp2 worse then liebert without nut. Until you're hit by a power failure when you're not around to shutdown your system(s) in time. In my opinion, a system that solely relies on a UPS to provide power in case the mains fails (ie, without a generator that kicks in after a few seconds) but doesn't monitor it, is only marginally better than not having a UPS at all. It will give people a false sense of security. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Status
Citeren Kiss Gabor (Bitman) ki...@ssg.ki.iif.hu: I wonder if ups.status: OB LB OFF is valid? Valid. Or OB and OFF are mutually exclusive flags? No. OL/OB - input status LB- battery status OFF - output status So the above is a perfectly legitimate status. See also 'docs/new-drivers.txt'. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Threads
Citeren Kiss Gabor (Bitman) ki...@ssg.ki.iif.hu: if you really want to split the acquisition load, use 4 real drivers, and then acquire data from the local sockets. Somehow like the clone driver do. Yes, exactly. This is the case when multithread simplifies programming model. Each thread could receive async data and issuing PING commands independently. The upsd server can do the same, yet only uses a single thread. I still don't see the benefit of multi threading. I'm interested in how you intend to consolidate the different values from the four UPSes you have without losing information. If one UPS loses input power, what would the value for 'input.voltage' of your meta-UPS be? If you want to help your system administrators setting up NUT easily, why not provide them with a centralized 'upsmon.conf' file? If you're using parallel redundant UPSes, it should be trivial to let upsmon monitor all of them and start shutting down when the POWERVALUE is too low. There is an undocumented '-f' flag that will allow specifying a different location for the 'upsmon.conf' file. Best regards, Arjen PS Be aware that in a properly setup parallel redundant NUT configuration, it is irrelevant which driver you monitor. The master upsmon processes will set the FSD flag on all drivers once there is insufficient POWERVALUE remaining. -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Supporting APC 5G UPSs
Citeren chris.coll...@apcc.com: I'd like to submit a patch to enable NUT to communicate with APC 5G UPSs. The current usbhid-ups driver recognises APC UPSs by the Vendor ID and Product ID of 0x051D and 0x0002. This needs to be amended with the new Product ID of 0x0003. (See attached file: apc-hid.patch) Thanks for the patch. Secondly, when Nut polls the UPS via the interrupt channel, these will time out, resulting in frequent lost comms. The USB Interrupt channel is being reserved in 5G UPSs for a proprietary protocol. In order to enable Nut to communicate with the UPS, a poll only configuration is required. The details of my ups.conf file are as follows: [apc] driver = usbhid-ups port = auto pollonly = 1 The 'pollonly' is a flag, so just listing 'pollonly' here would be enough (the '= 1' part is not used). Assuming this is important for this device, we should probably automatically disable the interrupt pipe, so this is what the revised patch will do upon detecting a 5G UPS. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
