Full configuration poll for Panduit G5 PDU

[gkaudewitz]

Hello together,

my current version of netxms is 5.2.8 on debian, I'm currently migrating my monitoring to.

I had implemented SNMP-requests to panduit G5 PDUs some time ago in a netxms-version 4.x and it worked fine even with some updates of netxms to current version.
Currently I did a firewareupdate on that PDU and afterwards a full configuration poll for the corresponding node. Within that poll netxms was not able checking running SNMP agent and doing a capability-update. (Testing it with a PDU that had an other firmwareversion same thing happend.) From that time on it got more strange:

• Using instance-poll with a DCI worked fine and all instances are created
• Created DCIs got an error while polling values
• Making a nxsnmpget request from server with needed SNMP-parameters with OID from one of the created DCIs worked fine and I got back the value for that OID

This bahavor is the same for SNMP v2c and v3. To simplyfy the problem I deactivated all encryption staff from v3.

As I have an old installation from netxms (Version 2.0.5) I added a node there and it all worked fine! (detection of node capabilities and DCI-Requests)

I do not know how to get it working on version 5.2.8 I'm currently migrating to.

Best regards

Georg

[Filipp Sudanov]

Can you do a tcpdump capture with this command:
tcpdump -s 0 -w snmp-exchange.pcap host = DEVICE_IP

We are interested in querying one problematic OID - first from nxsnmpget and then from NetXMS. Command will produce a file that can be opened using Wireshark. Please share the file.

[gkaudewitz]

I captured data for two situations:
1.) Configuration poll (full poll)
2.) nxsnmpget for special OID

Capturing a DCI-Poll (Forced Poll) gave me an empty file. I think the poll was  not done, because netxms was not able to detect SNMP capabilities at configuration poll.

@Filipp: I will send You a downloadlink as PM

[Filipp Sudanov]

Yes, if isSNMP capability is “No”, netxms might not send snmp requests to node. Please do packet capture while running full confuguration poll for that node.

[gkaudewitz]

I did the first request out of capture for full configuration poll and got following results:

nxsnmpget -v 3 -u xxxxx IP 1.3.6.1.2.1.1.2.0
1.3.6.1.2.1.1.2.0 [OBJECT IDENTIFIER]: 1.3.6.1.4.1.19536.10.1
// Value seems to be OK as the PDU comes from Panduit

nxsnmpget -v 3 -u xxxxx IP 1.3.6.1.2.1.1.1.0
1.3.6.1.2.1.1.1.0 [STRING]:  SN:PDU Metered PN:Device Model:P30D05M Rating:346-415V, 16A, 11.0kVA, 50/60Hz
// Value is OK

nxsnmpget -v 3 -u xxxxx IP 1.3.6.1.4.1.35160.1.1.0
1.3.6.1.4.1.35160.1.1.0 [NULL]:
// I don't know why this OID is requested it seems that it has nothing to do with Panduit

nxsnmpget -v 3 -u xxxxx IP 1.3.6.1.6.3.15.1.1.4.0
1.3.6.1.6.3.15.1.1.4.0 [NULL]:
// This is the OID from the report

it seems that the next calls to the device are done with global configured authtenticationparameters as they are encrypted. Within nodeconfiguration I have configured authentication parameters for that host.

nxsnmpget -v 3 -u xxxxx IP 1.3.6.1.2.1.1.3.0
1.3.6.1.2.1.1.3.0 [TIMETICKS]: 866125100
// Result for this request returned that is done as the last SNMP-Request in packet-capture

So it seems to be odd why the PDU is nor recognized as SNMP capable...

Best regards

Georg

[Filipp Sudanov]

Since the node works with snmp v2 I'd suggest to use that now to avoid encryption stuff.

For comparison we still need two captures - one from nxsnmpget, the other - when NetXMS is doing  configuration poll of that node.

[gkaudewitz]

It seems that SNMP has some problems on the PDU when it receives requests for OIDs that are not fully implemented.
I changed the snmp-Testoid to 1.3.6.1.4.1.19536.10.1 using the Custom Attribute "snmp.testoid".

Capabilities detection and DCIs for temperature using SNMPv2 and SNMPv3 include alarm generation now work as expected. Now implementing DCIs for current amps and volts and alarming for this.