On 20 October 2011 09:39, Ravi Kumar wrote:
> Code is similar to below
OK - so you are still forcing me to guess.
The only thing I can spot that looks wrong is the
handling of suffices (i.e. the index values)
> suffix = requests->requestvb->name + reginfo->rootoid_len + 1;
> s
Code is similar to below
void
initialize_table_XXXTable(void)
{
static u_long XXXTable_oid[] = { 1, 3, 6, 1, 4, 1, 38070, 3, 1, 24, 4
};
netsnmp_table_registration_info *table_info;
netsnmp_handler_registration *my_handler;
netsnmp_variable_list *index_vb;
table_info
On 20 October 2011 08:07, Ravi Kumar wrote:
> I have registered my table with netsnmp_register_table to implement
> my own getnext.
> Every thing seems to be working fine except snmpgetnext request with
> multiple oid returns only first oid and its value in response PDU.
> Any guesses ?
I'm sorr
I have registered my table with netsnmp_register_table to implement my own
getnext.
Every thing seems to be working fine except snmpgetnext request with
multiple oid returns
only first oid and its value in response PDU. Any guesses ? my code loops
over
for (request = requests; request; request =
On 19 October 2011 08:57, Ravi Kumar wrote:
> Can you please point me the function or code where this conversion is
> happening with respect to netSnmpHostsTable.
This is probably handled within 'netsnmp_table_iterator_helper_handler'
(agent/helpers/table_iterator.c).That's at the heart of th
Can you please point me the function or code where this conversion is
happening with
respect to netSnmpHostsTable . what if some one wants to implement his own
getnext functionality ?
Thanks.
On Wed, Oct 19, 2011 at 1:05 PM, Dave Shield wrote:
> On 19 October 2011 07:53, Ravi K
On 19 October 2011 07:53, Ravi Kumar wrote:
> I was going though netSnmpHostsTable table implementation based
> on mib2c.iterate_access.conf.
> I could no find a GETNEXT handling in netSnmpHostsTable_handler from the
> code looks like only get and set are handled.
That's correct.
Most of the tabl
Hi!
Probably problem in function int check_getnext_results (netsnmp_agent_session
*asp) from snmp_agent.c (a line 2798).
There is no check of the status of request. If the status of request is
erroneous, function check_getnext_results all can return 1 (request GETNEXT
correct).
It is necessary
Tue, 16 Nov 2010 16:28:10 + письмо от Dave Shield
:
> [ First - *please* don't mail me privately, without copying
> any responses to the mailing list. I don't have the time
> or inclination to offer private, unpaid, SNMP consultancy.
> Keep discussions to the list, where others can bot
[ First - *please* don't mail me privately, without copying
any responses to the mailing list. I don't have the time
or inclination to offer private, unpaid, SNMP consultancy.
Keep discussions to the list, where others can both learn
and offer advice. Thanks. ]
2010/11
On 11 November 2010 15:16, Robert Story wrote:
> On Thu, 11 Nov 2010 09:20:22 +0300 Phill wrote:
> PX> Has faced a strange situation. There are 4 tables in one MIB-file. All
> tables are realised in the subagent through AgentX. Net-SNMP works as the
> master. All fields of the table have type Un
On Thu, 11 Nov 2010 09:20:22 +0300 Phill wrote:
PX> Has faced a strange situation. There are 4 tables in one MIB-file. All
tables are realised in the subagent through AgentX. Net-SNMP works as the
master. All fields of the table have type Unsigned32. If any table contains an
error (for example n
Hi Dave,
I have submitted 2 patches, one for the trunk and one for V5.4 branch.
Please check at leased that one for trunk. 3 test scripts are also
included.
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3096725&group_id=12694
Kindly regards,
Claus
On 26.10.2010, at 22:43, Cl
Ok, done.
see
https://sourceforge.net/tracker/?func=detail&aid=3096725&group_id=12694&atid=312694
Note, this patch does not fix the sparse table BUG at V5.4.3!
Regards
Claus
On 26.10.2010, at 06:06, Thomas Anders wrote:
> Claus Klein wrote:
>> Please apply this patch and check the result abo
Hi Dave,
thanks, you are right. I merged more than needed.
On the other site, the sparse table handling on net-snmp v5.6 works.
Without my changes at the table_dataset.c.
But I have no Idea why?
So I merged all this files ... without luck.
Later I found the solution for this problem at the ta
Ok Thomas,
I will do it again against the SVN trunk.
But I still need a hint:
At another tread I asked some question about the code ...
1.) Why is the send_trap_to_sess() called for each entry at sinks
without check the snmpNotifyFilter?
2.) And why is the snmpNotifyFilter called via callbac
On 25 October 2010 22:30, Claus Klein wrote:
> First of all, the sparse table handling for the notificationLogMib does not
> work!
>
> Second the v1 trap pdu is different from the v2/v3 trap pdu.
>
> Than there are a lot of small BUGs about the trap handling toward the
> notificationLogMib.
> Pl
Claus Klein wrote:
> Please apply this patch and check the result about my FIXME notes.
Please submit your patch to http://www.net-snmp.org/patches so it won't get
lost. Patches that apply cleanly against SVN trunk usually have a higher chance
to get accepted quickly.
+Thomas
I was able to fix it.
It was more than one BUG involved!
First of all, the sparse table handling for the notificationLogMib
does not work!
Second the v1 trap pdu is different from the v2/v3 trap pdu.
Than there are a lot of small BUGs about the trap handling toward the
notificationLogMib.
On 2/12/08, Dave Shield <[EMAIL PROTECTED]> wrote:
>
> On 11/02/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> > I inserted ### before the "perl do" line in each copy of snmpd.conf that
> had
> > it.
>
> And restarted the agent, I presume?
Yes, with service snmpd restart.
> The behavior did
On 11/02/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> Also, 2nd question - What should be our subagent's response to a "getnext"
> on the last leaf in our subtree?
The subagent should return an "endOfMibView" value for this varbind
(RFC 2741, section 7.2.3.2 (2))
But if you're using the Net-S
On 11/02/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> I inserted ### before the "perl do" line in each copy of snmpd.conf that had
> it.
And restarted the agent, I presume?
> The behavior did not change, i.e. it still timed out as before.
H
Curiouser and curiouser
Other things
I inserted ### before the "perl do" line in each copy of snmpd.conf that had
it. The behavior did not change, i.e. it still timed out as before. (Also
the subagent still appears to function.) I forgot to mention, when I do a
getnext on netSnmp.1.8 I get an additional line that says
Connection from
On 11/02/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> Apparently we have no extend, etc, entries, though there's a "perl do"; here
> is the full text (excluding comments and blank lines) of the 3 snmpd.conf
> files I found on the system (=== lines are my commentary):
> === Contents of (recent
Apparently we have no extend, etc, entries, though there's a "perl do";
here is the full text (excluding comments and blank lines) of the 3
snmpd.conf files I found on the system (=== lines are my commentary):
=== Non-comment contents of /var/net-snmp/snmpd.conf
setserialno 463370307
engineBoots 2
On 11/02/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> > > But my question is also more algorithmic: How is it (the agent/subagent
> > > combination) supposed to do a getnext that jumps out of the subagent's
> > > subtree?
> >
> > The subtree is given an OID, and returns the next value that it k
On 11/02/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> Getnext results for netSnmp.x
> 1.4 nsCacheDefaultTimeout.0
> 1.5 same
So the cache modules is working OK
> 1.6 nsDebugEnabled.0
> 1.7 same
... as is the debug module...
> 1.8 enterprises.22782.1.2.1.1.0 = Timeticks (start of our sub
Interleaved below...
On 2/11/08, Dave Shield <[EMAIL PROTECTED]> wrote:
>
> On 11/02/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> > Response to getnext at netSnmp.1.3 is timeout.
>
> OK - what about
>GETNEXT netSnmp.1.5
>GETNEXT netSnmp.1.7
>GETNEXT netSnmp.1.9
>
> What I'm t
On 11/02/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> Response to getnext at netSnmp.1.3 is timeout.
OK - what about
GETNEXT netSnmp.1.5
GETNEXT netSnmp.1.7
GETNEXT netSnmp.1.9
What I'm trying to determine here is exactly *where* the blocking module
is located. If netSnmp.
Response to getnext at netSnmp.1.3 is timeout. Response to get at
netSnmp.1.3, netSnmp.1.3.1, etc, is noSuchName (though it does give a name
for the first couple of them). My guess is that whatever comes immediately
after netSnmp.1.2.1.1.6.0.12.1.3.6.1.6.3.16.1.5.2.1.6.127 is where the
damage is.
On 23/01/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
>attempting a subtree at netSnmp times out after
> netSnmp.1.2.1.1.6.0.12.1.3.6.1.6.3.16.1.5.2.1.6.127 and
> trying a getnext on this oid also times out.
That's part of the nsModuleTable
(in particular, an instance of the nsModuleTimeout
Hi Dave,
I have rechecked it , populating the values both the indexes
If I using snmp_alarm_register, in that case reqinfo->mode
=161(GETNEXT) and if i not using that reqinfo->mode =160(GET)..
I feel this is the only problem. But I don't know , why it is coming
like that .
Thanks & Regards
P
Hi ,
I have now populated the first index also . But still it is giving the
same result.
running snmpwalk on that node is giving "Timeout: No Response from
localhost "
Thanks & regards
Partha
Dave Shield wrote:
On Tue, 2005-06-14 at 11:36, partha wrote:
For the time being I want to work
> does GetNext and GetBulk functions column-wise in case of a table
> or row-wise..
They both walk the full length of each column (i.e. the value from
each row) before moving on to the next column.
Did you think of actually trying this with an existing agent,
to see what it does in practise?
34 matches
Mail list logo
