When trying to GetTable() with oid: 1.3.6.1.2.1.31.1.1.1.1 on a cisco WS-C3560G-48PS-S, I get an error stating that type 65 is not recognized.

I looked up type 65 (0x41) or Counter32 and found that it is basically an unsigned int that increases monotonically.

Adding the following case to DecodeSequence() seems to give me correct values, but I don't think it is a "correct" solution. I know very little about BER
case Counter32:
decodedValue, err := DecodeInteger(berValue)
if err != nil {
return nil, err
}
result = append(result, decodedValue)

Thank's for the great library!

Hi there,

In looking at the code, I see that the calls to Poll from Get in snmp.go use a 500ms fixed timeout. Has this been found to be a good value, or would it make sense to pass the users provided timeout in NewWapSNMP?

Thanks,
Nathan

In our SNMP server we using WSDL file for description all methods and resources.
We store this file is local.
Can I use local WSDL file for generation methods our SNMP server?

Hello,

Could you specify under what license the code is being released?

Great work by the way!

Hello,

The library doesn't seem to support 64-bit counters such as those in the ifXTable: http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.2.1.31.1.1.1

I have taken a look at DecodeSequence in ber.go and have added the following to the BERType table to make it work:

        case AsnCounter64:
            val, err := DecodeUInt(berValue)
            if err != nil {
                return nil, fmt.Errorf("error decoding integer %v: %v", berValue, err)
            }
            result = append(result, Counter64(val))

.I have a use-case where I need to lookup .1.0.8802 OIDs - they are perfectly fine and work, but I can't use them with your library.

If I remove the check, the requests seem to work, but all I get for a response is a "did not understand type 128" which looks like "No Instance found" - but there is an instance for sure, because if I look it up using snmpget it returns a STRING.

Looks like EncodeInteger and EncodeUint produce the wrong byte array for some values.

Example:
encodedID := wapsnmp.EncodeInteger(int64(16495265))
// encodedID = [251 178 161]
// should be [0 251 178 161]

This causes the value to be decoded as -281951 instead of 16495265.

Here are some more.

When the udp_stub_connection.go file exists flag.PrintDefaults will add test parameters on output.
Maybe because of udpStub struct ?

$ ./mysnmp -h
Usage of ./mysnmp:
-host="": host
-test.bench="": regular expression to select benchmarks to run
-test.benchmem=false: print memory allocations for benchmarks
-test.benchtime=1s: approximate run time for each benchmark
....

A value like -91 (as reported by snmpget) returns as 16777125 in WapSNMP.

I havent found the cause yet, but i'll do a pull request if i find it.

Good day.

I have a strange error.

This part of the code:

hardwareInfo,herr := SnmpServer.GetTable([]int{1,3,6,1,2,1,47,1,1,1,1,2})
if herr != nil {
fmt.Printf("Error getting table => %v\n", SnmpServer)
return
}
for currentOID, currentData := range hardwareInfo {
fmt.Printf("Current: %s -> %s\n",currentOID,currentData)
if result,:=regexp.MatchString("^X[0-9][0-9][0-9].*", currentData.(string));result {
hoid,:=strconv.Atoi(regexp.MustCompile("[0-9]+$").FindString(currentOID))
fmt.Printf("Found: %s -> %s\n",currentOID,currentData)
fmt.Printf("Get: %s%d\n","1.3.6.1.2.1.47.1.1.1.1.11.",hoid)
serialInfo,_:=SnmpServer.Get([]int{1,3,6,1,2,1,47,1,1,1,1,11,hoid})
fmt.Printf("%T : %v\n",serialInfo,serialInfo)
}
}

I run my program twice without recompiling, and:
Output log:

./getequipment

2015/02/19 10:37:45 Couldn't read. Retrying. Retry 0/5
Current: .1.3.6.1.2.1.47.1.1.1.1.2.1 -> X670-48x
Found: .1.3.6.1.2.1.47.1.1.1.1.2.1 -> X670-48x
Get: 1.3.6.1.2.1.47.1.1.1.1.11.1
2015/02/19 10:37:48 Couldn't read. Retrying. Retry 0/5
string : 1215G-02547
Current: .1.3.6.1.2.1.47.1.1.1.1.2.2 -> PowerSupply Slot-1
Current: .1.3.6.1.2.1.47.1.1.1.1.2.3 -> PowerSupply-Internal
Current: .1.3.6.1.2.1.47.1.1.1.1.2.4 -> PowerSupply Slot-2
Current: .1.3.6.1.2.1.47.1.1.1.1.2.5 -> PowerSupply-External
Current: .1.3.6.1.2.1.47.1.1.1.1.2.6 -> FanTray

./getequipment

2015/02/19 10:37:52 Couldn't read. Retrying. Retry 0/5
Current: .1.3.6.1.2.1.47.1.1.1.1.2.1 -> X670-48x
Found: .1.3.6.1.2.1.47.1.1.1.1.2.1 -> X670-48x
Get: 1.3.6.1.2.1.47.1.1.1.1.11.1
2015/02/19 10:37:55 Couldn't read. Retrying. Retry 0/5
string : X670-48x
Current: .1.3.6.1.2.1.47.1.1.1.1.2.2 -> PowerSupply Slot-1
Current: .1.3.6.1.2.1.47.1.1.1.1.2.3 -> PowerSupply-Internal
Current: .1.3.6.1.2.1.47.1.1.1.1.2.4 -> PowerSupply Slot-2
Current: .1.3.6.1.2.1.47.1.1.1.1.2.5 -> PowerSupply-External
Current: .1.3.6.1.2.1.47.1.1.1.1.2.6 -> FanTray

When I see the serial number - it is right. But it happens once in ten.
Your code is very beautiful and simple, but I do not see the error.

Hi Christope,

I’ve taken a quick look at the WapSNMP code and have found a few issues you may wish to take a look at:

1) ber.go - DecodeSequence

Problem: If the sequence contains EndOfMibView, an error is thrown and no values are returned. This error in turn will bubble up causing a whole GetTable or GetBulk call to fail.

Suggestion: Return EndOfMibView as a type like other types.

2) ber.go - DecodeSequence

Problem: Similar to above, hitting an unknown type at any point in a sequence, table scan, or GetMulitple will cause an error and it’s not possible to read any returned data.

Suggestion: Return an “Unsupported” type as a value, and continue, rather than raising an error at this low level. Callers can then handle on an individual OID basis as they see fit.

3) oid.go - DecodeOid

Problem: The test len(raw) < 2 is not correct. A zero length, or 0x00 (zero) OID is valid. This code failed when doing table scans on a few real world devices (e.g. Routers, NAS Servers, etc.).

Suggestion: return &Oid{}, nil

4) snmp.go - GetTable

Problem: The logic in GetTable seems to be faulty. The code to determine newLastOid assume the interaction order on the results map is deterministic. newLastOid will not be the numeric last oid, but instead a random OID (see iteration order). This bug causes very slow table walk because of overlapping pages are requested, and worse, it will randomly silently fail as there is a chance that lastOid == newLastOid.

Suggestion: I don’t think map[string] is the best data structure for this purpose. An ordered array of struct{OID, Value} may be a better choice, however this change would mean breaking the API. A non-braking solution would be to write your own ordering logic to determine the last OID (but this will be slower).

5) utils/goTable.go
Problem: There seems to be a minor case issue:

-       version := wapSnmp.SNMPv2c
+       version := wapsnmp.SNMPv2c

-       oid, err := wapSnmp.ParseOid(*oidasstring)
+       oid, err := wapsnmp.ParseOid(*oidasstring)

I’d welcome your thoughts/comments on these issues, and if appropriate I can propose some fixes and/or work with you to test.

Thanks for your hard work and making SNMP first-class in Go!