[HCL] GE Critical Power - VH Series UL - supported by snmp-ups (mib = ietf)

[PatrickDittrich]

[HCL] GE Critical Power - VH Series UL - supported by snmp-ups (mib = ietf)

[jimklimov]

Thanks a lot for this report, more so with the twist of running on Windows.

Did you build your own, or use the tarballs auto-made by NUT recipes on AppVeyor CI?

Got any hints to share for others who would endeavour with the revived NUT for Windows effort - e.g. how did you register the service(s) so an OS shutdown is actually handled?

Did any of the known-incomplete bits (quite a long list can be seen in the project) bite you in practice of this use-case?

Also, I'd expect the default mibs=auto to maybe complain but eventually find a suitable MIB, e.g. ietf as the last fallback. Did that also work for you, was some mapping discovered despite the "noise"?

IiRC the message itself is about trying a query for SysOID (in the IETF namespace) for a redirection to vendor-defined data (if any), and that OID was not served.

[PatrickDittrich]

I am using the executables from the AppVeyor CI generated 7z artifact (https://ci.appveyor.com/project/nut-travis/nut/history) and wrote a PowerShell script to register nut.exe as a Windows service. Beside the NUT executables I also needed the openSSL binaries (openssl-1.1.1w-win64.zip from https://wiki.overbyte.eu/wiki/index.php/ICS_Download) to be present in the sbin folder and had to copy everything from sbin to bin as well. I can document this under https://github.com/networkupstools/nut/wiki/NUT-for-Windows if you want.

I was not hindered by any of the known-incomplete bits, but the information on running it on Windows is quite scattered around. Also, there are a few things that changed between the old 2.6.5 Windows release and now. For example I needed to run the command shell as admin in order to be able to create the \\.\pipe\snmp-ups-* pipe (was working as normal user under 2.6.5). Also the binaries are quite big (each is around 5-60 MB) resulting in more than 1 GB used for NUT. Further I am unable to run a configuration with snmp_version = v1 and snmp_version = v3 at the same time as there seams to be different versions of openSSL used resulting in a conflict (I needed also to log out and back in after a switch from one version to the other).

When using the default mibs = auto, NUT was settling down to tripplite, so I set it to mibs = ietf myself. I guess it would work as well as it is state here: https://networkupstools.org/docs/man/snmp-ups.html TrippLite UPSes; at this time this is the IETF MIB mapping with just the Tripplite entry point OID to verify the device vendor.

About the OID, see http://oid-info.com/cgi-bin/display?oid=1.3.6.1.4.1.818.1.1&a=display and chapter "4 SNMP AGENT" of the SNMP Card manual https://library.industrialsolutions.abb.com/publibrary/checkout/GE_UPS_OPM_CNT_SNM_BAS_CRD_1GB_V022?TNR=Software%7CGE_UPS_OPM_CNT_SNM_BAS_CRD_1GB_V022%7CPDF&filename=GE_UPS_OPM_CNT_SNM_BAS_CRD_1GB_V022.pdf#page=38. I can try to get a SnmpWalk output next week.

[jimklimov]

Thanks for the insights! Probably, a practical chapter in the Wiki (or a new page) would be useful - thanks in advance :)

As for service registration, allegedly the bin/nut.exe program (coming from scripts/Windows/wininit.c in sources) should handle the service registration and un-registration and start-up. At least, so the sources say. Not sure quickly whether/how well it is documented. Some command-line help/usage is sorely missing, made a bit of sense of it from sources though - and found that my attempts to start did log Event Viewer messages :

...
The following information was included with the event: 

StartServiceCtrlDispatcher failed : exiting, this is a Windows service which can't be run as a regular application by default. 
Try -N to start it as a regular application.
...

No comments at the moment about pipe creation - not sure if it really requires privileges or something else was at play... I can only guess that the driver running as a Windows service would be sufficiently privileged. Otherwise, the Windows-side code of NUT did not change very much as part of the revival from 2.6.5-based branch. Was your earlier easier experience with same version/instance of Windows itself - maybe it is the OS that changed in some important aspect?

Regarding OpenSSL libraries - were there any particular complaints? I see that the libssl* and libcrypto* DLLs are present in the tarballed bin directory, so should have been found by the driver and tools. At least, if the exact file naming fits the expectations. If there is indeed some problem with the bundle, it would be great to find a way to reproduce it (like, were you in the relevant directory as "current working directory" when running the program, or did you use relative filenames - stuff like that might be important).

In fact, did the snmp-ups driver complain, or was it the nut-scanner tool (it has a separate routine for dynamic discovery and loading of shared objects/DLLs - and maybe it tries some wrong wordings)?

Finally, re-checked the note about file sizes, and agree that they seem excessive. At the moment (per share/config.nut_report_feature.log file) I can guess this is due to debug build being in effect for CI testing builds (so added symbols, little optimization). Allegedly this can help troubleshoot deployments made from the tarballs on early-bird systems like yours :D