SNMP_UDF for SNMPv1 and SNMPv2c

[enaiman]

@GSM - thank you very much for providing the data

After some debugging and headaches I found where the error was

Al I can say was - WOW. What I found was completely unexpected; the error was in a line, not in the UDF but in the test script:

Global $result

It took me some time to find that this global variable was changing the result of the _encode function because there was a variable inside that function having the same name

Embarasing, a little weird but perfectly normal. I know it was my fault but such a case is a nightmare to debug.

I have fixed the UDF (changed that variable name to $Op_Result and that should fix things.

I'll upload the new version shortly (1.4.1.)

Thank you for your help

[AleksanderWalesa]

Hi,

I've got some problems with BULK (A5) function - nothing is recieved. I'm trying to query my switch for interfaces.

SNMP WALK returns: GbE_1 for OID: 1.3.6.1.2.1.2.2.1.2.1 where the last .1 changes for next interface.

from this UDF I'm not recieving any data. Below is my code (modified example):

;GetBulk (ifTable - ifDescr) 32 values returned

Global $SNMP_OID = "1.3.6.1.2.1.2.2.1.2"

$SNMP_Command = _SNMPBuildPacket($SNMP_OID, $SNMP_Community,$SNMP_Version, $SNMP_ReqID, "A5", "20")

ConsoleWrite($SNMP_Command &@CRLF)

UDPSend($Socket, $SNMP_Command)

_StartListener()

sleep (200)

_ArrayDisplay($SNMP_Util, "GetBulk")

In the console I'm getting:

0x302802010104067075626C6963A51B02020001020100020120300F300D06092B06010201020201020500

0x302802010104067075626C6963A51B02020001020100020120300F300D06092B06010201020201020500

and array windows is not showing, but it looks like script is still running (I was waiting for 5 min).

Could anyone help?

Regards,

Aleksander

[enaiman]

I've noticed this strange behaviour - it seems that it will return values for a certain number of requests but not for others.

I'll have to look into what is happening and maybe re-write the whole "Bulk" part in the UDF.

I can't offer a date to post the fixed UDF but I'll try to do it as soon as I can.

Until then, try different values instead of that "20" - and if nothing is returned withing 15-20 seconds (maximum) you can close your script because it is hanged at some point.

[AleksanderWalesa]

Hi,

Thanks

I've found one more bug? oid: 1.3.6.1.2.1.2.1.0 (number of interfaces) is returning null with query with all methods (GetRequest, GetNext, GetBulk). With other tools (snmpwalk) it is ok so it's something wrong with UDF.

I'm building with autoit some tools for my monitoring system ("The Dude" from Mikrotik) and this UDF is GREAT!!!!

Best regards,

Aleksander

[enaiman]

I am re-writing the UDF, so far the packet generation is done; I hope by the end of the day to have packet decoding ready.

Keep an eye on the topic

[enaiman]

Well, managed to finish re-writing the UDF just in time for the weekend

However, I didn't have time to test it too much, tested the GetBulk (A5) for several values and it was OK, and tested reading an unique value (A0).

There might be some bugs but I hope the users will be able to point them to me

Enjoy

[AleksanderWalesa]

I'm starting tests right now

Best Regards,

Aleksander

[AleksanderWalesa]

First try: missing in 1.5 UDF

Func _WriteArrayValues(ByRef $ArrRet, $idx, $val0, $val1, $val2 = "") ;write entries in returned arrays

$ArrRet[$idx][0] = $val0

$ArrRet[$idx][1] = $val1

If $val2 <> "" Then $ArrRet[$idx][2] = $val2

EndFunc ;==>_WriteArrayValues

Beside this A0 is now returning correct values

I'll test it today

Aleksander

[AleksanderWalesa]

One more bug.

GETBULK: 1.3.6.1.2.1.4.20.1.1 shoud return only IP addreses but it returns whole class 1.3.6.1.2.1.4.20.1.*

Aleksander

Edited October 1, 2010 by AleksanderWalesa

[enaiman]

@AleksanderWalesa

Thank you very much for your findings, I could have sweared that I didn't let out that function from UDF but ... it wasn't there.

UDF fixed now.

Regarding the second question:

I have tested it this morning - you were trying to querry ipAdEntAddr with a GetBulk. My switches displays usually two IP addresses in this section (the switch IP and the management interface IP).

I am pretty sure that you didn't adjust $GetBulk from _SNMPBuildPacket and you left it with the default value which is 32(hex)

If you use $GetBulk = "02" you will see that only these two IPs are returned.

This variable ($GetBulk) tells the querried device how many OIDs to return; it will be up to you to adjust it in order to get the best results

[ptrex]

@enaiman

Great work !

It's been some time since I worked with SNMP but I will definitely give it a try again.

Rgds

ptrex

[AleksanderWalesa]

@enaiman

Thanks for update. Don't get me wrong but I thought that it should work a little bit different (GetBulk) Of course there are some OID's where you can get total number of items and then query with UDF's GetBulk for the rest of data (for example total number of interfaces - 1.3.6.1.2.1.1.7.0 and then query with getbulk with known number of interfaces) but there are some of them where total is unknown. From SNMPv2c spec. as I remember GetBulk procedure should work the way, that it should query for next data (OID) and when the next returned OID is out of scope it should stop. Of course I may be wrong and I should check in returned data for my values based on returned OID's

Best Regards,

Aleksander

[enaiman]

@ptrex

Thank you glad to see you following this

@AleksanderWalesa

I'm not sure what SNMPv2 would do in a case of "GetBulk", it will stop or not by default.

I'm not sure either how other SNMP application deal with GetBulk; it might be very well repeated GetNext querries until the OID returned is out of the original scope (which in entirely possible using this UDF) ... just speculating.

What I wanted to accomplish with this UDF was to give the community the ability to deal with SNMP on a basic level - it was never intended to be something similar in functionalities with other applications or to "do everything by the book".

I am pretty sure that you can use this in the way you want - you just need a logic a bit more complicated. It is the same thing as all programing languages, they give you the "bricks" - you need to lay them down; how you do that is entirely your choice.

For this cases where you say that the number of OID's is "unknown"; you are definitely aware that most of SNMP application have a MIB database, so that number is quite "known" to them Regarding this: I'm afraid my UDF won't go there, I am not ready for such a commitment (to make my UDF work with MIBs) and it is simply a too big amount of work. On the other hand that is hardly related to SNMP, is more like a database manipulation.

At the moment I am pretty sure that my work is done on this; I will be around to fix any glitches and to offer support when needed but I don't see any additions in the near future. "If" at some point I will feel like adding anything - I will update the thread.

[ryanrainy]

@enaiman

what a great UDF! Thank you !!!

i'm rokkie for AutoIt and SNMP ,i have some problems ....

i want get the Ip Address of windows 2003 PC,and i used the get-request and OID=1.3.6.1.2.1.4.20.1.1 ,but the results displayed "0",and the Error Code is 02 ,what 's the data type mean??

and if i want to get the CPU state and CPU Information of Windows 2003 ,How can i do ??

BEST REGARDS,

RYAN~

[enaiman]

@ryanrainy

Error 02 means "no such name" - the OID you're trying to read does not exist.

I understand you are trying to get the IP address; the problem is: you cannot get the result using "A0"= GetRequest or "A1"= GetNext. You need to read the whole table under 1.3.6.1.2.1.4.20.1 using "A5"= Get Bulk and ask for 5 results to be returned. You will get an array of results and one of them is the IP address you are looking for.

Use this line in my example script and you'll see that usually the IP Address is the first on the table.

Global $SNMP_OID = "1.3.6.1.2.1.4.20.1"
$SNMP_Command = _SNMPBuildPacket($SNMP_OID, $SNMP_Community,$SNMP_Version, $SNMP_ReqID, "A5", "05")

Also, you can see that the actual "instance" (the part after "1.3.6.1.2.1.4.20.1.1.") is exactly the IP address; that's why you were getting error 02.

To get CPU info, it depends on the manufacturer because every one of them will have it's own group of OID's. I'm afraid it is up to you to find where this info is to be found. Google it and I'm pretty sure you will find it.

[Sjee]

@enaiman

Hi,

I think I found a small problem; GetRequest (A0) is not working for an for an array of OID's.

This works:

$SNMP_OID= "1.3.6.1.4.1.26565.1.1.3.2.0" ;

$SNMP_Command = _SNMPBuildPacket($SNMP_OID, $SNMP_Community,$SNMP_Version, $SNMP_ReqID, "A0")

This doesn't :

$SNMP_OID[0]= "1.3.6.1.4.1.26565.1.1.3.2.0" ;

$SNMP_Command = _SNMPBuildPacket($SNMP_OID, $SNMP_Community,$SNMP_Version, $SNMP_ReqID, "A0")

[enaiman]

@sjee

Thank you very much for finding that.

It looks like last time I have rewriten the code, I completely forgot about that - the part dealing with OID arrays got moved to the Get_Bulk area where it is useless. I will need a little bit of time to fix that.

Please check this thread back late today or by Monday, I'll do my best to fix this - I will update the first post.

[enaiman]

I have decided to remove support for OID Arrays because there wasn't much value in having them - just making the UDF more difficult to debug.

Sorry for any inconvenience.

New files uploaded to reflect the minor version change.

[Sjee]

@enaiman

You're quick! For me the OID array's are very useful. The reason is that if I send a number of single OID's there is a small delay between every request which causes the data to run out of sync. And since I repeat the request every +/- 500ms there isn't enough time to use single OID's.

But for now the older version of your UDF still does the trick for me

Thanks for the great work!

[enaiman]

@Sjee

There is an alternative for that. If the OID's are in sequence and if the device is supporting SNMPv2c you can use GET_BULK to return up to 50 OID's.

Using an array was useful if the OID's were not in sequence.

Well, when the time will allow me to work a bit on this, I might put the arrays back; we'll see.

Just have a play with GET_BULK and see how it's doing.