NUT on SNMP V1 and V3 ups is unavailable

sgnoc

@dennypage Here is the output in a text file compressed to .gz. Hope that works.

ups.txt.gz

dennypage

Clearly a bug:

  32.274823	[D3] Entering nut_snmp_get_int()
  32.274826	[D3] nut_snmp_get(.1.3.6.1.4.1.3808.1.1.1.4.1.1.0)
  32.274828	[D3] nut_snmp_walk(.1.3.6.1.4.1.3808.1.1.1.4.1.1.0)
  32.274839	[D4] nut_snmp_walk: max. iteration = 1
  32.275454	[D2] SNMP UPS driver: entering su_status_set()
  32.275462	[D1] su_find_infoval: no matching INFO_* value for this OID value (2)
  32.275466	[D2] => value: 2

That OID is the ups.status. The "no matching INFO_* value is definitely incorrect.

This didn't make any sense until I started looking through the prior versions of the cyberpower-mib code. It turns out that this was a bug introduced in 2.8.0 (like so many others), and fixed very shortly thereafter.

The original bug report is here, and the fix was checked in here.

At this time, there is no release version of 8.x NUT that has the fix. However FreeBSD set up a "nut-devel" port to track the current dev tree, and I did a build from nut-devel build back in February to address a problem with the usb driver. I built the entire driver set at the time, including snmp-ups.

I've attached the build of snmp-ups that I did back in February. I expect that it will address the issue. Note that this build if for Intel / amd 64 bit. It will not work on arm (I don't have an arm system).

snmp-ups.gz

dabernards

@dennypage what's involved getting this fix on arm? I have a Netgate 1100 where I'd like to get this working.

dennypage

@dabernards said in NUT on SNMP V1 and V3 ups is unavailable:

what's involved getting this fix on arm?

You just need to do a build of nut-devel in FreeBSD Ports. I don't have an arm system (or a cross development system) or I would do it for you.

Or perhaps someone reading this with an arm system might volunteer to do a build?

sgnoc

@dennypage Thanks for the help and that it is a known bug, at least that makes more sense now.

I did swap the old snmp-ups for the one you built, but it is giving new errors. I'll post them here in case something jumps out that I may need to do an additional step, otherwise I'll just use the broken version until they finally release the free-bsd update that will get pushed to the package manager.

Below, I stop the service, move snmp-ups to snmp-ups-old, and then copy in your snmp-ups and set permissions to match. Owner/Group already were the same. When that was giving errors, I went back to the UPS GUI and saved the settings, to see if that would possibly trigger a restart that would work. Same result, but that's why you see 2 startups below.

2023-05-30 07:35:08.167112-04:00 	upsmon 	19088 	Signal 15: exiting
2023-05-30 07:35:03.169246-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:58.159275-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:53.147750-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:48.137510-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:43.126722-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:38.124049-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:33.120445-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:28.112044-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:23.104408-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:18.097110-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:13.094863-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:08.092775-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:34:03.090538-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:33:58.079900-04:00 	upsmon 	19088 	UPS CyberPowerCP2200 is unavailable
2023-05-30 07:33:58.079873-04:00 	upsmon 	19088 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:33:53.074942-04:00 	upsmon 	19088 	Communications with UPS CyberPowerCP2200 lost
2023-05-30 07:33:53.074914-04:00 	upsmon 	19088 	UPS [CyberPowerCP2200]: connect failed: Connection failure: Connection refused
2023-05-30 07:33:53.068205-04:00 	upsmon 	18344 	Startup successful
2023-05-30 07:33:53.042591-04:00 	upsmon 	30616 	Signal 15: exiting
2023-05-30 07:33:49.558079-04:00 	upsmon 	30616 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:33:44.555560-04:00 	upsmon 	30616 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:33:39.545766-04:00 	upsmon 	30616 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:33:34.541513-04:00 	upsmon 	30616 	UPS CyberPowerCP2200 is unavailable
2023-05-30 07:33:34.541485-04:00 	upsmon 	30616 	Poll UPS [CyberPowerCP2200] failed - Driver not connected
2023-05-30 07:33:29.531051-04:00 	upsmon 	30616 	Communications with UPS CyberPowerCP2200 lost
2023-05-30 07:33:29.531025-04:00 	upsmon 	30616 	UPS [CyberPowerCP2200]: connect failed: Connection failure: Connection refused
2023-05-30 07:33:29.524269-04:00 	upsmon 	29998 	Startup successful
2023-05-30 07:28:33.520811-04:00 	snmp-ups 	36164 	Signal 15: exiting
2023-05-30 07:28:33.513631-04:00 	upsmon 	35369 	Signal 15: exiting
2023-05-30 07:24:12.929094-04:00 	upsmon 	35369 	UPS CyberPowerCP2200 is unavailable
2023-05-30 07:19:07.657510-04:00 	upsmon 	35369 	UPS CyberPowerCP2200 is unavailable
2023-05-30 07:14:02.354888-04:00 	upsmon 	35369 	UPS CyberPowerCP2200 is unavailable
2023-05-30 07:08:57.067017-04:00 	upsmon 	35369 	UPS CyberPowerCP2200 is unavailable

dennypage

@sgnoc You won't see startup messages from the new snmp-ups because it is the wrong architecture and the OS cannot actually start the process. The upsmon messages indicate that the driver (snmp-ups) is not connected to upsd.

sgnoc

@dennypage the 7100 uses the Intel Atom CPU C3558, which the Intel site says is 64 bit architecture. Shouldn't that work on your 64 bit build? I thought it would be a simple swap out with the same architecture.

dennypage

@sgnoc Sorry, I conflated you with the prior poster who is on a different arch.

There are no log entries for snmp-ups after you restarted, which means that the process did not start.

Double check that the executable is in the correct location, and that the ownership and permissions are the same as the previous version.

If all of that looks good, you try can starting snmp-ups by hand to see if it shows an error.

sgnoc

@dennypage I've been trying to get it to run. I had the correct permissions and user/group to match the previous binary, but still the same result loading it on the pfsense gui. I attempted to get it to start in command prompt.

The only combination of options to get it to even load was to run the nut service in the gui, which generated the logs that it wasn't loaded (as posted previously), then I ran the command:

sudo ./snmp-ups -s CyberPowerCP2200 -x port=10.10.5.10 -u nut

This at least ran the snmp-ups and I was able to get a log saying

Communications with UPS CyberPowerCP2200 established

But when I go to the gui status page, instead of "OK" in the status line, it shows "OL" which are the first 2 characters of the UPS model number. So, I'm guessing things still aren't quite right. Also the following messages were posted when I ran the binary from command prompt:

Network UPS Tools - Generic SNMP UPS driver 1.28 (11-eol-49673-g687a1b3d4995)
Detected OL2200RTXL2U on host 10.10.5.10 (mib: cyberpower 0.52)
[CyberPowerCP2200] unhandled ASN 0x5 received from .1.3.6.1.4.1.3808.1.1.1.7.2.7.0
WARNING: Needed to fix group access to filesystem socket of this driver, but failed; run the driver with more debugging to see how exactly.
Consumers of the socket, such as upsd data server, can fail to interact with the driver and represent the device: /var/db/nut/snmp-ups-CyberPowerCP2200

Broadcast Message from root@netgate.gause3.lan
        (no tty) at 20:50 EDT...

Communications with UPS CyberPowerCP2200 established

I wasn't able to find the parameters that are normally run from the NUT service to start the snmp-ups binary, so I'm still not sure why the service isn't able to get it started, but it also seems to still have some issues with the snmp data being received.

I'll just have to wait and see if an update gets pushed that might work. Until then, it seems like the buggy binary may still at least get snmp messages from the UPS in the event of power failure and battery usage. I'll go back to that and hope for the best until a new update is released. Thanks for the help.

dennypage

@sgnoc run snmp-ups with debug as described above. Make sure that no other snmp-ups is running at the same time. Also run the upsc command while it is running.

sgnoc

@dennypage Thanks, running these again let me figure out the issue. I had to specify user as nut for the new version binary. I guess there was a default user change between the versions, and the new binary was getting permission denied errors for /var/db/nut using the user uucp. I set the parameter user=nut in the ups.conf and that fixed it not being able to start up.

New issue is the status is showing OL instead of Ok, so I'm guessing the snmp data isn't being parsed properly for cyberpower. I've attached a .gz file for the /tmp/out file I ran for another 100 seconds. I'm not really familiar with the snmp to understand the output properly.

ups2.txt.gz

Here is the output of the uspc command:

battery.charge: 100
battery.current: 3.30
battery.runtime: 3300
battery.runtime.elapsed: 0
battery.voltage: 79.10
battery.voltage.nominal: 72
device.contact: Shaun
device.description: UPS SNMP Card
device.location: Basement
device.mfr: CYBERPOWER
device.model: OL2200RTXL2U
device.serial: WBGEP2000038
device.type: ups
driver.name: snmp-ups
driver.parameter.pollinterval: 2
driver.parameter.port: 10.10.5.10
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 11-eol-49673-g687a1b3d4995
driver.version.data: cyberpower MIB 0.52
driver.version.internal: 1.28
input.frequency: 60
input.voltage: 123.20
output.current: 3.30
output.frequency: 60
output.voltage: 120
ups.delay.reboot: 0
ups.delay.shutdown: 180
ups.delay.start: 0
ups.firmware: S1A14
ups.load: 18
ups.mfr: CYBERPOWER
ups.model: OL2200RTXL2U
ups.serial: WBGEP2000038
ups.status: OL

The summary status for the gui says on line, at least. So that's some progress with the new version.

***Edit: after I submitted this, I re-read my last line and it hit me that the ups.status OL isn't an error reading the first 2 characters of the model of OL, but is short for the status listed of "on line". Don't know why that didn't click before. So I think all I needed to do with your newer version binary was to change the user from the default uucp username to the old default of nut, and now I'm good to go.

Thanks for the help, I'll standby with this version until NUT pushed a free-bsd update at some point.***

Side note: still getting an unhandled error in the logs:

[CyberPowerCP2200] unhandled ASN 0x5 received from .1.3.6.1.4.1.3808.1.1.1.7.2.7.0

But I don't think that is negatively affecting anything.

dennypage

@sgnoc The status field is made up of collections of character sequences separated by spaces:

OL: On line
OB: On Battery
LB: Low Battery
RB: Replace Battery
CAL: Runtime Calibration
FSD: Forced Shut Down

WRT the unhandled oid, correct that you don’t need to worry about it.

sgnoc

@dennypage Great, thanks again for the help and walking me through the extra steps. I'm up and running now. I appreciate it!

dennypage

@sgnoc You’re welcome