5.4.1: Persistent file ever growing

Hello all, Using net-snmp 5.4.1 and creating one V3 user, I noticed that the persistent snmpd.conf file is always growing at each shutdown and startup of the daemon. An env. var is used to specify an alternate path to that file (now in /etc/snmpd/persistent/). I noticed that some years ago a

Re: 5.4.1: Persistent file ever growing

On Thu, 26 Mar 2009 09:34:11 +, Dave Shield wrote : > 2009/3/26 lanas : > >  Using net-snmp 5.4.1 and creating one V3 user, I noticed that the > > persistent snmpd.conf file is always growing at each shutdown and > > startup of the daemon. > > What is the differ

Re: 5.4.1: Persistent file ever growing

On Wed, 25 Mar 2009 20:56:13 -0400, lanas wrote : > Using net-snmp 5.4.1 and creating one V3 user, I noticed that the > persistent snmpd.conf file is always growing at each shutdown and > startup of the daemon. An env. var is used to specify an alternate > path to that file (now i

Using var_ifEntry() to get iinterfaces names

Hello, I've noticed that there are (at least...) two ways to obtaine an interface name unside net-snmp. I'm currently using in ifTable_data_access.c when generating traps: netsnmp_access_interface_name_find(interface index) It works with LAN interfaces. But with WAN interfaces it does

Re: Using var_ifEntry() to get interfaces names

Hello, Sorry for a misleading detail and some typos in my last question. I wrote it quite fast just before leaving. Here are more precisions. For solving the problem described in the orignal question, I'm trying to use var_ifEntry() which is found in ../mibII/interfaces.c, hoping that it'll r

Help on getting an interface name

Hello all, In getName(int index) (mibgroup/tunnel.c) there are two ways to get the interface name. Here are excerpts: The first way: #ifndef USING_IF_MIB_IFTABLE_IFTABLE_MODULE oid name[MAX_OID_LEN] = { 1, 3, 6, 1, 2, 1, 2, 2, 1, 2 }; size_t length = 10; struct variable ifName_variable =

Re: Using var_ifEntry() to get interfaces names

On Sat, 30 May 2009 22:10:43 -0400, lanas wrote : > For solving the problem described in the orignal question, I'm > trying to use var_ifEntry() which is found in ../mibII/interfaces.c, > hoping that it'll return the proper interface name. OK, do not mind. The problem had

strdup() in sprintf() in patch 1775124 = memory leak

All, Just to let you know that 5.4.1 as shipped by Debian applies a patch # 1775124 that contains two strdup() inside a sprintf() statement in the netsnmp_udp_fmtaddr() method (plus one more) See: http://pastebin.ca/1701854. I reckon that this was fixed later (5.5. does not have it). Th

Re: strdup() in sprintf() in patch 1775124 = memory leak

Le Mardi, 22 Déc 2009 09:40:38 +0100, Magnus Fromreide a écrit : > On Mon, 2009-12-21 at 21:18 -0500, lanas wrote: > > All, > > > > Just to let you know that 5.4.1 as shipped by Debian applies a > > patch # 1775124 that contains two strdup() inside a spr

-e option in trapsess statement

Folks, Maybe the user mailing list was not the right place for this. I will file a bug about the following, if nobody explains otherwise. The -e option in trapsess (snmpd.conf) sets the contextEngineID. This is easily observable using tcpdumps. The -E option in trapsess also sets the conte

trapsess -e option and OCTET STRING

Hi all, The engineID (trapsess -e option) is defined as an OCTET STRING. Does this mean that it can be an hexadecimal ASCII string such as: 0x85643A5B ... so on ? Will snmpd convert the hex string to hex binary ? I'm asking because this field is seemingly defined as 32 bytes (RFC 3411). If it

Re: trapsess -e option and OCTET STRING

On Wed, 17 Feb 2010 09:27:51 +, Dave Shield wrote : > On 17 February 2010 00:41, lanas wrote: > >  The engineID (trapsess -e option) is defined as an OCTET STRING. > > Does this mean that it can be an hexadecimal ASCII string such as: > > 0x85643A5B ... so on ? [...] &g

Re: Memory leak in snmp_agent.c

Le Vendredi, 12 Mars 2010 17:38:37 -0800, Wes Hardaker a écrit : > You're right it's not. Generally there are a number of places in the > code (many many actually) where single-instance calls to memory > allocation are taken and never cleaned up like they should be at > shut-down time because we

NETLINK-based notifications

Hello all, I am aiming at integrating the NETLINK patch, submitted last year, to the latest version of net-snmp, in the coming two months. The purpose of this patch is to bring instant (relatively...) notifications when an interface is brought down/up. The patch works with a prior version of

send_linkUpDownNotifications() bug ?

Hello, I'm using the send_linkUpDownNotifications() to generate a trap when I got some information from the netlink system. When pulling an eth cable I thus get the following trap (note that the Admin and Oper values ares test values) : 9:41:10 TRAP:Cold Start from UDP: [10.159.9.37]:41278 TRA

Re: send_linkUpDownNotifications() bug ?

On Fri, 23 Jan 2009 20:19:44 -0500, lanas wrote : > I'm using the send_linkUpDownNotifications() to generate a trap when > I got some information from the netlink system. When pulling an > eth cable I thus get the following trap (note that the Admin and Oper > values ares test