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

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/20230327/f725fe10/attachment.htm>

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>