🚀 go-pugleaf

In article <uaeh7vglc89hhj95o...@4ax.com>, 
br...@zakalwe.demon.co.uk says...
> On Wed, 19 Mar 2003 16:53:18 GMT, "FLY135" <fly...@hotmail.com>
> wrote:
> 
> >Jim,
> >
> >I kind of see what my problem is but I don't know why it's happening and how
> >to fix it.  I have a MIB (called MIBNODE_networkIP) of type
> >ASN1_TYPE_IpAddress.  I'm using a shareware program called Loriot to do an
> >SNMP walk in part of my MIB tree.  When I get to MIBNODE_networkIP the
> >RTCSMIB_powerful_getnext is entered and I have a breakpoint to see what is
> >happening.  Originally I thought the MIB_instance_ipAddrEntry parse routing
> >was that I needed based on the MIBNODE_ipAdEntAddr MIB in 1213.c.  But this
> >is what was causing my fault.  MIB_instance_ipAddrEntry kept wanting to call
> >a FIND function which was NULL.  Also MIBNODE_ipAdEntAddr doesn't seem to
> >have a FIND function specified either.
> >
> >So I replaced the MIB_instance_ipAddrEntry parser with MIB_instance_zero,
> >thinking that may solve my problem.  Well when the beakpoint is hit in
> >RTCSMIB_powerful_getnext I see that my parse function is changed back to
> >MIB_instance_ipAddrEntry.  Is this normal behavior and is this what it
> >should be doing?  The end result is that RTCSMIB_OP_GETNEXT op code in
> >RTCSMIB_powerful_getnext is executed until the ID is zero.  The the opcode
> >is replaced with RTCSMIB_OP_GETFIRST and the parse function
> >MIB_instance_ipAddrEntry is called.  At that point MIB_instance_ipAddrEntry
> >tries to execute the null FIND.
> >
> >Got any ideas about what is going wrong?
> 
> Fuck! You must be joking!
> 
> Oh how Zan would have loved this.

Rubbish.

Obviously, he has simply neglected to flopdoodle the MIB_instance_zero, 
which is making RTCSMIB_OP_GETNEXT all tretchy.

And where the heck is Zan?  I'm running out of shadows to worship.

Bret