[Nut-upsdev] Issue with On Line Status (APC MGE Galaxy 5500 + AP9635CH)

Wed Mar 29 12:30:56 BST 2023

One good intro to this is
https://github.com/networkupstools/nut/blob/master/docs/snmp-subdrivers.txt
although it focuses on adding new subdrivers - but more or less the same
workflow applies to extending existing ones. Sometimes it helps to generate
a new one for a currently-partially-supported device, and then compare with
existing subdriver (using meld or similar GUI helps a lot) to port the
missing lines into it.

In computers all numbers are binary :) In SNMP they should be Integer32 or
Integer64 type, I think. Do you know which APC MIB version that NMC
supports, and if that MIB's text contradicts the reality (an APC bug to
report to them, I guess).

In the nut2mib structures you can specify several sources for the same
reading name, which allows the same subdriver to "pick the keys" to
different generations of otherwise similar devices. The first (or was it
last?) hit in the table wins, IIRC, so if an actual device exposes some
data in several OIDs (e.g. with different-precision data types, like in
vendor-extended vs. IETF-standard MIBs), the preference ordering may matter.

Jim

On Mon, Mar 27, 2023 at 2:01 PM mateuszx <jasmati09 at gmail.com> wrote:

> So what would it take me to edit NUT's code for my case to work? My
> Network Management Card sends its output state using unfortunately only (I
> guess so) this OID: 1.3.6.1.4.1.318.1.1.1.11.1.1.0
> Weirdly the standard way of obtaining Battery Status (drivers/apc-mib.c) 1.3.6.1.4.1.318.1.1.1.2.1.1.0
> gives me good results.
> Unfortunately power status OID's value type differs (my: 64 digits binary
> number vs standard: integer).
> I know i can retrieve each bit's value with no problem but the question
> is: How do I integrate my bit recognition with NUT's nut2mib struct and so
> on...
> I am working on drivers/apc-mib.c UPS driver
> Maybe is there something relatable already in the code so I can "make my
> work easier"?
>
> Matthew
>
> czw., 9 mar 2023 o 16:00 mateuszx <jasmati09 at gmail.com> napisał(a):
>
>> I've got an update on this case
>> Using tkmib I discovered that my UPS (NMC per say) sends its state by OID
>> 1.3.6.1.4.1.318.1.1.1.11.1.1.0
>> .iso.org.dod.internet.private.enterprises.apc.products.hardware.ups.upsState.upsBasicState.upsBasicStateOutputState.0
>> = 0001010000000000001000000000000000000000000000000000000000000000
>> (mib used for this snmpget was powernet441.mib)
>> (I got a description about each bit here, 4th bit is for OnLine, 6th
>> stands for Serial Communication Established, 19th is "On")
>>
>> Then I ran tcpdump grepping for this kind of OID. First using
>> snmpget/snmpwalk, then using upsc asking for ups.status or the entire upsc
>> output.
>> I've included tcpdump logs as well as the description of OID I've found.
>>
>> My question: is getting ups.status about changing "a few lines of code"
>> in let's say apc-mib.c file in the drivers folder of the repo or I should
>> make a commit and code ups.status depending on bits received using this OID?
>> I am running NUT 2.8.0 at the moment.
>>
>> czw., 9 mar 2023 o 14:14 mateuszx <jasmati09 at gmail.com> napisał(a):
>>
>>> I've got an update on this case
>>> Using tkmib I discovered that my UPS (NMC per say) sends its state by
>>> OID 1.3.6.1.4.1.318.1.1.1.11.1.1.0
>>> .iso.org.dod.internet.private.enterprises.apc.products.hardware.ups.upsState.upsBasicState.upsBasicStateOutputState.0
>>> = 0001010000000000001000000000000000000000000000000000000000000000
>>> (mib used for this snmpget was powernet441.mib)
>>> (I got a description about each bit here, 4th bit is for OnLine, 6th
>>> stands for Serial Communication Established, 19th is "On")
>>>
>>> Then I ran tcpdump grepping for this kind of OID. First using
>>> snmpget/snmpwalk, then using upsc asking for ups.status or the entire upsc
>>> output.
>>> I've included tcpdump logs as well as the description of OID I've found.
>>>
>>> My question: is getting ups.status about changing "a few lines of code"
>>> in let's say apc-mib.c file in the drivers folder of the repo or I should
>>> make a commit and code ups.status depending on bits received using this OID?
>>> I am running NUT 2.8.0 at the moment.
>>>
>>> Matthew
>>>
>>>
>>> czw., 2 mar 2023 o 10:46 mateuszx <jasmati09 at gmail.com> napisał(a):
>>>
>>>> NUT version is 2.7.4-14ubuntu2 indeed.
>>>> I think my next step will be examining data sent over SNMP, because
>>>> I've recently spotted some more problems with my device and so I will try
>>>> contacting APC for those reasons.
>>>> Anyway thanks for the output, I really appreciate it
>>>>
>>>> Matthew
>>>>
>>>> wt., 28 lut 2023 o 13:29 Jim Klimov via Nut-upsdev <
>>>> nut-upsdev at alioth-lists.debian.net> napisał(a):
>>>>
>>>>> Also, which version of NUT is involved? There were recently PRs
>>>>> (merged to master-branch, eventually will be in 2.8.1) about more SNMP-UPS
>>>>> support including APCs e.g. 1674, 1679, 1113 (should be in 2.8.0)...
>>>>>
>>>>> Many distros still ship 2.7.4...
>>>>>
>>>>> Jim
>>>>>
>>>>> On Tue, Feb 28, 2023, 00:57 Greg Troxel <gdt at lexort.com> wrote:
>>>>>
>>>>>> mateuszx via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:
>>>>>>
>>>>>> > At my workplace I have exact UPS config as stated in the subject
>>>>>> (APC MGE
>>>>>> > Galaxy 5500 + AP9635CH).
>>>>>> > I have it set up to work with snmp-ups NUT driver.
>>>>>> > Despite many readings from *upsc* command I am not receiving "On
>>>>>> Line
>>>>>> > Status" (ups.status OL) nor "On Battery Status" (ups.status OB) and
>>>>>> > therefore I can't get my systems to shutdown during a power outage
>>>>>> event.
>>>>>> > (device and ups) Serial Number seems to be missing too in both
>>>>>> *upsc *AND Web
>>>>>> > Interface of Network Management Card.
>>>>>> > It can read battery charge just fine (it can even trigger Low
>>>>>> Battery
>>>>>> > Status!).
>>>>>> > When I unplug the UPS from line power it does indeed log this event
>>>>>> on the
>>>>>> > Web Interface.
>>>>>>
>>>>>> I would run tcpdump and record and examine the SNMP traffic, and turn
>>>>>> on
>>>>>> debugging in the driver.  It is likely that the SNMP queries for
>>>>>> status
>>>>>> are not doing what the driver author expected.  You'll have to find
>>>>>> out
>>>>>> if your UPS has different variables.  snmpwalk may also be useful, or
>>>>>> docs.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Nut-upsdev mailing list
>>>>>> Nut-upsdev at alioth-lists.debian.net
>>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>>>>>
>>>>> _______________________________________________
>>>>> Nut-upsdev mailing list
>>>>> Nut-upsdev at alioth-lists.debian.net
>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230329/f0f8bcbd/attachment.htm>