Hi,
According to the 5.3.0.1 implementation, the engine ID discovery
is being done synchronously. Since the discovery is using the function
snmp_sess_synch_response passing as argument the session that wants to
be created, the agent is blocked during the discovery process not
allowing to re
I tried adding this line to target.c:get_target_sessoin():
netsnmp_ds_set_string(NETSNMP_DS_LIBRARY_ID, NETSNMP_DS_LIB_CLIENT_ADDR,
"localhost:");
So the new code looks like this:
Line
--
155 netsnmp_transport *t = NULL;
156
157 netsnmp_ds_set_string(NETSNMP_DS_LIBRARY_ID,
NET
Hi,
The initial Problem:
-
Inform ACKs are block by my Firewall.
Net-SNMP sends out an Infrom : [port X] --> [port 162]
Std. Infrom receiver replies: [port Y] --> [port X]
* X,Y are random ports.
Solution concept:
--
AMke net-snmp
Sorry for the double post, but this is the traceback I get on the
version in the trunk as well:
In [1]: import netsnmp
---
Traceback (most recent call last)
/src/net-snmp-svn-main/python/ in ()
/src/net-snmp-svn-m
I had problems importing the netsnmp python moduel once I had compiled
version 5.4. Is the version in the trunk a better place to checkout
the python bindings?
Noah
-
This SF.net email is sponsored by DB2 Express
Download DB
On 08/05/07, Senthil Nathan <[EMAIL PROTECTED]> wrote:
> Here, i have a mib table indexed by internal index...
> presently,i fixed the index range as 20. But i need the indexing should not
> be fixed.
So don't fix it.
If you've got a variable holding the maximum valid index, then use
that instea
Sukwoo Kang wrote:
> Do we need to modify libtool in net-snmp src directory? Is your work
> related
> to the following posting? (I found it in net-snmp-users list.)
Hacking libtool (in the top-level source dir) is one way of doing it.
Give it a try and let us know how it works out for you. Please
Magnus Fromreide wrote:
> I'd like to know if the last chunk in r16341 really was intended to be
> comitted?
>
> Index: agent/snmp_agent.c
> ===
> --- agent/snmp_agent.c (revision 16340)
> +++ agent/snmp_agent.c (revision 16341)
> @
