Also I have a question.
Do we need to use gdb on snmpd?
Or we need to use it on snmpget?
Can you please please clarify the steps we need to perform?
Sincerely,
Rahul K
-Original Message-
From: SHARMA,RAHUL K (A-India,ex1)
Sent: Wednesday, September 06, 2006 10:18 AM
To: [EMAIL PROTECTED
Hi,
The output is "No match".
For example
COMMAND -> snmpget -v1 -c SNMP_COMMUNITY-61 udp6:[fe80::203:baff:fe2a:a645]
sysName.0
OUTPUT -> No match
We will try using debugger and get back to you with information.
Sincerely,
Rahul K
-Original Message-
From: Thomas Anders [mailto:[EMAIL
Hello coders,
"undefined reference" issue.
/home/rexino/work/monp_tmp/libs/clictr/libclictr.a(CCliCtrTable_interface.o)(.text+0x115a):
In function `_CCliCtrTable_container_row_restore':
: undefined reference to `_mfd_CCliCtrTable_rowreq_from_index'
collect2: ld returned 1 exit status
I have look
Thank you for your detail description!
For the first question, I have tried netsnmp_insert_iterator_context. But unfortunately, it doesn't work yet - I get NULL.
The related codes is list:
printf("\npeter--notePCTable_createEntry --begin\n"); table_row = notePCTable_createEntry(t
Vladislav Bogdanov wrote:
> I attach the patch which corrects this behaviour for linux
What's the relationship/difference between your patch and the one in the patches
tracker:
[ 1509943 ] send udp replies from the ip alias they have been received
http://sourceforge.net/tracker/index.php?func=det
Hi.
Here is what tcpdump sees when polling multihomed linux host with
address 10.1.1.16 on eth interface and address 10.20.0.1 on dummy
(loopback) interface:
22:21:45.418354 10.10.194.15.57311 > 10.20.0.1.snmp: C=public
GetRequest(28) .1.3.6.1.2.1.1.1.0 (DF)
22:21:45.419425 10.1.1.16.snmp
Wes Hardaker wrote:
> DS> I'm inclined to leave things as they stand - this feels a more secure
> DS> arrangement, and is probably in line with default expectations.
> I actually think it should authorize all by default. That's what it's
> done before and it's a behavior change.
I'm on the fenc
> "DS" == Dave Shield <[EMAIL PROTECTED]> writes:
DS> I'm inclined to leave things as they stand - this feels a more secure
DS> arrangement, and is probably in line with default expectations. But
DS> it does result in a minor change in behaviour, so I wouldn't object if
DS> the consensus was
[EMAIL PROTECTED] wrote:
> IPv6:
> a) snmpget -v1 -c SNMP_COMMUNITY-61 udp6:[fe80::203:baff:fe2a:a645] sysName.0
> -> No match - NOT OK
> b) snmpget -v1 -c SNMP_COMMUNITY-62 udp6:[fe80::203:baff:fe2a:a645] sysName.0
> -> No match - NOT OK
What exactly is the output here?
Anyway, I'm sorry to co
On Thu, 24 Aug 2006 11:34:44 +0100 Graeme wrote:
GW> I just wondered if you were any closer to a solution for this problem -
GW> or maybe you need more debug from me to help you out.
I think I've tracked it down.. Can you try this patch?
row-merge-prev.pat
Description: Binary data
--
> "DS" == Dave Shield <[EMAIL PROTECTED]> writes:
DS> Explicitly authorise all contexts.
DS> (This results from a minor alteration in behaviour following another code
DS> change, but feels more secure than automatically opening up all contexts
DS> by default. Though I'm happy to be persuaded
On Tue, 5 Sep 2006 14:51:05 + Claus wrote:
CK> is there any patch available to fix the get-bulk problem?
Not that I know of. Did you ever file a bug-report for this problem? If not,
please do so, so we can get to it when someone gets properly motivated.
If you are looking at it yourself, net
On 05/09/06, Robert Story <[EMAIL PROTECTED]> wrote:
> So long as we're talking 5.4+,
Yup.
> and there is a way for the user to
> specify
> something to get the old behaviour (i.e. a prefix context match on ""),
Yup.
(That's the tweak I had to make to the te
On Wednesday 09 August 2006 17:40, Robert Story wrote:
> On Wed, 9 Aug 2006 15:11:52 + Claus wrote:
> CK> On Wednesday 09 August 2006 14:27, Robert Story wrote:
> CK> > On Wed, 9 Aug 2006 13:06:25 + Claus wrote:
> CK> > CK> IF-MIB::ifDescr[7] = STRING: br0
> CK> > CK> IF-MIB::ifDescr[501] =
On Mon, 04 Sep 2006 11:06:51 -0400 Sten wrote:
OS> This all happens because the first event (that runs run_alarms() and
OS> agentx ping) calls send(), select(), and recv() all in the same function
OS> call (agentx_synch_response()).
OS>
OS> It seems to me that it shouldn't be calling select() or r
On Tue, 5 Sep 2006 14:03:20 +0100 Dave wrote:
DS> It turns out that this change has also affected the default behaviour
DS> slightly. Up to now, these convenience directives have registered an
DS> entry in the vacmAccessTable with a prefix context match on "" - thus
DS> matching *ALL* contexts by
Dave Shield wrote:
> It turns out that this change has also affected the default behaviour
> slightly. Up to now, these convenience directives have registered an
> entry in the vacmAccessTable with a prefix context match on "" - thus
> matching *ALL* contexts by default. Following my latest patc
I've recently made an update to the processing of the access control
directives, to support setting an explicit context (or context
prefix). This has always been available via "access" (and
"authaccess"), but I wanted to add similar functionality to the
convenience routines (authcommunity, authuse
On 05/09/06, Zhang Chuan <[EMAIL PROTECTED]> wrote:
> I think the row can not be avaliable immediately after
> netsnmp_table_data_add_row(), but can be avaliable immediately after
> netsnmp_insert_table_row(). Am I right?
That's too simplistic a description.
Please see my explanation from yesterda
19 matches
Mail list logo
