We developed our snmp agent plugin.so that loads info the snmpd with
dlmod command in the snmpd.conf.
I like to turn on/off certain infomation GET request base
on the incoming IP address and the USER name/authenication info. (snmpv3 mode)
What's the best way for my .so agent plugin to access
t
[EMAIL PROTECTED] wrote:
BTW, if we apply these changes, we (I) still need to update all the Perl
scripts to load from the registry instead of only the environment
variables. Until that is done, we can't switch over the installer
script to use the registry.
Should I put it in to main even tho
> From: Alex Burger <[EMAIL PROTECTED]>
> Date: 2004/10/07 Thu PM 10:44:31 EDT
> To: [EMAIL PROTECTED]
> CC: Andy Smith <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Subject: Re: Win32: Registry support
>
> [EMAIL PROTECTED] wrote:
> > Agreed. Very nicely done, Alex!
> >
> > I recommend one smal
Alex Burger wrote:
[EMAIL PROTECTED] wrote:
Agreed. Very nicely done, Alex!
I recommend one small change:
don't define char *temp ahead of the ifdef.
Other than that, the patch looks good!!
[and familiar, too %^)]
Yes! It is similar to Dirk Krause's patch 850782, except it is using
setenv instea
Has the local strtok_r function gone away completely now? I did a CVS
pull last night and was getting errors in the MinGW build about a header
included in strtok_r.c, ok...we can handle that. I was able to compile
by idefing the include out for mingw. I did another CVS pull this
afternoon and s
[EMAIL PROTECTED] wrote:
Agreed. Very nicely done, Alex!
I recommend one small change:
don't define char *temp ahead of the ifdef.
Other than that, the patch looks good!!
[and familiar, too %^)]
Yes! It is similar to Dirk Krause's patch 850782, except it is using
setenv instead of a static variab
Agreed. Very nicely done, Alex!
I recommend one small change:
don't define char *temp ahead of the ifdef.
Other than that, the patch looks good!!
[and familiar, too %^)]
>
> From: Andy Smith <[EMAIL PROTECTED]>
> Date: 2004/10/07 Thu PM 07:25:12 EDT
> To: Alex Burger <[EMAIL PROTECTED]>
> CC:
>
> From: <[EMAIL PROTECTED]>
> Date: 2004/10/07 Thu PM 05:39:51 EDT
> To: <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]>
> Subject: [ 1010351 ] Uninitalized stack variable in smux_trap_process
>
> All,
>
> I've submitted the above patch some time ago but it was never picked up.
> What can I
That works for me. I would much rather see wrapper functions than
continue adding to the #ifdef hell in application code. Very nice!
Andy
Alex Burger wrote:
Attached is a patch that allows you to use the registry to store
variables that are normally defined as environment variables.
A new funct
Attached is a patch that allows you to use the registry to store
variables that are normally defined as environment variables.
A new function called netsnmp_getenv has been created in tools.c. For
*nix it simply returns what getenv() would return.
For Windows it:
-returns a pointer to the envi
All,
I've submitted the above patch some time ago but it was never picked up.
What can I do to have it merged?
Read ya,
Joshua Giles
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business
SL> Hm... when I try to find a reasonable buffer size, I don't think
SL> I would care much about SNMP_MAX_PDU_SIZE, but rather about the
SL> EXPECTED traffic that I want the OS to buffer in times of
SL> congestion, i.e. about what's a reasonable number of trap
SL> (or request) PDUs to buffer, a
Michael J Slifcak writes:
> With the greatest respect to the author of the patch,
> I think the default should be "do not set this". Better yet,
> I think the patch should be removed, and left in the "This Works For Me"
> kind of patches that we collect, and not incorporated into the project.
> I
Geert De Peuter writes:
> If (server)
> DEFAULT_BUFFER = SNMP_MAX_PDU_SIZE * 2;
> else
> DEFAULT_BUFFER = SNMP_MAX_PDU_SIZE;
Hm... when I try to find a reasonable buffer size, I don't think I
would care much about SNMP_MAX_PDU_SIZE, but rather about the EXPECTED
traffic that I want the
Hello,
I've been trying to compile an agent (in win32, using VC++ 6.0) I have
extended to some test mib I have designed. I have executed the mib2c and
generated the 2 files and added them to the project and succesfully built
snmpd. Then I unload the service, replace the snmpd.exe file and upload
I'm trying to extend the agent, and my MIB has some integer and octet
string objects. It's only to store some values set by hand (snmpset),
not going to acquire them automatically.
I've followed the example (scalar_int) to create my integer objects
(netsnmp_register_int_instance) and it worked fin
Alex Burger wrote:
Hi Andy.
Attached is a patch for net-snmp.nsi that makes the following changes:
-Prompts the user to overwrite snmp.conf if it exists. If the user says
yes, it saves it as snmp.conf.new (overwriting snmp.conf.new if it
exists). It defaults to overwrite for silent installs.
-C
On Tue, 05 Oct 2004 12:23:40 + Patricia wrote:
PZ> We'd like to implement the net-snmp on our own developed embedded
PZ> system.=3D20 =3D20 We don't need the whole net-snmp, only an "elementary
PZ> kernel". I mean, a snmp- library, an agent -library and a MIB-library.
You should configure with
Thomas Anders wrote:
While I'm thinking that the "oldEngineID" handling qualifies as a bug
I submitted patch 1042139 to fix this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1042139&group_id=12694&atid=312694
Please apply.
+Thomas
--
Thomas Anders (thomas.anders at blue-cable.de)
-
> After building the agent, I am doing snmpwalk from 0.0 which results in
> "noSuchName" error. Please let me know, is this a bug in the Agent API's??
It's not a bug in the agent, no.
But it could well be regarded as a flaw in the 'snmpwalk' application.
What's happening is that snmpwalk starts
20 matches
Mail list logo
