Alex Burger wrote:
[EMAIL PROTECTED] wrote:
Using a 5.2.pre2- win32 binary..
1. Un-install does not remove all of the files.
These files remain:
/c/usr/share/snmp/mib2c.access_functions.conf
/c/usr/share/snmp/mib2c.array-user.conf
/c/usr/share/snmp/mib2c.check_values.conf
/c/usr/share/snmp/mib2
[EMAIL PROTECTED] wrote:
Using a 5.2.pre2- win32 binary..
1. Un-install does not remove all of the files.
These files remain:
/c/usr/share/snmp/mib2c.access_functions.conf
/c/usr/share/snmp/mib2c.array-user.conf
/c/usr/share/snmp/mib2c.check_values.conf
/c/usr/share/snmp/mib2c.check_values_loc
Hello All,
I am working on a hpux(11.22 IPF).
In this architecture
**file
mntab.h(present)
function getmntentit is used to open the /etc/mntab
fileis defined in the c library
function endmntentit is used to close the /etc/mntab
fileis defined
Hi, Jochen.
I think the Net-SNMP community would benefit from the patches
that are currently held in net-snmp-5.1.2-5.diff.gz.
[Search "debian" and "net-snmp" to find that file]
I believe that some of those patches could be applied
to the V5-1-patches and main branches of net-snmp CVS trees.
The
Alex Burger wrote:
Michael J. Slifcak wrote:
Using a later 5.2.pre2- win32 binary,
these un-install issues were tested
All files installed from Net-SNMP package were removed
If snmpd agent was registered and running,
it was stopped, unregistered, then removed.
All references to "snmpd.log
Michael J. Slifcak wrote:
Using a later 5.2.pre2- win32 binary,
these un-install issues were tested
All files installed from Net-SNMP package were removed
If snmpd agent was registered and running,
it was stopped, unregistered, then removed.
All references to "snmpd.log" no longer exist i
On Sun, 3 Oct 2004 18:49:17 +0200 Geert wrote:
GDP> OK ... Replying off-list [...]
Replying on-list, because everyone should see all the arguments (eg this isn't
solely my decision, so you need to present your arguments to everyone).
GDP> You did mention in your original reply to up the buffers o
Using a later 5.2.pre2- win32 binary,
these un-install issues were tested
All files installed from Net-SNMP package were removed
If snmpd agent was registered and running,
it was stopped, unregistered, then removed.
All references to "snmpd.log" no longer exist in the Registry
after u
On Sun, 3 Oct 2004 14:00:33 +0100 Patrick wrote:
PW> Thanks - I also add that extra NULL check in mib.c which avoids a core
PW> dump if one doesn't use a sensible "width" values..
Tahnks, I added that patch to 5.1.x and 5.2.x cvs, thanks.
I'll leave the manpage patches for the manpage folks. I'd
On Sun, 3 Oct 2004 16:35:58 +0200 Geert wrote:
GDP> Technically I agree with leaving the UDP buffers alone (unless they are
GDP> explicitly set in the configuration) like you suggest.
GDP> However, the consequences will be that more traps will get lost and bigger
GDP> packets might not make it when
Michael J. Slifcak wrote:
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.
If the commu
On Sun, 03 Oct 2004 09:39:52 -0400 Michael wrote:
MJS> Robert Story (Coders) wrote:
MJS> > The new patch allows on to set independent buffer sizes for client vs
MJS> > server, and send vs receive. Given that SNMP_MAX_PDU_SIZE is less than
MJS> > 64k, a default buffer size of 128k seems excessive.
M
Technically I agree with leaving the UDP buffers alone (unless they are
explicitly set in the configuration) like you suggest.
However, the consequences will be that more traps will get lost and bigger
packets might not make it when people upgrade to version 5.2, just because
their OS default happ
Just as a quick FYI.
If "it is decided" to pull the patch then the network admins/system admins
would not be able to tweak anything anymore, because the situation as it was
"before the patch" reset both the send and receive buffer to 128K
(hardcoded). That means, even before the patch all net-snm
On Sun, 3 Oct 2004 10:07:25 +0200 Geert wrote:
GDP> In case someone has a default socket buffer size which is greater than our
GDP> default (currently 128K) then we should probably respect that.
I think this is another good argument for leaving the OS default alone, unless
a buffer size is explici
Robert Story (Coders) wrote:
With the recent addition of the ability to set the buffers size for UDP and TCP
sockets in 5.2, it seems like a good time to revisit the question of what the
default value should be. The current behavior is to set them to 128k, which
seems rather large. The rational, fr
On Sun, Sep 26, 2004 at 05:24:55PM -0400, Robert Story wrote:
> On Fri, 24 Sep 2004 17:34:53 +0100 Patrick wrote:
> PW> I would provide patches to man, but I don't really understand
> PW> what a subidentifier is..
>
> A sub-identifier is a single identifier from an OID. eg, .1.3.6 is composed of
>
My previous post made me realize it that the current patch might still not
be optimal in some situations...
In case someone has a default socket buffer size which is greater than our
default (currently 128K) then we should probably respect that.
At the moment, if the end user doesn't override the
The recent addition only allows tweaking of the UDP buffers.
First a note on why I "forgot" about TCP
On the TCP side I looked at the code and saw the return code of the send is
intercepted. Therefore I made the (wrong) assumption that this return code
would be interpreted appropriately and an fa
19 matches
Mail list logo
