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

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/20230309/e0de75ff/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Matthews_logs.tar.gz
Type: application/gzip
Size: 3909 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230309/e0de75ff/attachment.gz>

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>