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

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>

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>