On 08/04/2008, Kris van Rens <[EMAIL PROTECTED]> wrote:
> Yes, I thought so, but all attempts were without result. Here's what I
> thought I should do:
>
> ---
> // Update OID
> memmove(if_oid, resp->variables->name, resp->variables->name_length);
resp->variables->name_length*sizeof(oid)
>
Hi Dave,
Thanks again for your response.
On Tue, Apr 8, 2008 at 2:51 PM, Dave Shield <[EMAIL PROTECTED]> wrote:
>You need to update the 'if_oid' buffer with the OID from this response.
>
> At the moment, you're asking for the same OID every time.
Yes, I thought so, but all attempts were wi
On 08/04/2008, Kris van Rens <[EMAIL PROTECTED]> wrote:
> I'm trying this now, but for some reason, I get stuck at the first
> object. Here's what I do:
> read_objid("IF-MIB::ifPhysAddress", if_oid, &if_oid_len);
>
> // Walk the list of IF-MIB::ifPhysAddress.x
> for (i =
Hi Dave,
On Tue, Apr 8, 2008 at 1:34 PM, Dave Shield <[EMAIL PROTECTED]> wrote:
> On 08/04/2008, Kris van Rens <[EMAIL PROTECTED]> 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 thi
On 08/04/2008, Kris van Rens <[EMAIL PROTECTED]> 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} =
Hi Dave,
On Tue, Apr 8, 2008 at 12:53 PM, Dave Shield <[EMAIL PROTECTED]> wrote:
> On 08/04/2008, Kris van Rens <[EMAIL PROTECTED]> wrote:
>
> > > You are also assuming that ifTable entries will always be
> > > in a strict consecutive sequence (starting from 1). That's
> > > probably tru
On 08/04/2008, Kris van Rens <[EMAIL PROTECTED]> wrote:
> > You are also assuming that ifTable entries will always be
> > in a strict consecutive sequence (starting from 1). That's
> > probably true for most simple systems, but it's not guaranteed.
> >It is perfectly valid to have 3 in
Hi Dave,
Thanks for the apt response, I really appreciate it! I fixed the
MAX_OID_LEN thing and all works fine now.
> You are also assuming that ifTable entries will always be
> in a strict consecutive sequence (starting from 1). That's
> probably true for most simple systems, but it's not g
Hi Dave
What i meant by both patches is that I applied them one by one.
Both have some changes to be made for 5.3.1 code which I made and Applied
them.
After Patching..I did a make uninstall and recompiled the code again after
running ./configure.
However the error still persists.The container erro
On 08/04/2008, Kris van Rens <[EMAIL PROTECTED]> wrote:
> size_t if_oid_len = MAX_OID_LEN;
> read_objid("IF-MIB::ifNumber.0", if_oid, &if_oid_len);
Remember that this sets the value of 'if_oid_len' to be the actual
length of the OID for 'ifNumber.0' (i.e. 10)
> for (i =
On 08/04/2008, anand <[EMAIL PROTECTED]> wrote:
> I have applied the container-atomic-insert.patch as well as
> net-snmp-5.3-shared-ip-4.patch on the release Net-SNMP 5.3.1.
I'm not sure whether it's sensible to apply *both* patches.
According to the comments in that tracker item, the container
p
Hi There,
I'm experiencing strange behaviour with a test program for NET-SNMP
I've made (in Linux that is).
The test program source code is concatenated below and executes the
following things in chronological order:
** Initialise a SNMP session
** Build a PDU that requests 'IF-MIB::ifNumber
Hi
I have applied the container-atomic-insert.patch as well as
net-snmp-5.3-shared-ip-4.patch on the release Net-SNMP 5.3.1.
However on issuing the SIGHUP im still seeing these messages in the logs:
NET-SNMP version 5.3.1
Reconfiguring daemon
NET-SNMP version 5.3.1 restarted
error on subcontaine
13 matches
Mail list logo
