> What files would make the most sense to check?
I'd say the killpower flag file sounds most suspicious for this role. In some distros it may be in /etc and there was an init-script to delete it early in boot. Regarding the "pile of ASNs", I wonder if David could (get someone to) produce a custom MIB mapping source for https://github.com/networkupstools/nut/blob/master/drivers/snmp-ups.c#R92 to integrate with Tripplite's over SNMP better than via IETF default tables... Jim On Fri, Aug 20, 2021, 08:01 Aaron Stewart <aaron.stew...@baymaterials.com> wrote: > When connecting to the TrippLite unit with SNMP, via: > > # cat /etc/nut/ups.conf > .... > maxretry = 3 > [scotty] > driver = snmp-ups > port = poweralert-061036722874.baymaterials.local > snmp_version = v2c > mibs = ietf > community = tripplite > > # /lib/nut/snmp-ups -a scotty > Network UPS Tools - Generic SNMP UPS driver 0.97 (2.7.4) > Duplicate driver instance detected! Terminating other driver! > Detected SU2200RTXLCD2U on host poweralert-061036722874.baymaterials.local > (mib: ietf 1.5) > [scotty] unhandled ASN 0x80 received from 1.3.6.1.2.1.33.1.2.6.0 > [scotty] unhandled ASN 0x80 received from 1.3.6.1.2.1.33.1.2.7.0 > [scotty] unhandled ASN 0x81 received from 1.3.6.1.2.1.33.1.3.3.1.4.1 > [scotty] unhandled ASN 0x81 received from 1.3.6.1.2.1.33.1.3.3.1.5.1 > [scotty] unhandled ASN 0x81 received from 1.3.6.1.2.1.33.1.5.3.1.3.1 > [scotty] unhandled ASN 0x81 received from 1.3.6.1.2.1.33.1.5.3.1.4.1 > [scotty] unhandled ASN 0x80 received from 1.3.6.1.2.1.33.1.6.3.8 > [scotty] unhandled ASN 0x80 received from 1.3.6.1.2.1.33.1.7.1.0 > [scotty] unhandled ASN 0x80 received from 1.3.6.1.2.1.33.1.9.6.0 > [scotty] unhandled ASN 0x80 received from 1.3.6.1.2.1.33.1.9.9.0 > [scotty] unhandled ASN 0x80 received from 1.3.6.1.2.1.33.1.9.10.0 > > > The pile of unhandled ASNs is what had me worried about relying on the > SNMP connection in the first place... > > > > IT & Office Manager > P Please consider the environment before printing this e-mail. > > > ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ > Disclaimer > > > This message may contain confidential information and is intended only > for the individual(s) or entities named above. Any review, retransmission, > dissemination, distribution, copying or other use of this information by > persons or entities other than the intended recipient is prohibited. Please > notify the sender immediately by e‑mail if you have received this e‑mail by > mistake and delete this e‑mail from any and all computers it may be stored > on. No liability is accepted for any errors or omissions in the contents > of this message which arise as a result of e‑mail transmission. If > verification is required, please request a hard‑copy version. No liability > is accepted for any damage caused by any virus transmitted by this e‑mail. > The recipient should check this e‑mail and any attachments for the presence > of viruses. > ------------------------------ > *From:* David Zomaya <david_zom...@tripplite.com> > *Sent:* Wednesday, August 18, 2021 19:57 > *To:* Aaron Stewart <aaron.stew...@baymaterials.com>; > nut-upsuser@alioth-lists.debian.net <nut-upsuser@alioth-lists.debian.net> > *Subject:* Re: Tripp-Lite USB "REMOTE SHUTDOWN" > > Warning: This email originated from outside of Straumann’s trusted e-mail > environment. Do not click any links or open attachments unless you > recognize the sender and have confidence the content is safe. > > > > > The issue showed up with shipping firmware but persists after I loaded > 20.0.1.118. > > Ah, you're referring to the WEBCARDLX firmware (i.e. the management card > installed in the UPS). There's also a UPS firmware that isn't generally > updated in the field I thought you were referring to (that displays on the > LCD and is reported via the WEBCARDLX too, probably ends in 16 on that > unit). > That firmware should have no impact on this issue, but thank you for > clarifying! > > > Hardware S/N is 3104JLCPS795200451. > > We should get a support ticket open for you like we did with another user. > Can you shoot me a direct email (off-list) with your contact information > (shipping address and contact number)? I do plan to give the mailing list > an update when/if I get to root cause, but I don't have that yet. In the > interim, I'd like to see what we can do for you (or anyone else that runs > into this... strangely it does not occur on most/all units). > > > Is there any hope for using it over SNMP with NUT instead? > > It should work. The WEBCARDLX supports the RFC1628 "UPS MIB" and that is > what the ITEF driver uses. Generally, our support for the RFC1628 MIB > works in all recent versions. > I can set up some tests later this week or early next week to demonstrate, > but feel free to shoot over the specifics of the errors you see and your > config if you'd like. > > > Thank you, > David Zomaya > Tripp Lite > david_zom...@tripplite.com > > ________________________________ > This message is for the addressee's use only. It may contain confidential > information. If you receive this message in error, please delete it and > notify the sender. Tripp Lite disclaims all warranties and liabilities, and > assumes no responsibility for viruses which may infect an email sent to you > from Tripp Lite and which damage your electronic systems or information. It > is your responsibility to maintain virus detection systems to prevent > damage to your electronic systems and information. > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser