Re: [Nut-upsuser] New NUT user with HP R3000XR problem
Citeren Brother Railgun of Reason : Oops, looking at the code I saw this isn't a warning, but a (fatal) error instead (this was not one of the most descriptive error messages I ever wrote). I now recall that this value is OS dependent, so you probably want/need to limit this in upsd.conf through the MAXCONN parameter (which in your case seems to be mandatory). Ah, ... yeah, that would have been better than patching the code, wouldn't it? *sheepish* I missed that parameter. I'll undo my patch and try using the maxconn param instead. As just mentioned, my studies appear to indicate that this is a tunable kernel parameter which, on Solaris, defaults out-of-the-box to 256. It is. I'm not quite sure what would be the better thing to do in case the (default) MAXCONN value is too high: 1) Bail out with a more descriptive error message 2) Adjust the number of connections to the maximum allowed (with message to syslog) I think it would be much more user friendly to do the latter, but opinions on this are welcomed. Given that this varies by OS *but* may be tunable, my inclination would be to adjust the connections to the max available if less than MAXCONN, emit a warning in syslog and on the console, and document in the sample upsd.conf that depending on OS this MAY be a tunable parameter. I think the safest we can do is, by default use the maximum number available (instead of fixing this to 1024). People would still be able to lower this value should they wish to (in order not to waste resources if this happens to be a very high value). But we *must* bail out (with a more descriptive error message) if people deliberately request a number higher than the system allows. You'll run into problems (and this may not be immediately after startup) if you exceed the maximum number of connections, so this must be fixed. The only way to guarantee this happens, is to refuse to start. [...] Ah, so the behavior is as *intended*, but the documentation has gotten out of step with the intent. I see. If this change was made for security reasons, perhaps this goal might be aided by adding a netblock ALLOW or ACCEPT directive? For example, with two subnets, I might specify: LISTEN 127.0.0.1 3493 ACCEPT 127.0.0.0/8 LISTEN 10.24.32.14 3493 ACCEPT 10.24.32.0/24 ACCEPT 10.24.33.0/24 upsd could simply refuse connections from outside the netblocks it had been told to ACCEPT, without doing any further authentication. For IP based access control, you'd better use a firewall which can do this much more efficiently than we ever can. We actually *removed* this and now use tcp_wrappers only for IP based *user* level access control. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
On Wed, May 27, 2009 at 11:51:44PM +0200, Arjen de Korte wrote: > Citeren Brother Railgun of Reason : > babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] >>> Weird, apparently your system has a limited number of file descriptors >>> available. I have a feeling that this is not a standard operating system. >> I was a little puzzled by that myself. It's Solaris 10 x86 running on a >> pretty substantial box, it shouldn't be an OS limitation. > > Oops, looking at the code I saw this isn't a warning, but a (fatal) error > instead (this was not one of the most descriptive error messages I ever > wrote). I now recall that this value is OS dependent, so you probably > want/need to limit this in upsd.conf through the MAXCONN parameter (which > in your case seems to be mandatory). Ah, ... yeah, that would have been better than patching the code, wouldn't it? *sheepish* I missed that parameter. I'll undo my patch and try using the maxconn param instead. As just mentioned, my studies appear to indicate that this is a tunable kernel parameter which, on Solaris, defaults out-of-the-box to 256. > I'm not quite sure what would be the better thing to do in case the > (default) MAXCONN value is too high: > > 1) Bail out with a more descriptive error message > 2) Adjust the number of connections to the maximum allowed (with message to > syslog) > > I think it would be much more user friendly to do the latter, but opinions > on this are welcomed. Given that this varies by OS *but* may be tunable, my inclination would be to adjust the connections to the max available if less than MAXCONN, emit a warning in syslog and on the console, and document in the sample upsd.conf that depending on OS this MAY be a tunable parameter. >> BTW, upsd.conf is default with everything commented out, which should >> result in listening on everything: >> >> # This defaults to the global IPv4 listening address and port 3493. You >> # may specify each interface you want upsd to listen on for connections, >> # optionally with a port number. > > We need to change this. This used to be the case in older versions, but we > now default to a (safer) localhost only. Ah, so the behavior is as *intended*, but the documentation has gotten out of step with the intent. I see. If this change was made for security reasons, perhaps this goal might be aided by adding a netblock ALLOW or ACCEPT directive? For example, with two subnets, I might specify: LISTEN 127.0.0.1 3493 ACCEPT 127.0.0.0/8 LISTEN 10.24.32.14 3493 ACCEPT 10.24.32.0/24 ACCEPT 10.24.33.0/24 upsd could simply refuse connections from outside the netblocks it had been told to ACCEPT, without doing any further authentication. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
On Wed, May 27, 2009 at 05:10:07PM -0400, Brother Railgun of Reason wrote: > and then telnetting to port 3493, still from localhost, and I still > couldn't connect to port 3493. So, being a nasty suspicious sort, I > checked lsof ... nothing's got port 3493 open. checked the process > table ... upsd isn't running. It appears to start up, then immediately > die. > > Could this be because something is limiting it to 256 connections? > (Not that I'm ever going to need even a tenth of that 16 > connections would be more than I'm ever going to need to use.) > > I'm wondering whether I should go tweak the source to request only 256 > connections (or even 128) and see if upsd still dies on startup. Indeed, I checked the code, and inability to get the requested number of connections is a fatal error. Investigating this, I've discovered that when upsd checks how many connections it may have, it's actually checking _SC_OPEN_MAX, which is the number of files it's allowed to have open, and which appears to be governed by rlim_fd_cur. On Solaris 10, out of the box, rlim_fd_cur defaults to 256. I'll reset this to 2048 in /etc/system on my next reboot, but in the meantime I've patched upsd.c to set maxconn to 128, since I'm never going to need even 256 connections to upsd. Now: babylon4:root:/opt/nut:10 # upsd Network UPS Tools upsd 2.4.1 listening on 10.24.32.14 port 3493 listening on 127.0.0.1 port 3493 Connected to UPS [tokamak]: bcmxcp-tokamak babylon4:root:/opt/nut:11 # upsc toka...@localhost ups.status OL babylon4:root:/opt/nut:12 # upsc toka...@localhost ambient.temperature: 23.8 ambient.temperature.high: 55 battery.charge: 33.1 battery.runtime: 442 battery.voltage: 129.2 driver.name: bcmxcp driver.parameter.baud_rate: 19200 driver.parameter.pollinterval: 2 driver.parameter.port: /dev/tty00 driver.version: 2.4.1 driver.version.internal: 0.21 input.current: 11.2 input.frequency: 60.0 input.frequency.high: 65 input.frequency.low: 55 input.frequency.nominal: 60 input.transfer.boost.high: 12 input.voltage: 119.8 input.voltage.nominal: 120 outlet.1.delay.shutdown: -1 outlet.1.delay.start: 1 outlet.1.id: 1 outlet.1.status: On outlet.2.delay.shutdown: -1 outlet.2.delay.start: 2 outlet.2.id: 2 outlet.2.status: On outlet.3.delay.shutdown: -1 outlet.3.delay.start: 3 outlet.3.id: 3 outlet.3.status: On output.current:9.4 output.current.nominal: 24.0 output.frequency: 60.0 output.phases: 1 output.voltage: 115.3 output.voltage.nominal: 120 ups.beeper.status: enabled ups.firmware: Cont:01.01 ups.load: 37.5 ups.model: COMPAQ UPS 2900VA ups.power: 1080.5 ups.power.nominal: 2900 ups.serialMPAQ ups.status: OL So this is starting to look much better. I wish I'd realized sooner that upsd wasn't just complaining, but complaining *and dying*. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
Citeren Brother Railgun of Reason : babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] Weird, apparently your system has a limited number of file descriptors available. I have a feeling that this is not a standard operating system. I was a little puzzled by that myself. It's Solaris 10 x86 running on a pretty substantial box, it shouldn't be an OS limitation. Oops, looking at the code I saw this isn't a warning, but a (fatal) error instead (this was not one of the most descriptive error messages I ever wrote). I now recall that this value is OS dependent, so you probably want/need to limit this in upsd.conf through the MAXCONN parameter (which in your case seems to be mandatory). I'm not quite sure what would be the better thing to do in case the (default) MAXCONN value is too high: 1) Bail out with a more descriptive error message 2) Adjust the number of connections to the maximum allowed (with message to syslog) I think it would be much more user friendly to do the latter, but opinions on this are welcomed. For whatever reason, you can't connect to localhost. I've never seen this before. The only thing I can imagine now is that some kind of policy exists that doesn't allow you connect through localhost because this is OS is running as a guest on top of another system. Nope, this is not a client OS or vhost. This is the global zone of a Solaris 10 machine, and as you can see, the above was running as root. This all makes sense now. The server is not running. BTW, upsd.conf is default with everything commented out, which should result in listening on everything: # This defaults to the global IPv4 listening address and port 3493. You # may specify each interface you want upsd to listen on for connections, # optionally with a port number. We need to change this. This used to be the case in older versions, but we now default to a (safer) localhost only. [...] Could this be because something is limiting it to 256 connections? (Not that I'm ever going to need even a tenth of that 16 connections would be more than I'm ever going to need to use.) I'm wondering whether I should go tweak the source to request only 256 connections (or even 128) and see if upsd still dies on startup. Yes, see a couple of lines down in upsd.conf (no need to tweak the sources for that). Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
On Wed, May 27, 2009 at 08:42:40PM +0200, Kjell Claesson wrote: > > On Wed, May 27, 2009 at 06:04:40PM +0200, Kjell Claesson wrote: > OK, > 8<-snip--- > > With the config indicating 19200, it locks immediately at 19200. I just > > don't get any UPS "signature" displayed on connection: > > > > babylon4:root:/opt/nut:24 # bin/upsdrvctl start > > Network UPS Tools - UPS driver controller 2.4.1 > > Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) > > RS-232 communication subdriver 0.17 > > Connected to UPS on /dev/tty00 with baudrate 19200 > This is right. You dont get anything more from the driver. Oh, OK ... I thought the examples and other list threads with R3000XRs showed a version string being echoed at this point. > > > babylon4:root:/opt/nut:25 # sbin/upsd > > Network UPS Tools upsd 2.4.1 > > listening on 127.0.0.1 port 3493 > > listening on ::1 port 3493 > > /opt/nut/var is world readable > > Connected to UPS [tokamak]: bcmxcp-tokamak > > Maximum number of connections limited to 256 [requested 1024] > > babylon4:root:/opt/nut:26 # bin/upsc toka...@localhost > > Error: Connection failure: Connection refused > This is not so good. But it is the daemon that is complaining > that it can not connect to the socket right. > > Check your configuration once more. I've been over it several times ... it appears upsd is dying immediately after startup, but I don't yet know why. > You have a config block. (not used at the moment. [...] > Yes it looks like it is giving the right sequence for load-segments. So far, so good then... > So check that all permissions on the files and socket directory is right. > The driver is working OK. The way I configured it, that should be /opt/nut/var: [from config.status:] exec /bin/bash "./configure" '--prefix=/opt/nut' '--htmldir=/var/httpd/local/manuals/nut' '--with-serial' '--with-gd-includes=-I/usr/local/include' '--with-gnu-ld' '--with-statepath=/opt/nut/var' '--with-pidpath=/opt/nut/var' '--with-user=nut' '--with-group=nut' '--with-cgi' '--with-lib' '--without-usb' '--without-snmp' '--without-ssl' $ac_configure_extra_args --no-create --no-recursion babylon4:root:/opt/nut:53 # ls -l . var .: total 15 drwxr-xr-x 2 root nut 44 May 26 21:02 bin/ drwxr-xr-x 2 root nut 5 May 26 21:02 cgi-bin/ drwxr-x--- 2 root nut 15 May 26 21:15 etc/ drwxr-xr-x 2 root nut 6 May 26 21:02 html/ drwxr-xr-x 2 root nut 2 May 26 21:02 include/ drwxr-xr-x 3 root nut 7 May 26 21:02 lib/ drwxr-xr-x 2 root nut 5 May 26 21:02 sbin/ drwxr-xr-x 3 root nut 5 May 26 21:02 share/ drwxrwx--- 2 root nut 4 May 27 16:51 var/ var: total 2 srw-rw 1 nut nut 0 May 27 16:51 bcmxcp-tokamak= -rw-r--r-- 1 nut nut 4 May 27 16:51 bcmxcp-tokamak.pid babylon4:root:/opt/nut:54 # ls -l /dev/tty00 lrwxrwxrwx 1 root root 26 Apr 18 18:48 /dev/tty00 -> ../devices/isa/a...@1,3f8:a babylon4:root:/opt/nut:55 # ls -l /devices/isa/a...@1,3f8:a crw-rw 1 root nut 106, 0 May 27 17:17 /devices/isa/a...@1,3f8:a -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
On Wed, May 27, 2009 at 08:56:13PM +0200, Arjen de Korte wrote: > Citeren Brother Railgun of Reason : > >> babylon4:root:/opt/nut:24 start >> Network UPS Tools - UPS driver controller 2.4.1 >> Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) >> RS-232 communication subdriver 0.17 >> Connected to UPS on /dev/tty00 with baudrate 19200 > > OK, the driver is running, so this is not the problem. > >> babylon4:root:/opt/nut:25 # sbin/upsd >> Network UPS Tools upsd 2.4.1 >> listening on 127.0.0.1 port 3493 >> listening on ::1 port 3493 >> /opt/nut/var is world readable >> Connected to UPS [tokamak]: bcmxcp-tokamak >> Maximum number of connections limited to 256 [requested 1024] > > Weird, apparently your system has a limited number of file descriptors > available. I have a feeling that this is not a standard operating system. I was a little puzzled by that myself. It's Solaris 10 x86 running on a pretty substantial box, it shouldn't be an OS limitation. >> babylon4:root:/opt/nut:26 # bin/upsc toka...@localhost >> Error: Connection failure: Connection refused > > For whatever reason, you can't connect to localhost. I've never seen this > before. The only thing I can imagine now is that some kind of policy exists > that doesn't allow you connect through localhost because this is OS is > running as a guest on top of another system. Nope, this is not a client OS or vhost. This is the global zone of a Solaris 10 machine, and as you can see, the above was running as root. BTW, upsd.conf is default with everything commented out, which should result in listening on everything: # This defaults to the global IPv4 listening address and port 3493. You # may specify each interface you want upsd to listen on for connections, # optionally with a port number. Despite the above statement, this *actually* results in upsd defaulting to listening only on loopback. I just tried explicitly adding the machine's external IP as well: LISTEN 127.0.0.1 3493 LISTEN 10.24.32.14 3493 babylon4:root:/opt/nut:42 # sbin/upsd -DDD Network UPS Tools upsd 2.4.1 listen_add: added 127.0.0.1:3493 listen_add: added 10.24.32.14:3493 setuptcp: try to bind to 10.24.32.14 port 3493 listening on 10.24.32.14 port 3493 setuptcp: try to bind to 127.0.0.1 port 3493 listening on 127.0.0.1 port 3493 Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] and then telnetting to port 3493, still from localhost, and I still couldn't connect to port 3493. So, being a nasty suspicious sort, I checked lsof ... nothing's got port 3493 open. checked the process table ... upsd isn't running. It appears to start up, then immediately die. Could this be because something is limiting it to 256 connections? (Not that I'm ever going to need even a tenth of that 16 connections would be more than I'm ever going to need to use.) I'm wondering whether I should go tweak the source to request only 256 connections (or even 128) and see if upsd still dies on startup. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
Citeren Brother Railgun of Reason : babylon4:root:/opt/nut:24 start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) RS-232 communication subdriver 0.17 Connected to UPS on /dev/tty00 with baudrate 19200 OK, the driver is running, so this is not the problem. babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] Weird, apparently your system has a limited number of file descriptors available. I have a feeling that this is not a standard operating system. babylon4:root:/opt/nut:26 # bin/upsc toka...@localhost Error: Connection failure: Connection refused For whatever reason, you can't connect to localhost. I've never seen this before. The only thing I can imagine now is that some kind of policy exists that doesn't allow you connect through localhost because this is OS is running as a guest on top of another system. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
[oops, forgot to copy list] On Wed, May 27, 2009 at 06:04:40PM +0200, Kjell Claesson wrote: > > On Tue, May 26, 2009 at 09:51:31PM -0400, Brother Railgun of Reason wrote: > Hi, > > > ups.conf looks like this: > > > > > > [tokamak] > > > driver = bcmxcp > > > port= /dev/tty00 > > > baud_rate = 19200 > > > desc= HP R3000XR (main rack) > > > > (Oops. That's *after* changing to the 19200 rate the driver claims to > > autodetect.) > That sound strange. It should hit 19200 direct if it is in the config. > And the HP R3000XR is communicating at 19200 default. That type > is the reason the baud changing got into the driver. Sorry, I confused the issue a little there. I originally had 9600 specified. It failed to connect at 9600, autodetected, and claimed sync at 19200. When I went back and pasted in the config section, I didn't realize until too late that I'd pasted the config from *after* editing to 19200 in before the stage of the process where I'd actually done so. With the config indicating 19200, it locks immediately at 19200. I just don't get any UPS "signature" displayed on connection: babylon4:root:/opt/nut:24 # bin/upsdrvctl start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) RS-232 communication subdriver 0.17 Connected to UPS on /dev/tty00 with baudrate 19200 babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] babylon4:root:/opt/nut:26 # bin/upsc toka...@localhost Error: Connection failure: Connection refused > If it say it connect it is talking to the ups. But to be sure about that, you > may run it in debug mode, like this. > > /path/to/bcmxcp -DD -a tokamak > (stop it by hitting ctrl-c) > > Now it would spit out some info. I'm interested in the output. There may > be some problems how the HP is counting the load-segments. > It depends on the version of the firmware in the ups. That generates a lot of output with many repeats. I've edited out most of the repeats from the end of the following: debug level is '2' Connected to UPS on /dev/tty00 with baudrate 19200 Length of meter map: 82 Index Offset Format NUT 001561 None 0018000461 input.current 0021000861 None 0023001261 ups.power 0027001651 output.frequency 0028002051 input.frequency 0031002461 None 0033002851 battery.voltage 0034003251 battery.charge 00350036e2 battery.runtime 0056004061 input.voltage 0062004461 ambient.temperature 0065004861 output.current 0068005261 output.current.nominal 0071005661 None 0078006061 output.voltage Length of alarm map: 27 Index Alarm Supported INVERTER_AC_OVER_VOLTAGEYes 0001INVERTER_AC_UNDER_VOLTAGE Yes -001INVERTER_OVER_OR_UNDER_FREQ No -001BYPASS_AC_OVER_VOLTAGE No -001BYPASS_AC_UNDER_VOLTAGE No -001BYPASS_OVER_OR_UNDER_FREQ No 0002INPUT_AC_OVER_VOLTAGE Yes 0003INPUT_AC_UNDER_VOLTAGE Yes 0004INPUT_UNDER_OR_OVER_FREQYes -001OUTPUT_OVER_VOLTAGE No -001OUTPUT_UNDER_VOLTAGENo -001OUTPUT_UNDER_OR_OVER_FREQ No 0005REMOTE_EMERGENCY_PWR_OFFYes -001REMOTE_GO_TO_BYPASS No -001BUILDING_ALARM_6No -001BUILDING_ALARM_5No -001BUILDING_ALARM_4No -001BUILDING_ALARM_3No -001BUILDING_ALARM_2No -001BUILDING_ALARM_1No -001STATIC_SWITCH_OVER_TEMP No -001CHARGER_OVER_TEMP No -001CHARGER_LOGIC_PWR_FAIL No -001CHARGER_OVER_VOLTAGE_OR_CURRENT No -001INVERTER_OVER_TEMP No 0006OUTPUT_OVERLOAD Yes 0007RECTIFIER_INPUT_OVER_CURRENTYes 0008INVERTER_OUTPUT_OVER_CURRENTYes 0009DC_LINK_OVER_VOLTAGEYes -001DC_LINK_UNDER_VOLTAGE No -001RECTIFIER_FAILEDNo 0010INVERTER_FAULT Yes -001BATTERY_CONNECTOR_FAIL No -001BYPASS_BREAKER_FAIL No 0011CHARGER_FAILYes -001RAMP_UP_FAILED No -001STATIC_SWITCH_FAILEDNo -001ANALOG_AD_REF_FAIL No -001BYPASS_UNCALIBRATED No -001RECTIFIER_UNCALIBRATED No -001OUTPUT_UNCALIBRATED No -001INVERTER_UNCALIBRATED No -001DC_VOLT_UNCALIBRATEDNo -001OUTPUT_CURRENT_UNCALIBRATED No -001RECTIFIER_CURRENT_UNCALIBRATED No -001BATTERY_CURRENT_UNCALIBRATEDNo -001INVERTER_ON_OFF_STAT_FAIL No -001BATTERY_CURRENT_LIMIT No -001INVERTER_STARTUP_FAIL No -001ANALOG_BOARD_AD_STAT_FAIL No -001OUTPUT_CURRENT_OVER_100 No -001BATTERY_GROUND_FAULTNo -001WAITING_FOR_CHARGER_SYNCNo -001NV
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
> On Tue, May 26, 2009 at 09:51:31PM -0400, Brother Railgun of Reason wrote: Hi, > > ups.conf looks like this: > > > > [tokamak] > > driver = bcmxcp > > port= /dev/tty00 > > baud_rate = 19200 > > desc= HP R3000XR (main rack) > > (Oops. That's *after* changing to the 19200 rate the driver claims to > autodetect.) That sound strange. It should hit 19200 direct if it is in the config. And the HP R3000XR is communicating at 19200 default. That type is the reason the baud changing got into the driver. > > > Am I using the correct cable here? If not, what's the correct cable to > > use? If it say it connect it is talking to the ups. But to be sure about that, you may run it in debug mode, like this. /path/to/bcmxcp -DD -a tokamak (stop it by hitting ctrl-c) Now it would spit out some info. I'm interested in the output. There may be some problems how the HP is counting the load-segments. It depends on the version of the firmware in the ups. > > The other detail I forgot to add was that, just out of sheer > constructive paranoia, I tried using an APC 940-0024C cable instead of > the HP cable, which as far as I can tell with a DVM is just a dumb > serial cable wired all nine pins straight through. With the HP cable, > the driver thinks it has comm sync at 19200, but upsdrvctl can't talk to > it; with the APC cable, the driver can't even establish communication at > all. /Kjell ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
On Tue, May 26, 2009 at 09:51:31PM -0400, Brother Railgun of Reason wrote: > ups.conf looks like this: > > [tokamak] > driver = bcmxcp > port= /dev/tty00 > baud_rate = 19200 > desc= HP R3000XR (main rack) (Oops. That's *after* changing to the 19200 rate the driver claims to autodetect.) > Am I using the correct cable here? If not, what's the correct cable to > use? The other detail I forgot to add was that, just out of sheer constructive paranoia, I tried using an APC 940-0024C cable instead of the HP cable, which as far as I can tell with a DVM is just a dumb serial cable wired all nine pins straight through. With the HP cable, the driver thinks it has comm sync at 19200, but upsdrvctl can't talk to it; with the APC cable, the driver can't even establish communication at all. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] New NUT user with HP R3000XR problem
Greetings, I've just installed nut-2.4.1 on a Solaris 10 x86 machine to monitor a HP R3000XR UPS. SunOS babylon4 5.10 Generic_138889-08 i86pc i386 i86pc Solaris First of all, I encountered a single problem during the build. After configuring, drivers/Makefile ends up containing the following line: LIBNETSNMP_LDFLAGS = -R../lib -L/usr/sfw/lib -lnetsnmp -lgen [...] This is clearly wrong, as runtime lib specifications cannot be relative. By correcting that to -R/usr/sfw/lib, everything compiled and installed fine. (This occurs regardless of whether or not snmp support is enabled.) I've already seen from the list archives that the BCMXCP driver is the correct driver for this UPS. I have already verified that I have the correct serial port and that it's working properly (I am able to communicate with an APC SU1400 on this port, using apcupsd-3.14.6 and an APC 940-0024C cable, with no problems). I have set the port permissions as per the install instructions, I've set the baud rate on the port to 9600 as per existing threads in the archives, and I'm using the HP straight-through serial cable (or is it just a serial extension cable?) that came with the UPS. That cable bears the following identifying information: HP 397237-002 SPARES P/N 397642-001 5006 ups.conf looks like this: [tokamak] driver = bcmxcp port= /dev/tty00 baud_rate = 19200 desc= HP R3000XR (main rack) This is where things start going pear-shaped. I apparently cannot communicate with the UPS. I can start the bcmxcp driver, but it fails to communicate at 9600, and "autodetects" a rate of 19200: babylon4:root:/opt/nut/etc:9 # ../bin/upsdrvctl start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) RS-232 communication subdriver 0.17 No response from UPS on /dev/tty00 with baudrate 9600 Attempting to autodect baudrate Connected to UPS on /dev/tty00 with baudrate 19200 If I set baud_rate=19200 in ups.conf, that starts right up: babylon4:root:/opt/nut/etc:11 # ../bin/upsdrvctl start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) RS-232 communication subdriver 0.17 Connected to UPS on /dev/tty00 with baudrate 19200 But neither gets any model or version information from the UPS. I can start upsd: babylon4:root:/opt/nut/etc:18 # ../sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] but can't get status from the UPS: babylon4:root:/opt/nut/etc:19 # ../bin/upsc toka...@localhost ups.status Error: Connection failure: Connection refused Am I using the correct cable here? If not, what's the correct cable to use? If I am already using the correct cable, I'm presuming this means my UPS's RS232 module is toast. Thanks. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
