SNMP help please?

[SimonGoodson]

Hello,

I'm brand new to SNMP although I have used LabVIEW a couple of times over the last few years. Right now I am developing an application to test power supplies. We are using a Dell G756N switched PDU to power each supply. I've tried a couple of approaches to controlling it, and SNMP is the most promising so far. During my research I came across ManageEngine's free MibBrowser and I was able to find the latest MIB in Dell's firmware download here. I have been able to communicate with the PDU and turn outlets on and off so far, but I really need to integrate the PDU control into the LabVIEW application to automate the testing. I came accross Mark Yedinak's SNMP communication library and his APC PDU examples, the latest of which I have found are in this thread.

I tried to make a VI to test the communication in LabVIEW using the OID I got from MibBrowser, but it returns an error code of 2, noSuchName. The PDU is set to use v1 of SNMP and both the public and private communities have write+ access. I have tried it with and without the leading period, but without any success. I am using LabVIEW 2013 64-bit. Could someone please look at the information below and see what I might be doing wrong or what direction to take to troubleshoot it?

Thanks,

Simon

MIB Object ID:

.iso.org.dod.internet.private.enterprises.dell.pdu.pdusub.hardware.rPDU.rPDUOutlet.rPDUOutletSwitched.rPDUOutletSwitchedControlTable.rPDUOutletSwitchedControlEntry.rPDUOutletSwitchedControlCmd

.1.3.6.1.4.1.674.10903.200.2.200.130.1.4.1.4.1 : {1 or 2}

I added the .1 at the end for the index of the first outlet, and the 1 variable is instant on, while the 2 is instant off

Picture

VI:

Front Panel:

Wiring:

Link to SNMP Communications and APC_PDU.zip examples:

http://forums.ni.com/t5/LabVIEW/APC-UPS-with-desktop/m-p/2431528/highlight/true#M749059

For some reason I can't get the actual VI to attach itself. The MIB is in the archive too. Its in my dropbox here:

https://dl.dropboxusercontent.com/u/10871313/Power%20Supply%20Testing.zip

Thanks again

[SimonGoodson]

Anybody?

[PhillipBrooks]

In this thread, the originator of the SNMP lib mentioned that if you see NoSuchName in the error_sting, your OID is not defined correctly.

[SimonGoodson]

Hi Pillip,

Thank you for replying. I'm not sure how to troubleshoot that. Do you have any ideas? I'm only an occasional LabVIEW user and brand new to SNMP. I'm willing to do the work, I'm just not sure what it is.

I'm using the same OID that is listed in MIB Browser, and MIB Browser is able to successfully communicate. Is there another tool that translates better? I've seen references to MIBs that aren't standard, and maybe that is where the disconnect is happening, but I don't know how to identify a non-standard MIB.

Thanks,

Simon

[PhillipBrooks]

You might try loading wireshark to capture and parse the actual UDP message sent by the mibbrowser program.

There may be some index or instance component you need to set/change in your OID.

Make the LabVIEW OID match the working application's message and Bobs your uncle

[SimonGoodson]

Thanks Phillip, I'll give that a shot.

Regards,

Simon

[SimonGoodson]

I've switched to LV2014 32-bit and installed Wireshark. I'm still getting the same "noSuchName" error, but using wireshark it lists the packet sent by SNMP as a "Malformed Packet". I'm guessing that somewhere in the depths of the VIs something is wrong, but I'm not sure what. I created a small program to save the output of the MIB Walk VI and that ran fine. The OID that I am sending is listed along with the correct type of variable.

The Wireshark traces and MIB Walk are included.

Thanks,
Simon

[PhillipBrooks]

I don't have a lot of time to look at it, but I compared the wireshark captures and it looks like the problem is in the OID.

There is this post where someone else who had a OID containing a large value had some problems, and Mark had provided a fix.

From what I can tell in the date/tiome stamps of the files, the LLB you have is later than the updated one that Mark provided to fix the problem.

My only suggestion would be to try the LLB in the link above and see if that solves the problem.

http://forums.ni.com/t5/LabVIEW/Help-with-SNMP/m-p/1328623#M541584

[SimonGoodson]

I appreciate all the time you have taken, thank you. At your suggestion, I tried the older SNMP library, but I got the same results.

Could you tell me how you analyzed the packets from Wireshark and determined it was the OID, or point me to some reading? I was going to translate the hex to U8 and see if they match what should be coming out of the SNMP vi's. Is that correct?

Also, as I said before, I did an MIB Walk that worked completely and wireshark didn't list any malformed packets during the run. After comparing the sub-vi trees of the Walk and the Set program, here are the vi's that are exclusive to the set program, and the ones that are shared with the MIB Walk:

Exclusive vi's:

Set snmp Item(s).vi

SNMP Set Request.vi

SNMP Build Set Request Packet.vi

SNMP Build Set Sequence.vi

SNMP String to Type.vi

SNMP String to Smallest Int Array.vi

SNMP ASCII Hex String To Binary String.vi

Shared vi's:

SNMP Get Random Port Number.vi

SNMP Open Port.vi
SNMP Build OID.vi
SNMP Encode SubID.vi
Sequence length convert.vi
SNMP Get Response.vi
SNMP Parse SNMP Packet.vi

Parse SNMP Packet Header.vi
Parse SNMP Tuple.vi
byte array to number.vi
SNMP Type to String.vi
SNMP Byte Array to Int32.vi
SNMP OID to String.vi
SNMP Parse Sequence Data.vi
SNMP Type Num to Type String.vi
SNMP Close Port.vi

Thanks,

Simon

[SimonGoodson]

I guess I'm following up my own post, but here is what I have found today:

The references I found and used for SNMP packet structure/encoding:

SNMP Programmer's Reference - SetRequest PDU

SNMP: Simple? Network Management Protocol (especially the graphic at the bottom)

And I figured out you could click on the different parts of the UDP packets in Wireshark to get some further explanation of what they represent. Awesome tool, thanks for pointing it out!

Comparing the "Outlet 1 Off" packet from MIBBrowser (MB) and my LabVIEW (LV) program:

• UDP packet length on MB is 62, is 61 on LV, definitely a mismatch.
• Both SNMP portions start at the same offset
• SNMP version looks good in both packets
• Community string in both packets looks good
• both packets define the packet as a set request, although the LV on is one hex shorter
• Set request ID on MB is 2, on LV is -7295. Seems strange, bears further investigation.
• The Varbind List Type looks okay. Note that it starts one place later in the LV packet than the MB packet due to the size of the request-id in the LV packet.
• The Varbind Type and length is correct in both packets (30 1a)
• The OID is correct in both packets (type:06, length:15, value (2b 06 01 04 01 85 22 d5 17 81 48 02 81 48 81 02 01 04 01 04 01)
• The value in the MB is correct (type: 02 [integer32] lenth:01 value: 02), but the LV packet only has one hex: 00

Things to investigate:

• The request id: Is a negative number valid? Does that particular value mean anything? Generated by the accessible vi's or is it a product of the LabVIEW UDP implementation, or the underlying OS?
• Why is the value conversion incorrect? Is it in the VI or truncated later?

Knocking off a bit early today to take care of other business. Further updates Monday.

-Simon