`ipAddressTable` and `ipAddressEntry` MIB Support

[upsampled]

Summary

Add Support for listing the IPs on an interface.

Notes

May look at doing this in another package to see if MIB development can be done separately from the main project.

[upsampled]

Ok, going to need to push some changes to handle dynamic length and value PDU Values.

Starting with dynamic values, I think the way to break the least amount of existing code is to unfortunately adopt 'variables in path declaration' syntax like the http package does.

So in the 'http' package you might see "/user/{name}" and the path then r.PathValue("name") in the handle function. For MIB declaration I might try:

{
	OID:      "1.3.6.1.2.1.2.2.1.2.{ifIdx}",
	Type:     gosnmp.OctetString,
	OnGet:    func(ctx context.Context) (value interface{}, err error) { 
                ctxVar:= ctx.Value("ifIdx")
                ifIndex := 0
                if idx, ok := val.(int); ok {
		   ifIndex  = idx
  	        } else {
  		    return nil, errors.New("unable to get ifIdx from request")
  	        }
                iface, err := net.InterfaceByIndex(ifIndex)
              	if err != nil {
              		return nil, err
              	}
                return GoSNMPServer.Asn1OctetStringWrap(ifName), nil 
        },
	Document: "ifDescr",
},

Not great code using string with Context.Value directly, but just hoping this should work initially and void dependency loops.

I'll work on dynamic length after this is working.

[slayercat]

Regarding this feature, would you consider using closure functions and generator-like constructs to improve modularity?

Specifically, would it be feasible to append each ifIdx-associated OID and its corresponding handler into the existing framework before start(), using closures to encapsulate the binding logic?

I haven't compiled this code yet — it's just a conceptual demonstration of the approach I have in mind:

package main

import (
	"errors"
	"fmt"
	"net"
	"strconv"

	"github.com/gosnmp/gosnmp"
	g "github.com/slayercat/gosnmpserver"
)


func makeIfDescrHandler(ifIndex int) func() (interface{}, error) {
	return func() (interface{}, error) {
		iface, err := net.InterfaceByIndex(ifIndex)
		if err != nil {
			return nil, err
		}
		return g.Asn1OctetStringWrap(iface.Name), nil
	}
}

func main() {
	var controlItems []g.PDUValueControlItem

	for i := 0; i < 10; i++ {
		ifIndex := i + 1 
		oid := fmt.Sprintf("1.3.6.1.2.1.2.2.1.2.%d", ifIndex)

		node := g.PDUValueControlItem{
			OID:      oid,
			Type:     gosnmp.OctetString,
			OnGet:    makeIfDescrHandler(ifIndex),
			Document: "ifDescr",
		}

		controlItems = append(controlItems, node)
	}
	// ... other codes
}

[upsampled]

Not really because things like number of IP addresses on an interface are going to be dynamic. More of an issue is that those IP addresses get put back into the OID value to get the next IP. See below for decrypted snmpd output for listing all IPs on interface 1.

report 1.3.6.1.6.3.15.1.1.4.0
get-next-request 1.3.6.1.2.1.4.20
get-response   1.3.6.1.2.1.4.20.1.1.127.0.0.1
get-next-request   1.3.6.1.2.1.4.20.1.1.127.0.0.1
get-response   1.3.6.1.2.1.4.20.1.1.172.17.0.3
get-next-request   1.3.6.1.2.1.4.20.1.1.172.17.0.3
get-response   1.3.6.1.2.1.4.20.1.2.127.0.0.1
get-next-request   1.3.6.1.2.1.4.20.1.2.127.0.0.1
get-response   1.3.6.1.2.1.4.20.1.2.172.17.0.3
get-next-request   1.3.6.1.2.1.4.20.1.2.172.17.0.3
get-response   1.3.6.1.2.1.4.20.1.3.127.0.0.1
get-next-request   1.3.6.1.2.1.4.20.1.3.127.0.0.1
get-response   1.3.6.1.2.1.4.20.1.3.172.17.0.3
get-next-request   1.3.6.1.2.1.4.20.1.3.172.17.0.3
get-response   1.3.6.1.2.1.4.20.1.4.127.0.0.1
get-next-request   1.3.6.1.2.1.4.20.1.4.127.0.0.1
get-response   1.3.6.1.2.1.4.20.1.4.172.17.0.3
get-next-request   1.3.6.1.2.1.4.20.1.4.172.17.0.3
get-response 1.3.6.1.2.1.4.21.1.1.0.0.0.0

While we don't have to do the variable in path syntax, I do think that we need to be able to indicate that this handler handles all requests with certain oid prefix. I also think that passing a context to the PDUValue handlers is smart in the short term for letting the handler know the full OID path, but also in the long term for cancelations and tracing.

[upsampled]

Ok, a quicker/hackier way to do this generator functions may be to trigger refreshes depending on the value given to getForPDUValueControl . If the OID given is before the first registered OID, then gather all the values for the pending walk. We still probably need to add a context, but at least the array math (super fragile) won't be effected.

[slayercat]

When I was developing this library, I did not fully consider the implications of changing the OID during operation. In my estimation, a brief service interruption to change the OID and then restart the service would generally be acceptable.

If you have any better suggestions, I would greatly appreciate hearing them, and I am more than willing to adopt them.

Thanks

[upsampled]

On closer look, we might be able to use generators We are just going to determine when to cache values and when to refresh. Also locking will need to be added to the OIDs member.

Can you verify something? the length variable in get-next request is often involved with the OID table length, so it makes it difficult to deal with if the OID table changes. Few other notes:

• I also don't think Get-Next requests has max-repetitions field, so the following can be deleted

        if i.MaxRepetitions != 0 {
		length = int(i.MaxRepetitions)
	}

• length is almost always 1, I see you are trying to handle greater than 1 but i don;t think it is correct.

	if length+id > len(t.OIDs) {
		length = len(t.OIDs) - id
	}

When length is 1, this makes perfect sense. You are checking if there is an OID after the current OID; however i believe , If you get three get-next requests, you have to individually check the OIDs after each one, not get the next three.

If you send a get-next-request with 3 OIDs:

• .1.3.6.1.2.1.1.2.0
• .1.3.6.1.2.1.1.4.0
• .1.3.6.1.2.1.1.6.0

Then the response will contain 3 values:

• The next OID after .1.3.6.1.2.1.1.2.0
• The next OID after .1.3.6.1.2.1.1.4.0
• The next OID after .1.3.6.1.2.1.1.6.0

With your permission I think we should only handle the length value of 1, as that is the only value that works currently, and then handle the extremely rare multi OID get-next equerry in another revision

[slayercat]

I understand that in your use case, an SNMP-GET request typically contains only one OID. However, both the sample pcap and the reference [1] have shown instances where multiple OIDs are used within a single SNMP-GET request.

I am not entirely certain if the current implementation fully complies with the RFC, and this is something that warrants further consideration. I simply hope that the current implementation is logical (my apologies, as I may not have had sufficient time recently to conduct thorough testing).

I have attached the pcap file for your reference.

Thank you very much for your valuable feedback.

[1] https://stackoverflow.com/questions/35239828/snmp-how-many-oids-can-be-requested-in-one-pdu

snmp_v2c_getnext_multiple_oids.zip