Hi,
we do have APC Smart-UPS each with AP9617 and latest FW.
As we found out we are not able to shutdown the UPS via SNMP - neither
immediately nor delayed. And we cannot set values, but we can read them
correctly. So it seems as we are not able to write to the UPS and get back
strange error
Update: I can set the battery change date. ;-)
But nothing else...
Hi,
we do have APC Smart-UPS each with AP9617 and latest FW.
As we found out we are not able to shutdown the UPS via SNMP - neither immediately nor delayed. And we cannot set values, but we can read them correctly. So it se
Another update:
Did this manually: snmpset -c private -v 1 10.100.200.30 1.3.6.1.4.1.318.1.1.1.5.2.6.0 i 90
And it worked! But using nut it does not work with the error below.
Update: I can set the battery change date. ;-)
But nothing else...
Hi,
we do have APC Smart-UPS each with
Ok, and here comes the tcp dump:
snmpset -c private -v 1 10.100.200.30 1.3.6.1.4.1.318.1.1.1.5.2.6.0 i 90 makes this:
14:01:02.725830 IP 10.100.200.1.40893 > 10.100.200.30.161: C=private SetRequest(35) .1.3.6.1.4.1.318.1.1.1.5.2.6.0=90
14:01:02.759972 IP 10.100.200.30.161 > 10.100.200.1.4
Here comes the output:
root@abex:~# /lib/nut/snmp-ups - -a apc10001 -k
Network UPS Tools - Generic SNMP UPS driver 0.66 (2.6.4)
0.00 debug level is '4'
0.000446 SNMP UPS driver : entering upsdrv_initups()
0.000471 SNMP UPS driver : entering nut_snmp_init(snmp-ups)
Sorry, forgot this, cause I was still with the 90/"90" problem...
user = nut
[apc10001]
driver = snmp-ups
port = 10.100.200.30
snmp_version = v1
mibs = apcc
pollfreq = 15
desc = "APC Smart-UPS 1000I (30)"
community=private
Here comes the output:
root@abex:
And this is the tcpdump output from the snmp-ups command:
15:22:22.063065 IP 10.100.200.1.43571 > 10.100.200.30.161: C=private GetRequest(34) .1.3.6.1.4.1.318.1.1.1.1.1.1.0
15:22:22.080085 IP 10.100.200.30.161 > 10.100.200.1.43571: C=private GetResponse(52) .1.3.6.1.4.1.318.1.1.1.1.1.1.0="Sm
Well, did file two bugs. I believe that I might have found two...
I will take the source package and fix #708397 myself. I will wait for the maintainer what he says about the other one.
I will post the changed apc-mib.c here. Ok? Or shall I send it to someone else?
-lutzn
Debian Bug #7
I changed one line only:
line 1463 in snmp-ups.c:
from: if (su_info_p->info_flags & ST_FLAG_STRING) {
to: if (su_info_p->flags & SU_TYPE_STRING) {
Can anyone please verify!
Because if it is true what I did then I believe that setting values might not have worked for any snmp u
Ok, now I saw that it is far from complete. nut does only support snmp types 's' and 'i' when writing. nut does not support type 't'. So no timeticks such as delays can be set on an AP9617. Maybe other cards do no type checking...
This means snmp-ups.c and apc-mib.c need to be changed. And m
Regarding Debian Bug#708397: nut: APC SNMP set value does not work (wrong mib type declarations)
Here are the patches that work for APC Smart-UPS with APC AP9617 / SNMP.
After applying the patches the UPS accepts and holds the values that are written to the UPS (string, int and tick values)
Hi,
on Debian and maybe other systems one of the last steps the system's shutdown
procedure does is to shut down the UPS via upsdrvctl to turn off the machine
and to conserve power. But this is a place where network communications via
SNMP is not possible anymore because the interfaces are d
>> In the shutdown procedure that is initiated via shutdown -h +0 is there any
>> point where the shutdown could be interrupted due to power coming back or is
>> this the final command that always results in the machine being brought
>> down? I looked through the scripts that are involved and fo
13 matches
Mail list logo
