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

Thu Mar 30 15:30:29 BST 2023

Well thanks,
The solution for my problem was kinda easy (still need some testing
though): found out my ups status is a string, so then I changed the way
snmp-ups.c gets the status.
Had to change *nut_snmp_get_int *to *nut_snmp_get_str *at around line 3470,
then grab fourth char out, use *strtol *function to then send it to
*su_status_set
*function.
I created my copy of *apc-mib.c *with my OID at place, then did cases for
0/1 values and Voilà!
(I know I probably need some if's there so other non-string-status UPS's
would work with my config but I'm happy nonetheless :))

Matthew

śr., 29 mar 2023 o 13:31 Jim Klimov <jimklimov+nut at gmail.com> napisał(a):

> 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/20230330/46f8a8b7/attachment.htm>