Most likely insanely newbie GET vs GETNEXT question

[Parth7]

I'm attempting to graph performance numbers from Ethernet radios and hitting a bit of a wall. It all boils down to this:

snmpgetnext -v 2c -c public 192.168.10.168 .1.3.6.1.4.1.10728.2.10.2.2.8.1.4
iso.3.6.1.4.1.10728.2.10.2.2.8.1.4.11.44580 = INTEGER: -65

That works and the -65 is the number I want to graph.

snmpget -v 2c -c public 192.168.10.168 .1.3.6.1.4.1.10728.2.10.2.2.8.1.4
iso.3.6.1.4.1.10728.2.10.2.2.8.1.4 = No Such Instance currently exists at this OID

That doesn't work.

I'm assuming this is because the radio is storing a table of these values which is why I need to issue the GETNEXT instead of a simple GET. How do I tell Cacti to do that?

[Howie]

GETNEXT gets you the next OID after the one you asked for. If you look, the reply isn't for the same OID that you requested!

So iso.3.6.1.4.1.10728.2.10.2.2.8.1.4.11.44580 is what you should try to use with snmpget

[Parth7]

I was thinking that I couldn't reference .1.3.6.1.4.1.10728.2.10.2.2.8.1.4
iso.3.6.1.4.1.10728.2.10.2.2.8.1.4.11.44580 because it was subject to change. Is that not true? If so, I can easily just change the OID.

[Howie]

It depends on the MIB, but usually that last part will be something like the interface number, which won't change. It depends on what the manufacturer has defined though - people do some funny things.

[Parth7]

Unfortunately it changes.

snmpgetnext -v 2c -c public 192.168.10.168 .1.3.6.1.4.1.10728.2.10.2.2.8.1.2
iso.3.6.1.4.1.10728.2.10.2.2.8.1.2.11.44693 = INTEGER: -66

A few minutes later...

snmpget -v 2c -c public 192.168.10.168 iso.3.6.1.4.1.10728.2.10.2.2.8.1.2.11.44693
iso.3.6.1.4.1.10728.2.10.2.2.8.1.2.11.44693 = No Such Instance currently exists at this OID

Immediately after that...

snmpgetnext -v 2c -c public 192.168.10.168 .1.3.6.1.4.1.10728.2.10.2.2.8.1.2
iso.3.6.1.4.1.10728.2.10.2.2.8.1.2.11.44708 = INTEGER: -66

Is there a way to get Cacti to collect its data via an snmpnext instead of a snmpget so that it can follow this changing OID?

[Howie]

If it's changing like that, it's probably because the thing you're monitoring is different. Check in the MIB to see what that data really is...

So if it's for an associated client which goes away, for example, you probably need to rethink your plan.

[Parth7]

It appears I was going after table data that the device was storing and continuously updating. the MIBs for those table cells were constantly changing. I found the raw data I needed elsewhere in static MIBs so a GET reliably works. Thanks for the input.