Nut upsuser - Mar 2015 - Tripplite SNMPwebcard communication lost and established randomly

Just started using NUT and having a problem. I'm not sure if it is even NUT
that is causing the issue.
I'm running the latest FreeNAS 9.3 release.
Network UPS Tools upsmon 2.7.2.
The UPS is a Tripplite SU6000RT4UHVPM with the SNMPwebcard installed.
I'm trying to use the SNMPwebcard, not USB or Serial. I've updated the
SNMPwebcard to the latest firmware version (see below).

In FreeNAS I was able to create a connection to the UPS by simply adding the IP
address for the Port and defining the driver as "Various ups 3 (various)
SNMP - RFC 1628 (snmp-ups)". After that querying it just worked via
"upsc tripplite". And everything looks fine. However after a few hours
I started getting emails and messages in the console about communication lost
(COMMBAD) and shortly after it being established. This happens over and over
again. I thought perhaps I needed to change some of the settings in ups.conf. I
tried adjusting the pollfreq up to 30, using an snmp_version v2c, and a few
other adjustments. However the behavior persists.

I just stated to use NUT. I'm not sure if NUT is causing this, or perhaps
the SNMPwebcard in the UPS. Or perhaps a switch on the network. And I'm not
really sure how to figure it out. I'm starting with NUT since that is the
only thing currently that is exhibiting this behavior. Perhaps this is something
others have seen and know how to fix. A portion of what I am seeing in the
console below.

[root at freenas] /usr/local/libexec/nut# upsc tripplite
battery.charge: 100.00
battery.runtime: 4020.00
battery.temperature: 17.00
battery.voltage: 219.00
device.mfr: TRIPPLITE
device.model: SU6000RT4UHVPM
device.type: ups
driver.name: snmp-ups
driver.parameter.pollinterval: 2
driver.parameter.port: 192.168.0.24
driver.parameter.snmp_version: v2c
driver.version: 2.7.2
driver.version.data: ietf MIB 1.4
driver.version.internal: 0.72
input.bypass.frequency: 59.90
input.bypass.phases: 1.00
input.bypass.voltage: 209.00
input.frequency: 59.90
input.phases: 1.00
input.transfer.high: 300.00
input.transfer.low: 100.00
input.voltage: 209.00
input.voltage.nominal: 220.00
output.current: 0.20
output.frequency: 60.00
output.phases: 1.00
output.realpower: 419.00
output.voltage: 220.00
ups.beeper.status: enabled
ups.firmware: 06
ups.firmware.aux: 12.06.0064
ups.load: 80.00
ups.mfr: TRIPPLITE
ups.model: SU6000RT4UHVPM
ups.status: OL

Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 20:37 EDT...

Communications with UPS tripplite lost


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 20:38 EDT...

Communications with UPS tripplite established



Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 0:38 EDT...

Communications with UPS tripplite lost


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 0:38 EDT...

Communications with UPS tripplite established


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 1:38 EDT...

Communications with UPS tripplite lost


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 1:38 EDT...

Communications with UPS tripplite established


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 3:09 EDT...

Communications with UPS tripplite lost


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 3:09 EDT...

Communications with UPS tripplite established


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 3:39 EDT...

Communications with UPS tripplite lost


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 3:39 EDT...

Communications with UPS tripplite established


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 4:09 EDT...

Communications with UPS tripplite lost


Broadcast Message from root at freenas.internal.cddiagnostics.com
        (no tty) at 4:09 EDT...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150330/7f3382d9/attachment.html>

On Mar 30, 2015, at 10:41 AM, Jason Gould <jgould at cddiagnostics.com>
wrote:
> Just started using NUT and having a problem. I?m not sure if it is even NUT
that is causing the issue.
> I?m running the latest FreeNAS 9.3 release.
> Network UPS Tools upsmon 2.7.2.
> The UPS is a Tripplite SU6000RT4UHVPM with the SNMPwebcard installed.
> I?m trying to use the SNMPwebcard, not USB or Serial. I?ve updated the
SNMPwebcard to the latest firmware version (see below).
Thanks, this is good background information.
 
> In FreeNAS I was able to create a connection to the UPS by simply adding
the IP address for the Port and defining the driver as ?Various ups 3 (various)
SNMP - RFC 1628 (snmp-ups)?. After that querying it just worked via ?upsc
tripplite?. And everything looks fine. However after a few hours I started
getting emails and messages in the console about communication lost (COMMBAD)
and shortly after it being established. This happens over and over again. I
thought perhaps I needed to change some of the settings in ups.conf. I tried
adjusting the pollfreq up to 30, using an snmp_version v2c, and a few other
adjustments. However the behavior persists.
There are two stages here: the snmp-ups driver polls every 'pollfreq'
seconds, and upsmon sends a warning if an UPS is stale for longer than DEADTIME
seconds (as set in upsmon.conf). So if you increase pollfreq, you would probably
want to increase DEADTIME as well. (I'm not sure how FreeNAS exposes this
setting.) The upsmon.conf documentation recommends multiplying pollfreq by three
to get DEADTIME. You may want to go higher than that, depending on how long the
interval is between COMMBAD and COMMOK (the messages you quoted only have
one-minute resolution).

Unfortunately, it looks like snmp-ups goes into COMMBAD mode if even one of the
SNMP queries fails (and it queries a lot of OIDs), so you would need to rely on
DEADTIME to filter out any transient packet loss. You might also see if your
firewall or switch can prioritize SNMP packets using QoS settings - I am not
familiar with how many times NetSNMP retries, but SNMP is UDP-based.

You could also try running 'snmpwalk' by hand against the SNMPwebcard to
see if it experiences the same packet loss. If that doesn't work, I think
you have a case for Tripp Lite support.

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150330/e76c5cd6/attachment-0001.html>