[Nut-upsuser] Welcome to the "Nut-upsuser" mailing list (Digest mode)

Jim Klimov jimklimov+nut at gmail.com
Tue May 19 14:32:48 BST 2026


Seems you are on to something, maybe this commit between v2.7.4 and v2.8.0
releases broke it:
https://github.com/networkupstools/nut/commit/5d97d070699#diff-394069cee27e0ffdde5fa85b9538d059705bc024c2ac59ad903cba8ac31fa5be

Previously the default argument was a different OID for each line, and
afterwards up to now - a "0":

-       { "test.battery.stop", 0, 0, IETF_OID_UPS_MIB "7.1.0",
IETF_OID_UPS_MIB "7.7.2", SU_TYPE_CMD, NULL }, /*
upsTestAbortTestInProgress */
-       { "test.battery.start", 0, 0, IETF_OID_UPS_MIB "7.1.0",
IETF_OID_UPS_MIB "7.7.3", SU_TYPE_CMD, NULL }, /* upsTestGeneralSystemsTest
*/
-       { "test.battery.start.quick", 0, 0, IETF_OID_UPS_MIB "7.1.0",
IETF_OID_UPS_MIB "7.7.4", SU_TYPE_CMD, NULL }, /* upsTestQuickBatteryTest */
-       { "test.battery.start.deep", 0, 0, IETF_OID_UPS_MIB "7.1.0",
IETF_OID_UPS_MIB "7.7.5", SU_TYPE_CMD, NULL }, /*
upsTestDeepBatteryCalibration */
+       { "test.battery.stop", 0, 1, IETF_OID_UPS_MIB "7.1.0", "0",
SU_TYPE_CMD, NULL }, /* upsTestAbortTestInProgress */
+       { "test.battery.start", 0, 1, IETF_OID_UPS_MIB "7.1.0", "0",
SU_TYPE_CMD, NULL }, /* upsTestGeneralSystemsTest */
+       { "test.battery.start.quick", 0, 1, IETF_OID_UPS_MIB "7.1.0", "0",
SU_TYPE_CMD, NULL }, /* upsTestQuickBatteryTest */
+       { "test.battery.start.deep", 0, 1, IETF_OID_UPS_MIB "7.1.0", "0",
SU_TYPE_CMD, NULL }, /* upsTestDeepBatteryCalibration */

Feel free to open the GitHub issue, or if you can build and test locally
that an equivalent change back (now wrapped into snmp_info_default()
macros) helps - you can open a pull request right away.
See e.g.
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
about
building (prerequisites and routine).

Jim


On Tue, May 19, 2026 at 2:22 PM Albert Pavlas <albert.pavlas at k-net.cz>
wrote:

> I see, thank you for the swift response. As for the password I
> accidentally carried over in the reply, it's been changed.
>
> I can affirm that the ietf setting was chosen because it is the only
> protocol that the interface card can speak.
> Here is the debug output from the smtp driver, as was suggested.
>
> ----------------------------
> [D2] entering main_instcmd(test.battery.start, (null)) for
> [knet-olomoucka-1] on socket 6
> [D2] shared main_instcmd() does not handle command test.battery.start,
> proceeding to driver-specific handler
> [D2] entering su_setOID(instcmd, test.battery.start, (null))
> [D1] entering nut_snmp_set(1.3.6.1.2.1.33.1.7.1.0, i, 0)
> [knet-olomoucka-1] nut_snmp_set: can't set 1.3.6.1.2.1.33.1.7.1.0: Error
> in packet: (badValue) The value given has the wrong type or length.
> [D1] su_setOID: cannot execute command 'test.battery.start'
>
> [D2] entering main_instcmd(test.battery.start.quick, (null)) for
> [knet-olomoucka-1] on socket 6
> [D2] shared main_instcmd() does not handle command
> test.battery.start.quick, proceeding to driver-specific handler
> [D2] entering su_setOID(instcmd, test.battery.start.quick, (null))
> [D1] entering nut_snmp_set(1.3.6.1.2.1.33.1.7.1.0, i, 0)
> [knet-olomoucka-1] nut_snmp_set: can't set 1.3.6.1.2.1.33.1.7.1.0: Error
> in packet: (badValue) The value given has the wrong type or length.
> [D1] su_setOID: cannot execute command 'test.battery. start. quick'
>
> [D2] entering main_instcmd(test.battery.start.deep, (null)) for
> [knet-olomoucka-1] on socket 6
> [D2] shared main_instcmd() does not handle command
> test.battery.start.deep, proceeding to driver-specific handler
> [D2] entering su_setOID(instcmd, test.battery.start.deep, (null))
> [D1] entering nut_snmp_set(1.3.6.1.2.1.33.1.7.1.0, i, 0)
> [knet-olomoucka-1] nut_snmp_set: can't set 1.3.6.1.2.1.33.1.7.1.0: Error
> in packet: (badValue) The value given has the wrong type or length.
> [D1] su_setOID: cannot execute command 'test.battery. start.deep'
> ----------------------------
>
> Looking at these, I am convinced that this is an issue with NUT's
> implementation of the RFC, even more so after looking over the source code.
> Please, bear with me here:
> Note RFC-1628, page 22-23 <https://www.rfc-editor.org/rfc/rfc1628#page-22>,
> upsWellKnownTests.
>
>     ----------------------------
> *upsWellKnownTests     *OBJECT IDENTIFIER ::= {* upsTest 7 *}
>
> upsTestNoTestsInitiated OBJECT-IDENTITY
>        STATUS     current
>        DESCRIPTION
>                "No tests have been initiated and no test is in
>                progress."
>        ::= { upsWellKnownTests  *1* }
>
>    upsTestAbortTestInProgress OBJECT-IDENTITY
>        STATUS     current
>
>        DESCRIPTION
>                "The test in progress is to be aborted / the test in
>                progress was aborted."
>        ::= { upsWellKnownTests  *2 *}
>
>    upsTestGeneralSystemsTest OBJECT-IDENTITY
>        STATUS     current
>        DESCRIPTION
>                "The manufacturer's standard test of UPS device
>                systems."
>        ::= { upsWellKnownTests  *3* }
>
>    upsTestQuickBatteryTest OBJECT-IDENTITY
>        STATUS     current
>        DESCRIPTION
>                "A test that is sufficient to determine if the battery
>                needs replacement."
>        ::= { upsWellKnownTests  *4* }
>
>    upsTestDeepBatteryCalibration OBJECT-IDENTITY
>        STATUS     current
>        DESCRIPTION
>                "The system is placed on battery to a discharge level,
>                set by the manufacturer, sufficient to determine
>                battery replacement and battery run-time with a high
>                degree of confidence.  WARNING:  this test will leave
>                the battery in a low charge state and will require
>                time for recharging to a level sufficient to provide
>                normal battery duration for the protected load."
>        ::= { upsWellKnownTests  5 }
>
> ----------------------------
>
> Compare this with the lines 248-253 of ietf-mib.c:
> <https://github.com/networkupstools/nut/blob/master/drivers/ietf-mib.c>
> ----------------------------
> 249 snmp_info_default(*"ups.status", ST_FLAG_STRING, SU_INFOSIZE,
> IETF_OID_UPS_MIB "7.1.0"*, "", 0, ietf_test_active_info), /* upsTestId */
> 250 snmp_info_default(*"test.battery.stop", 0, 1, IETF_OID_UPS_MIB
> "7.1.0", "0", SU_TYPE_CMD, NULL*), /* upsTestAbortTestInProgress */
> 251 snmp_info_default(*"test.battery.start", 0, 1, IETF_OID_UPS_MIB
> "7.1.0", "0", SU_TYPE_CMD, NULL*), /* upsTestGeneralSystemsTest */
> 252 snmp_info_default("*test.battery.start.quick", 0, 1, IETF_OID_UPS_MIB
> "7.1.0", "0", SU_TYPE_CMD, NULL*), /* upsTestQuickBatteryTest */
> 253 snmp_info_default("*test.battery.start.deep", 0, 1, IETF_OID_UPS_MIB
> "7.1.0", "0", SU_TYPE_CMD, NULL*), /* upsTestDeepBatteryCalibration */
> ----------------------------
> Note that the same code is used for each line, omitting the final number
> of the sequence. - Same as within the debug text. ietf-mib.c is lacking the
> expected enumeration of OBJECT IDENTIFIER in upsWellKnownTests.
> Unless you request me not to, I will be happy to open an issue on your
> github.
>
> P.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20260519/f8226e47/attachment-0001.htm>


More information about the Nut-upsuser mailing list