Using sample application "snmpget" to retrieve the cdpCacheAddress (1.3.6.1.4.1.9.9.23.1.2.1.1.4), the return result is not correct. The return type is CiscoNetworkAddress which is OctetString and in my test case it is 4 octets IP address. The test on two Cisco devices always returned the same results in the first three octets. The last octets appears to match the 4th octet of the device's IP address.
For example:
using the snmpget sample application with the following command line argument:
-v=2 -c=public 192.168.254.11 .1.3.6.1.4.1.9.9.23.1.2.1.1.4.10003.1
The output received was as follow:
Variable: Id: .1.3.6.1.4.1.9.9.23.1.2.1.1.4.10003.1; Data: ???
convert the Data to string: 63.63.63.11
using the snmpget sample application with the following command line argument:
-v=2 -c=public 192.168.254.12 .1.3.6.1.4.1.9.9.23.1.2.1.1.4.8.2
The output received was as follow:
Variable: Id: .1.3.6.1.4.1.9.9.23.1.2.1.1.4.8.2; Data: ???
convert the Data to string: 63.63.63.12
The code snippet from sample application snmpget:
For Each variable As Variable In Messenger.[Get](version, receiver, New OctetString(community), vList, timeout)
Console.WriteLine(variable)
Next
I tried converting the returned result in different way, but I suspect the result from the call to Messenger.[Get] was wrong to begin with.
Information on cdpCacheAddress:
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=.1.3.6.1.4.1.9.9.23.1.2.1.1.4.&translate=Translate&submitValue=SUBMIT&submitClicked=true
Comments: You are right about the complex data type that requires further processing. By checking the cdpNeighborAddressType, implementation may decide on the processing logic. In my case, the return type is type=1 indicating that it is 4 octet IP. What I don't get was that the content of the return "variable" from Messenger.[Get] were the same first three octet as 63 from different devices. Also, I have verified that the device's return data are good by using a mib browser. Any suggestions?
For example:
using the snmpget sample application with the following command line argument:
-v=2 -c=public 192.168.254.11 .1.3.6.1.4.1.9.9.23.1.2.1.1.4.10003.1
The output received was as follow:
Variable: Id: .1.3.6.1.4.1.9.9.23.1.2.1.1.4.10003.1; Data: ???
convert the Data to string: 63.63.63.11
using the snmpget sample application with the following command line argument:
-v=2 -c=public 192.168.254.12 .1.3.6.1.4.1.9.9.23.1.2.1.1.4.8.2
The output received was as follow:
Variable: Id: .1.3.6.1.4.1.9.9.23.1.2.1.1.4.8.2; Data: ???
convert the Data to string: 63.63.63.12
The code snippet from sample application snmpget:
For Each variable As Variable In Messenger.[Get](version, receiver, New OctetString(community), vList, timeout)
Console.WriteLine(variable)
Next
I tried converting the returned result in different way, but I suspect the result from the call to Messenger.[Get] was wrong to begin with.
Information on cdpCacheAddress:
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=.1.3.6.1.4.1.9.9.23.1.2.1.1.4.&translate=Translate&submitValue=SUBMIT&submitClicked=true
Comments: You are right about the complex data type that requires further processing. By checking the cdpNeighborAddressType, implementation may decide on the processing logic. In my case, the return type is type=1 indicating that it is 4 octet IP. What I don't get was that the content of the return "variable" from Messenger.[Get] were the same first three octet as 63 from different devices. Also, I have verified that the device's return data are good by using a mib browser. Any suggestions?