Re: Strange error in test program...

Hi Dave,

On Tue, Apr 8, 2008 at 1:34 PM, Dave Shield <D.T.Shield@liverpool.ac.uk> wrote:
> On 08/04/2008, Kris van Rens <krisvanrens.list@gmail.com> wrote:
>
> > > But how do you know which ifIndex.{x} values to ask for?
> > > The {x} there is the same as the {x} in the ifPhysAddress.{x}
> > > OID. So this is just moving the problem (unnecessarily).
> >
> >
> > I suspected that for IF-MIB::ifIndex{x} = {y} the value {x} would be
> > in a strict consecutive order, that is, for your example this would
> > give:
> >
> > IF-MIB::ifIndex.0 = 2
> > IF-MIB::ifIndex.1 = 3
> > IF-MIB::ifIndex.2 = 27
>
> Nope.
> The ifIndex value is exacly the same as the index subidentifier.
> So this walk would actually read:
>
> IF-MIB::ifIndex.2 = 2
> IF-MIB::ifIndex.3 = 3
> IF-MIB::ifIndex.27 = 27
>
>
> That's why modern MIBs mark the index object as "not-accessible".
> It doesn't provide any useful information. These index values can
> be retrieved from walking any of the other columns instead.

Ok, I see. No solution here then.


> If you need SNMPv1 support, then the answer is to use GETNEXT:
>
> GETNEXT ifPhysAddress
> (gives back the value for ifPhysAddress.2)
> GETNEXT ifPhysAddress.2
> (gives back the value for ifPhysAddress.3)
> GETNEXT ifPhysAddress.3
> (gives back the value for ifPhysAddress.27)
> GETNEXT ifPhysAddress.27
> (gives back the value for ifAdminStatus.2
> which isn't relevant, so you can stop)
>
> Walking off the end of the column means you don't actually
> need to retrieve ifNumber.0

I'm trying this now, but for some reason, I get stuck at the first
object. Here's what I do:

-----------------------
// Get starting object: 'IF-MIB::ifPhysAddress.*'
read_objid("IF-MIB::ifPhysAddress", if_oid, &if_oid_len);

// Walk the list of IF-MIB::ifPhysAddress.x
for (i = 0; i < 10; i++) {
// Create a PDU (SNMP packet)
req = snmp_pdu_create(SNMP_MSG_GETNEXT);
snmp_add_null_var(req, if_oid, if_oid_len);

// Send request PDU
ret = snmp_synch_response(sess_h, req, &resp);
if (ret != STAT_SUCCESS || resp->errstat != SNMP_ERR_NOERROR)
goto out_snmp_synch_response;

// DEBUG
print_variable(resp->variables->name, resp->variables->name_length,
resp->variables);

// Free response PDU
if (resp)
snmp_free_pdu(resp);
}
------------------------------

I studied the code of snmpwalk, which, as far as I could see through
all error handling, does the same.

As you can see, the stopping criterion is still a counter, but will be
the end of the list.

Here's the output:
---
# ./snmptest
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.1 = STRING:
---

Thanks again!

-Kris

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757...un.com/javaone
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders