Menu
▾
▴
net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(315) |
Dec
(298) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(254) |
Feb
(467) |
Mar
(430) |
Apr
(345) |
May
(406) |
Jun
(336) |
Jul
(313) |
Aug
(265) |
Sep
(433) |
Oct
(462) |
Nov
(387) |
Dec
(232) |
| 2002 |
Jan
(352) |
Feb
(556) |
Mar
(463) |
Apr
(500) |
May
(557) |
Jun
(337) |
Jul
(317) |
Aug
(279) |
Sep
(273) |
Oct
(354) |
Nov
(267) |
Dec
(347) |
| 2003 |
Jan
(351) |
Feb
(445) |
Mar
(520) |
Apr
(665) |
May
(499) |
Jun
(393) |
Jul
(304) |
Aug
(425) |
Sep
(262) |
Oct
(329) |
Nov
(220) |
Dec
(174) |
| 2004 |
Jan
(365) |
Feb
(479) |
Mar
(515) |
Apr
(522) |
May
(214) |
Jun
(471) |
Jul
(292) |
Aug
(341) |
Sep
(243) |
Oct
(446) |
Nov
(294) |
Dec
(147) |
| 2005 |
Jan
(171) |
Feb
(209) |
Mar
(218) |
Apr
(321) |
May
(233) |
Jun
(534) |
Jul
(268) |
Aug
(345) |
Sep
(498) |
Oct
(557) |
Nov
(459) |
Dec
(238) |
| 2006 |
Jan
(288) |
Feb
(180) |
Mar
(151) |
Apr
(113) |
May
(164) |
Jun
(277) |
Jul
(160) |
Aug
(383) |
Sep
(221) |
Oct
(404) |
Nov
(358) |
Dec
(163) |
| 2007 |
Jan
(293) |
Feb
(175) |
Mar
(202) |
Apr
(155) |
May
(427) |
Jun
(484) |
Jul
(414) |
Aug
(125) |
Sep
(131) |
Oct
(160) |
Nov
(79) |
Dec
(70) |
| 2008 |
Jan
(133) |
Feb
(115) |
Mar
(158) |
Apr
(194) |
May
(197) |
Jun
(230) |
Jul
(146) |
Aug
(68) |
Sep
(93) |
Oct
(53) |
Nov
(95) |
Dec
(69) |
| 2009 |
Jan
(81) |
Feb
(162) |
Mar
(215) |
Apr
(216) |
May
(78) |
Jun
(131) |
Jul
(61) |
Aug
(176) |
Sep
(127) |
Oct
(28) |
Nov
(83) |
Dec
(94) |
| 2010 |
Jan
(100) |
Feb
(187) |
Mar
(320) |
Apr
(161) |
May
(194) |
Jun
(142) |
Jul
(129) |
Aug
(139) |
Sep
(239) |
Oct
(202) |
Nov
(139) |
Dec
(196) |
| 2011 |
Jan
(195) |
Feb
(191) |
Mar
(201) |
Apr
(127) |
May
(84) |
Jun
(126) |
Jul
(101) |
Aug
(237) |
Sep
(123) |
Oct
(104) |
Nov
(197) |
Dec
(114) |
| 2012 |
Jan
(65) |
Feb
(85) |
Mar
(129) |
Apr
(84) |
May
(94) |
Jun
(83) |
Jul
(89) |
Aug
(85) |
Sep
(89) |
Oct
(73) |
Nov
(34) |
Dec
(38) |
| 2013 |
Jan
(89) |
Feb
(30) |
Mar
(25) |
Apr
(18) |
May
(20) |
Jun
(45) |
Jul
(74) |
Aug
(37) |
Sep
(72) |
Oct
(30) |
Nov
(67) |
Dec
(24) |
| 2014 |
Jan
(23) |
Feb
(16) |
Mar
(40) |
Apr
(37) |
May
(12) |
Jun
(18) |
Jul
(30) |
Aug
(26) |
Sep
(24) |
Oct
(32) |
Nov
(15) |
Dec
(33) |
| 2015 |
Jan
(15) |
Feb
(45) |
Mar
(21) |
Apr
(24) |
May
(22) |
Jun
(7) |
Jul
(57) |
Aug
(17) |
Sep
(16) |
Oct
(3) |
Nov
(8) |
Dec
(13) |
| 2016 |
Jan
(7) |
Feb
(14) |
Mar
(40) |
Apr
(8) |
May
(10) |
Jun
(6) |
Jul
(8) |
Aug
(10) |
Sep
(19) |
Oct
(20) |
Nov
(45) |
Dec
(10) |
| 2017 |
Jan
(10) |
Feb
(12) |
Mar
(3) |
Apr
(17) |
May
(41) |
Jun
(21) |
Jul
(13) |
Aug
(13) |
Sep
(7) |
Oct
(23) |
Nov
(10) |
Dec
(23) |
| 2018 |
Jan
(45) |
Feb
(3) |
Mar
(57) |
Apr
(107) |
May
(173) |
Jun
(47) |
Jul
(28) |
Aug
(26) |
Sep
(38) |
Oct
(56) |
Nov
(22) |
Dec
(11) |
| 2019 |
Jan
(37) |
Feb
(8) |
Mar
(7) |
Apr
(29) |
May
(32) |
Jun
(5) |
Jul
(21) |
Aug
(31) |
Sep
(38) |
Oct
(8) |
Nov
(13) |
Dec
(10) |
| 2020 |
Jan
(9) |
Feb
(33) |
Mar
(14) |
Apr
(4) |
May
(16) |
Jun
(11) |
Jul
(14) |
Aug
(50) |
Sep
(24) |
Oct
(3) |
Nov
(14) |
Dec
(13) |
| 2021 |
Jan
(18) |
Feb
(15) |
Mar
(12) |
Apr
(9) |
May
(9) |
Jun
(8) |
Jul
(6) |
Aug
(7) |
Sep
(26) |
Oct
(17) |
Nov
(6) |
Dec
(2) |
| 2022 |
Jan
(3) |
Feb
(11) |
Mar
(7) |
Apr
(15) |
May
(5) |
Jun
(4) |
Jul
(29) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(4) |
Dec
(1) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(3) |
Jun
(5) |
Jul
(3) |
Aug
(10) |
Sep
(10) |
Oct
(7) |
Nov
(2) |
Dec
(4) |
| 2024 |
Jan
(22) |
Feb
(5) |
Mar
(11) |
Apr
(20) |
May
(16) |
Jun
(9) |
Jul
(14) |
Aug
(5) |
Sep
(7) |
Oct
(4) |
Nov
(3) |
Dec
|
| 2025 |
Jan
(6) |
Feb
(6) |
Mar
(14) |
Apr
(2) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bart V. A. <bva...@ac...> - 2019-07-08 13:52:57
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Bill,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">To avoid confusion: does your comment
apply to commit a88d81f1144e ("NET-SNMP-SYSTEM-MIB, Linux: Update
calculation of free space") only or also to commit 4e3ace87b566
("NET-SNMP-SYSTEM-MIB: Account reclaimable space")?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Bart.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 7/8/19 5:18 AM, Bill Fenner via
Net-snmp-coders wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF...@ma...">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">There's a long history of telling people "You're
polling a Linux system, you have to know that you subtract
buffers and cached from physical before you report free
memory" in the HOST-RESOURCES-MIB. I'm not against
simplifying, but - if people have data collection set up for
"the old way", where you have to subtract buffers and cached
after collecting them, then this change will result in
double-subtraction.
<div><br>
</div>
<div>In Arista EOS we handled this by adding another row to
the table, to avoid breaking existing data collection when
someone upgrades.</div>
<div><br>
</div>
<div> Bill</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019 at 12:27
AM net-snmp Git repository <<a
href="mailto:no...@co..."
moz-do-not-send="true">no...@co...</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="gmail-m_-1493749843583364338markdown_content">
<h2 id="gmail-m_-1493749843583364338branch-v5-8-patches">Branch:
V5-8-patches</h2>
<div class="gmail-m_-1493749843583364338markdown_content">
<p>NET-SNMP-SYSTEM-MIB, Linux: Update calculation of
free space</p>
<p>Update calculation of free space for Physical and
Virtual memory on linux.<br>
Based on <a
href="https://gitlab.com/procps-ng/procps/blob/master/proc/sysinfo.c#L789"
target="_blank" moz-do-not-send="true">https://gitlab.com/procps-ng/procps/blob/master/proc/sysinfo.c#L789</a></p>
<p><span>[ bvanassche: edited patch subject ]</span></p>
</div>
<p>By Josef Ridky on 07/04/2019 06:45<br>
<a
href="https://sourceforge.net/p/net-snmp/code/ci/a88d81f1144ecf33f0ca02ada042b77368855a94/"
target="_blank" moz-do-not-send="true"><strong>View
Changes</strong></a></p>
<hr>
<h2 id="gmail-m_-1493749843583364338branch-master">Branch:
master</h2>
<div class="gmail-m_-1493749843583364338markdown_content">
<p>Merge branch 'V5-8-patches'</p>
<p>* V5-8-patches:<br>
NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free
space</p>
</div>
<p>By Bart Van Assche on 07/08/2019 04:15<br>
<a
href="https://sourceforge.net/p/net-snmp/code/ci/8d5cdf8aeb6b3521e09b2f2a921ed5061da221e9/"
target="_blank" moz-do-not-send="true"><strong>View
Changes</strong></a></p>
<hr>
<p>Sent from <a href="http://sourceforge.net"
target="_blank" moz-do-not-send="true">sourceforge.net</a>
because you indicated interest in <a
href="https://sourceforge.net/p/net-snmp/code/"
target="_blank" moz-do-not-send="true">https://sourceforge.net/p/net-snmp/code/</a></p>
<p>To unsubscribe from further messages, please visit <a
href="https://sourceforge.net/auth/subscriptions/"
target="_blank" moz-do-not-send="true">https://sourceforge.net/auth/subscriptions/</a></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>
|
|
From: Bill F. <fe...@us...> - 2019-07-08 12:18:09
|
There's a long history of telling people "You're polling a Linux system, you have to know that you subtract buffers and cached from physical before you report free memory" in the HOST-RESOURCES-MIB. I'm not against simplifying, but - if people have data collection set up for "the old way", where you have to subtract buffers and cached after collecting them, then this change will result in double-subtraction. In Arista EOS we handled this by adding another row to the table, to avoid breaking existing data collection when someone upgrades. Bill On Mon, Jul 8, 2019 at 12:27 AM net-snmp Git repository < no...@co...> wrote: > Branch: V5-8-patches > > NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free space > > Update calculation of free space for Physical and Virtual memory on linux. > Based on > https://gitlab.com/procps-ng/procps/blob/master/proc/sysinfo.c#L789 > > [ bvanassche: edited patch subject ] > > By Josef Ridky on 07/04/2019 06:45 > *View Changes* > <https://sourceforge.net/p/net-snmp/code/ci/a88d81f1144ecf33f0ca02ada042b77368855a94/> > ------------------------------ > Branch: master > > Merge branch 'V5-8-patches' > > * V5-8-patches: > NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free space > > By Bart Van Assche on 07/08/2019 04:15 > *View Changes* > <https://sourceforge.net/p/net-snmp/code/ci/8d5cdf8aeb6b3521e09b2f2a921ed5061da221e9/> > ------------------------------ > > Sent from sourceforge.net because you indicated interest in > https://sourceforge.net/p/net-snmp/code/ > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > |
|
From: Alexander R. <AR...@ad...> - 2019-07-03 06:08:49
|
Hi, It seems, that there is a memory leak when reconfiguration by SIGHUP signal. To reproduce and debug the issue I propose the following patch: diff -rBbNuw -X ../Exclude net-snmp-5.8.org/agent/agent_read_config.c net-snmp-5.8/agent/agent_read_config.c --- net-snmp-5.8.org/agent/agent_read_config.c 2018-07-16 17:33:40.000000000 +0300 +++ net-snmp-5.8/agent/agent_read_config.c 2019-07-02 10:51:34.219251554 +0300 @@ -304,10 +304,12 @@ void update_config(void) { + snmp_dump_session_list (__func__, __LINE__); snmp_call_callbacks(SNMP_CALLBACK_APPLICATION, SNMPD_CALLBACK_PRE_UPDATE_CONFIG, NULL); free_config(); read_configs(); + snmp_dump_session_list (__func__, __LINE__); } diff -rBbNuw -X ../Exclude net-snmp-5.8.org/include/net-snmp/session_api.h net-snmp-5.8/include/net-snmp/session_api.h --- net-snmp-5.8.org/include/net-snmp/session_api.h 2018-07-16 17:33:40.000000000 +0300 +++ net-snmp-5.8/include/net-snmp/session_api.h 2019-07-02 10:51:44.091262681 +0300 @@ -28,6 +28,10 @@ NETSNMP_IMPORT void snmp_sess_init(netsnmp_session *); + + + int snmp_dump_session_list (const char * func, int line); /* for debug */ + /* * netsnmp_session *snmp_open(session) * netsnmp_session *session; diff -rBbNuw -X ../Exclude net-snmp-5.8.org/snmplib/snmp_api.c net-snmp-5.8/snmplib/snmp_api.c --- net-snmp-5.8.org/snmplib/snmp_api.c 2018-07-16 17:33:40.000000000 +0300 +++ net-snmp-5.8/snmplib/snmp_api.c 2019-07-02 10:50:54.551213214 +0300 @@ -990,6 +990,20 @@ _init_snmp_init_done = 0; } +int snmp_dump_session_list (const char * func, int line) +{ + int indx = 0; + struct session_list *slp = Sessions; + + snmp_log(LOG_INFO, "%s(%d) %s Sessions=%p \n", func, line, __func__, Sessions); + + for (slp = Sessions; slp; slp = slp->next) { + snmp_log(LOG_INFO, " %d. slp=%p peer=<%s>\n", (int) ++indx, slp, slp->session->peername); + } + return indx; +} + + /* * inserts session into session list */ If some of file snmpd.conf contains the line, for example, 'trapsess -v 2c -c public 1.2.3.4" and the process snmpd receives SIGHUP, then in /var/log/snmpd.log we see: ... Reconfiguring daemon NET-SNMP version 5.8 restarted update_config(307) snmp_dump_session_list Sessions=0x55aa58c82930 1. slp=0x55aa58c82930 peer=<(null)> 2. slp=0x55aa58c73790 peer=<1.2.3.4> 3. slp=0x55aa58c6bab0 peer=<(null)> 4. slp=0x55aa58b528d0 peer=<(null)> update_config(312) snmp_dump_session_list Sessions=0x55aa58c83bf0 1. slp=0x55aa58c83bf0 peer=<1.2.3.4> 2. slp=0x55aa58c82930 peer=<(null)> 3. slp=0x55aa58c73790 peer=<1.2.3.4> 4. slp=0x55aa58c6bab0 peer=<(null)> 5. slp=0x55aa58b528d0 peer=<(null)> ... As a solution, I would suggest the following simple patch: diff -rBbNuw -X ../Exclude net-snmp-5.8.org/agent/mibgroup/notification/snmpNotifyTable_data.c net-snmp-5.8/agent/mibgroup/notification/snmpNotifyTable_data.c --- net-snmp-5.8.org/agent/mibgroup/notification/snmpNotifyTable_data.c 2018-07-16 17:33:40.000000000 +0300 +++ net-snmp-5.8/agent/mibgroup/notification/snmpNotifyTable_data.c 2019-07-03 08:17:05.953676342 +0300 @@ -511,6 +511,7 @@ } } snmpNotifyTableStorage = NULL; + shutdown_snmpTargetAddrEntry_data(); // AR...@ad... return (0); } Thank you, Alex |
|
From: Sam T. <sta...@cu...> - 2019-06-26 18:43:08
|
Bill, Bart,
Shouldn't there be a check (netsnmp_handler_check_cache)
just before snmp_async_send to make sure the cb_data is still
valid (or that the session hasn't been disconnected)?
I'm assuming (with good evidence) that our subagent
session was disconnected (our subagent has a problem)
and something was freed...and we attempt to free cb_data
again and core dump. So at the bottom of agentx_got_response():
/*
* When the master sends a CleanupSet PDU, it will never get a response
* back from the subagent. So we shouldn't allocate the
* netsnmp_delegated_cache structure in this case.
*/
if (pdu->command != AGENTX_MSG_CLEANUPSET)
cb_data = netsnmp_create_delegated_cache(handler, reginfo,
reqinfo, requests,
(void *) ax_session);
else
cb_data = NULL;
*/* some checks */*
* cache = netsnmp_handler_check_cache(cb_data); if (!cache) {
DEBUGMSGTL(("agentx/master", "session may be disconnected %8p\n",
session)); /* response is too late, perhaps session was
disconnected? */ if (cb_data)
netsnmp_free_delegated_cache((netsnmp_delegated_cache*) magic);
return 1; }*
*/* end checks */*
/*
* send the requests out.
*/
DEBUGMSGTL(("agentx/master", "sending pdu
(req=0x%x,trans=0x%x,sess=0x%x)\n",
(unsigned)pdu->reqid, (unsigned)pdu->transid,
(unsigned)pdu->sessid));
result = snmp_async_send(ax_session, pdu, agentx_got_response, cb_data);
if (result == 0) {
snmp_free_pdu(pdu);
if (cb_data)
netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
cb_data);
}
return SNMP_ERR_NOERROR;
--Sam
On Tue, Jun 25, 2019 at 3:38 PM Sam Tannous <sta...@cu...>
wrote:
>
> I'm still not able to recreate this bug (#2943) where we
> double free cb_data at the bottom of agentx_master_handler()
> (with the netsnmp_free_delegated_cache()).
>
> Just in looking at the code logic, it seems like we allocate
> the netsnmp_delegated_cache structure only if the master
> sent a CleanupSet PDU. In the case I'm looking at, I can
> see the master has already disconnected the subagent:
>
> bgpd[5180]: snmp[info]: AgentX master disconnected us, reconnecting in 15
> ip[8042]: *** Error in `/usr/sbin/snmpd': double free or corruption
> (fasttop): 0x0000000001d15420 ***
> zebra[21794]: snmp[info]: AgentX master disconnected us, reconnecting in 15
>
> So when this happens, the master attempts to close_agentx_session().
> My best guess (without being able to recreate this) is that this structure
> is freed here first. Is it possible to somehow protect the session
> (and all subsessions) from being freed if there the master is in the
> process
> of allocating netsnmp_delegated_cache?
>
> Can we set something like AGENTX_MSG_CLEANUPSET if we have
> disconnected (or timed out) any/all subagents? This is just to prevent the
> double free that happens at the end of agentx_master_handler().
>
> Thanks,
> Sam
>
>
>
>
|
|
From: Sam T. <sta...@cu...> - 2019-06-25 20:05:40
|
I'm still not able to recreate this bug (#2943) where we double free cb_data at the bottom of agentx_master_handler() (with the netsnmp_free_delegated_cache()). Just in looking at the code logic, it seems like we allocate the netsnmp_delegated_cache structure only if the master sent a CleanupSet PDU. In the case I'm looking at, I can see the master has already disconnected the subagent: bgpd[5180]: snmp[info]: AgentX master disconnected us, reconnecting in 15 ip[8042]: *** Error in `/usr/sbin/snmpd': double free or corruption (fasttop): 0x0000000001d15420 *** zebra[21794]: snmp[info]: AgentX master disconnected us, reconnecting in 15 So when this happens, the master attempts to close_agentx_session(). My best guess (without being able to recreate this) is that this structure is freed here first. Is it possible to somehow protect the session (and all subsessions) from being freed if there the master is in the process of allocating netsnmp_delegated_cache? Can we set something like AGENTX_MSG_CLEANUPSET if we have disconnected (or timed out) any/all subagents? This is just to prevent the double free that happens at the end of agentx_master_handler(). Thanks, Sam |
|
From: Bill F. <fe...@gm...> - 2019-06-19 22:28:16
|
The memory leak is gone in the current V5-8-patches. I have not dug into trying to bisect which change fixed it. Bill On Tue, May 14, 2019 at 7:01 AM Bill Fenner <fe...@gm...> wrote: > Perhaps getbulk no longer dumps core, but I can not get it to return > anything but GENERR any more, and, it seems to leak memory. > > Any "large enough" request seems to fail in this way, e.g., snmpbulkget -v > 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime sysUpTime sysUpTime .1 > > This is particularly frustrating because code was added to 5.8 to rebuild > a getbulk reply if it's too big. But there was already code to not build > the PDU too big, it's just not taking the v3 header into account properly > (that's my best guess, at least). So now there are two different > mechanisms to send a "right-size" reply and they both don't work. Around > 5.8 release time I was working with Robert Story to fix this, but that > effort kind of petered out and Robert's work didn't make it into git. > > Can anyone get getbulk to work in the current 5.8-patches with SNMPv3? > > I've attached a test script with 504 failing test cases when I run it > against an unmodified V5-8-patches branch, and net-snmp leaks about a meg > of RAM during the test. This is an adaptation of my internal test to the > net-snmp test framework; the complete test would use all supported values > for -l, -a, -x but for now this is the simplest one using nanp. > > Thanks, > Bill > > > > > On Wed, Apr 10, 2019 at 10:25 AM Bart Van Assche < > bva...@us...> wrote: > >> This patch has been applied on the v5.8 and master branches. Thanks for >> the patch! >> ------------------------------ >> >> * [patches:#1388] <https://sourceforge.net/p/net-snmp/patches/1388/> >> patch for bug 2923: snmpv3 bulkget errors result in double free core dump* >> >> *Status:* open >> *Group:* backport-needed >> *Created:* Tue Mar 05, 2019 09:56 AM UTC by Sam Tannous >> *Last Updated:* Tue Mar 05, 2019 09:56 AM UTC >> *Owner:* nobody >> *Attachments:* >> >> - v3doublefree2.patch >> <https://sourceforge.net/p/net-snmp/patches/1388/attachment/v3doublefree2.patch> >> (14.2 kB; application/octet-stream) >> >> This is a patch for https://sourceforge.net/p/net-snmp/bugs/2923/ when >> almost any v3 bulkget >> error will cause a core dump of snmpd. >> ------------------------------ >> >> Sent from sourceforge.net because you indicated interest in >> https://sourceforge.net/p/net-snmp/patches/1388/ >> >> To unsubscribe from further messages, please visit >> https://sourceforge.net/auth/subscriptions/ >> > |
|
From: Krishna C. <cha...@gm...> - 2019-06-10 15:37:59
|
On Thu, May 30, 2019 at 2:51 PM Krishna Chaitanya <cha...@gm...> wrote: > > Hi, > > I am just starting on SNMP and have a query on how to implement tables. > > I did go through forum messages and examples found below to be > helpful, but still, have doubts. > > https://sourceforge.net/p/net-snmp/mailman/message/33480025/ (This was helpful) > examples/mibgroup/netSnmpHostsTable.c > > I have a single API which will get 3 different types of stats (A, B, C) and each > stats can have multiple instances, so I have made 3 different tables (A, B, C). > > a) providing complete row > I want to provide the latest stats every time a request is made > (snmpwalk/snmptable). For that > I have registered a handler for each table and inside the handler, > fetching the stats. > But the problem is that the handler is called for every column? So, > for efficiency sake > I need to run a separate thread to fetch and fill only the column > asked in the handler? Is there a better approach? Like can I submit > the entire row at once? > > b) replace row asserts > FYI, I am using data_set tables it already has a handler but as I want > to update the table > with new values, I am doing a replace row (it causes duplicate warnings). > > Any help is appreciated. Thanks. > After spending some more time, able to get below optimizations: FYI, I am using table_data_set tables. In my custom table handler, I am doing below pseudo code: Is this the preferred approach? for (requests) //Try to update full row at once. if table->colnum != LAST_COL continue; //fetch existing row for (rows) row->index == table_info->index old_row = row break; row = fetch_and_prepare_data() replace (old_row, row) |
|
From: Krishna C. <cha...@gm...> - 2019-06-10 15:20:53
|
Hi,
I am running an SNMP subagent using agentX protocol and all MIB values
of type Counter64 as shown in big_endian order even though my desktop
is Intel (little endian).
The basic problem arises because Counter64 is not a direct data type
rather its a struct {high, low} and the value is stored using memmove
which copies the LSB into high.
Sample code is below:
int64_t a = 99;
snmp_set_var_typed_value (..ASN_COUNTER64, & a);
If I explicitly set is as below, it works. But doing this for many
variables and explicitly copying to high/low is cumbersome.
struct counter64 a = {0, 99};
snmp_set_var_typed_value (..ASN_COUNTER64, & a);
Is there a way we can use int64_t and get little endian?
P.S. During my search, I did come across code handling Endianess based
on session.flags (AGENTX_MSG_FLAG_NETWORK_BYTE_ORDER) but
snmp_pdu_create doesn't set those flags.
--
Thanks,
Regards,
Chaitanya T K.
|
|
From: Krishna C. <cha...@gm...> - 2019-05-30 09:22:11
|
Hi, I am just starting on SNMP and have a query on how to implement tables. I did go through forum messages and examples found below to be helpful, but still, have doubts. https://sourceforge.net/p/net-snmp/mailman/message/33480025/ (This was helpful) examples/mibgroup/netSnmpHostsTable.c I have a single API which will get 3 different types of stats (A, B, C) and each stats can have multiple instances, so I have made 3 different tables (A, B, C). a) providing complete row I want to provide the latest stats every time a request is made (snmpwalk/snmptable). For that I have registered a handler for each table and inside the handler, fetching the stats. But the problem is that the handler is called for every column? So, for efficiency sake I need to run a separate thread to fetch and fill only the column asked in the handler? Is there a better approach? Like can I submit the entire row at once? b) replace row asserts FYI, I am using data_set tables it already has a handler but as I want to update the table with new values, I am doing a replace row (it causes duplicate warnings). Any help is appreciated. Thanks. -- Thanks, Regards, Chaitanya T K. |
|
From: Simon C. <sim...@mp...> - 2019-05-24 15:02:01
|
Hi, According to the following synopsis https://www.akamai.com/us/en/multimedia/documents/state-of-the-internet/snmp-reflector-attacks-threat-advisory.pdf The remote SNMP daemon is responding with a large amount of data to a 'GETBULK' request with a larger than normal value for 'max-repetitions'. A remote attacker can use this SNMP server to conduct a reflected distributed denial of service attack on an arbitrary remote host. What is the actual ’max-repetitions' of NET-SNMP version 5.7.1 ? Is this value the same for version 5.8.x ? Thanks, Simon |
|
From: Arun K. <aru...@gm...> - 2019-05-23 06:37:24
|
Thank you Anders wallin. Could you please give me some reference for snmp agent configuration on linux. Request you to provide linux snmp agent rpms On Thu, May 23, 2019, 12:03 Anders Wallin <wal...@gm...> wrote: > Hi Arun, > > your request needs to be more specific to get an answer, but that said, > start by reading > http://net-snmp.sourceforge.net/wiki/index.php/Tutorials > > Regards > Anders Wallin > > > On Wed, May 22, 2019 at 5:23 PM Arun Kumar <aru...@gm...> wrote: > >> Dear friends, >> >> i want to configure snmp configuration on linux. can you please help me >> configuration of mibs and other details. Thanks! >> _______________________________________________ >> Net-snmp-coders mailing list >> Net...@li... >> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders >> > |
|
From: Anders W. <wal...@gm...> - 2019-05-23 06:33:38
|
Hi Arun, your request needs to be more specific to get an answer, but that said, start by reading http://net-snmp.sourceforge.net/wiki/index.php/Tutorials Regards Anders Wallin On Wed, May 22, 2019 at 5:23 PM Arun Kumar <aru...@gm...> wrote: > Dear friends, > > i want to configure snmp configuration on linux. can you please help me > configuration of mibs and other details. Thanks! > _______________________________________________ > Net-snmp-coders mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > |
|
From: Ming C. <Min...@wa...> - 2019-05-22 21:13:45
|
When the parent_data is NULL, which indicates there is no table entry for this request, and then usually, they will call "netsnmp_set_request_error(reqinfo, request,SNMP_NOSUCHINSTANCE)" to set the VB type to "NO SUCH INSTANCE" in your Table Handler function - please check your private table handler code. Also, you need to call netsnmp_set_request_error(reqinfo, request, SNMP_NOSUCHOBJECT) to set the VB type to "NO SUCH OBJECT" in your Table Handler function, when the column is out of range. Thanks, Ming From: Jaka Simonic <Jak...@Av...> Sent: Thursday, May 16, 2019 6:15 AM To: net...@li... Subject: snmpa agent get_next bad oid combination Hi! We are using version 5.7.3 on an embedded system. We noticed segmentation errors in our dynamically loded module. The issue was that one of the requests had null pointer at parent_data. The issue can be reproduced on any table i.e. >snmpgetnext -v2c -c public x.x.x.x 1.3.6.1.4.1.2509.9.15.2.3.1.13 1.3.6.1.4.1.2509.9.15.2.3.1.12< (the first oid is pointing at nonexistent "column" and second one is a valid oid). The nonexistent oid appears in the requests linked list as a request with parent_data null and processed with value 1. (gdb) x/64xb 0x1e733f8 0xbb45b8: 0xd8 0xf9 0xbf 0x00 0x00 0x00 0x00 0x00 0xbb45c0: 0xb8 0xb1 0x9f 0x00 0x10 0xe3 0xad 0x00 0xbb45c8: 0x09 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xbb45d0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xbb45d8: 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0xbb45e0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xbb45e8: 0xd8 0xf9 0xbf 0x00 0xf8 0x45 0xbb 0x00 0xbb45f0: 0x00 0x00 0x00 0x00 0x60 0xe2 0xad 0x00 Usually getnext on a >nonexistent column< oid returns >No Such Object available...< without calling our linked module. Is this a bug? Can you please adivse me how to handle this situation when encountered? Best regards, Jaka Simonic p.s. this should give additional clarification This only happens when oids are pointing at the same table and one of them is pointing at nonexistent column and another at an existing column. Otherwise the agent resolves the situation with appropriate messages. Here all of oid are nonexistent: snmpgetnext -v2c -c public x.x.x.x iso.3.6.1.4.1.2509.9.15.2.3.1.14.59.2001.1.5 iso.3.6.1.4.1.2509.9.15.2.3.1.14.59.2001.1.7 1.0.8802.1.1.2.1.4.1.1.91.0.8802.1.1.2.1.4.1.1.8 iso.3.6.1.4.1.2509.9.15.2.3.1.14.59.2001.1.5 = No Such Object available on this agent at this OID iso.3.6.1.4.1.2509.9.15.2.3.1.14.59.2001.1.7 = No Such Object available on this agent at this OID iso.0.8802.1.1.2.1.4.1.1.91.0.8802.1.1.2.1.4.1.1.8 = No Such Object available on this agent at this OID |
|
From: Venkateswarlu K. <ven...@gm...> - 2019-05-21 03:50:19
|
Hi Dan Pattison, In my machine i don't have /etc/hostname .But i am reading hostname from my API and updating it in sysName before calling the netsnmp_create_update_handler_registration But i am seeing that when i do snmpwalk it's directly calling netsnmp_create_update_handler_registration API. Suspecting that due to this one its not updating the sysName. Same behavior i am seeing for sysLocation and sysContact also. Thanks, Venkateswarlu.K On Mon, May 20, 2019 at 10:16 AM Dan Pattison <dan...@et...> wrote: > Hello Venkat, > > Are you changing the hostname by editing the /etc/hostname file directly > or by using the hostname command? > > Regards, > > Dan Pattison > > On 2019-05-19 9:04 p.m., Venkateswarlu Konamki wrote: > > Hi All, > Any update on this issue? > > Thanks, > Venkat > > > On Thu, May 16, 2019 at 10:40 AM Venkateswarlu Konamki < > ven...@gm...> wrote: > >> Hi All , >> >> I am facing issue with in system_mib with SysName and SysLocation. >> >> Recently i have upgraded net-snmp version from 5.3.01 to 5.7.3. In 5.7.3, >> if i see the code is system_mib there are changes happened for handling >> the mibs. >> >> First time when i am doing snmp walk i am able to get the correct >> hostname and syslocation. >> Next i have changed the hostname with CLI (not via snmpset). when i do >> snmpwlak or get, hostname is still showing the old name. >> >> *Before changing the hostname : * >> # snmpget -v2c -c test localhost .1.3.6.1.2.1.1.5.0 >> .1.3.6.1.2.1.1.5.0 = STRING: "Venkat_Desktop" >> # >> administrator@Venkat:~$ hostname >> Venkat_Desktop. >> >> *After changing the hostname from Venkat_Desktop to "Venkat_machine"* >> # snmpget -v2c -c test localhost .1.3.6.1.2.1.1.5.0 >> .1.3.6.1.2.1.1.5.0 = STRING: "Venkat_Desktop" >> # >> administrator@Venkat:~$ hostname >> Venkat_machine. >> >> It is reflecting in hostname, but when i do via snmp it is still showing >> the old hostname. >> >> I am notable to find the root cause for this one. >> >> Is any one faced same issue ? if yes. what is the fix for this ? Please >> help on this >> >> >> Thanks, >> >> Venkat >> > > > _______________________________________________ > Net-snmp-coders mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > > > _______________________________________________ > Net-snmp-coders mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > |
|
From: Bill F. <fe...@gm...> - 2019-05-20 16:02:36
|
To try to make it easier I've created a fake pull request, allowing comments on the diff and discussion, and a clear set of diffs between this stuff and 5.8-patches: https://github.com/fenner/net-snmp/pull/3 Bill On Mon, May 20, 2019 at 11:27 AM Bill Fenner <fe...@gm...> wrote: > Some of the back and forth with rstory happened on the admin list; some of > it was unicast. I put together all of the patches, even though there are > now at least 2 fixes for the problem, and published them at > https://github.com/fenner/net-snmp/commits/rstory-getbulk-patches . > > I can't imagine that the changes are useful as they are (other than the > added debugging, perhaps) but may be useful to see what kinds of things we > ran into. > > And my opinion remains that the fundamental problem here is that the > reverse encoding knows how to stop encoding in time, but doesn't know about > the overhead that usm adds, and for some reason the changes in 5.8 try to > address this by switching to forward encoding, which relies on the state > that was freed (and really probably only helps because forward encoding > uses a fixed-sized 1472-byte buffer). (It's possible that the delayed free > that Sam introduced helps the "state that was freed" part. With 3 > different solutions for the problem it's hard to figure out exactly how to > proceed.) > > Bill > > > On Mon, May 20, 2019 at 9:28 AM Bill Fenner <fe...@gm...> wrote: > >> On Tue, May 14, 2019 at 1:38 PM Bart Van Assche <bva...@ac...> >> wrote: >> >>> On 5/14/19 4:01 PM, Bill Fenner wrote: >>> > Perhaps getbulk no longer dumps core, but I can not get it to return >>> > anything but GENERR any more, and, it seems to leak memory. >>> > >>> > Any "large enough" request seems to fail in this way, e.g., >>> > snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime >>> > sysUpTime sysUpTime .1 >>> > >>> > This is particularly frustrating because code was added to 5.8 to >>> > rebuild a getbulk reply if it's too big. But there was already code >>> > to not build the PDU too big, it's just not taking the v3 header into >>> > account properly (that's my best guess, at least). So now there are >>> > two different mechanisms to send a "right-size" reply and they both >>> > don't work. Around 5.8 release time I was working with Robert Story >>> > to fix this, but that effort kind of petered out and Robert's work >>> > didn't make it into git. >>> > >>> > Can anyone get getbulk to work in the current 5.8-patches with SNMPv3? >>> > >>> > I've attached a test script with 504 failing test cases when I run it >>> > against an unmodified V5-8-patches branch, and net-snmp leaks about a >>> > meg of RAM during the test. This is an adaptation of my internal test >>> > to the net-snmp test framework; the complete test would use all >>> > supported values for -l, -a, -x but for now this is the simplest one >>> > using nanp. >>> >>> >>> Hi Bill, >>> >>> A new test has been added >>> (testing/fulltests/default/T0221snmpbulkget_large_simple). That test >>> passes on my setup. Can you have a look whether that test covers the >>> issue you ran into? >>> >> >> It doesn't - the problems arise when the agent decides that the message >> is too big and doesn't fit in the buffer. (E.g., the usage >> of --sendMessageMaxSize in my test, or, the repetition of .1 .1 .1 .1 on >> the snmpbulkget command line). >> >> Regarding the "memory leak": RSS is not a reliable source of information >>> to detect memory leaks. If you want to verify whether or not a new >>> memory leak has been introduced please use Valgrind. >>> >> >> Yes, my internal test uses valgrind and shows the leaks, I was using RSS >> growth as a proxy. I also used a script something like >> http://www.net-snmp.org/wiki/index.php/Running_Net-SNMP_Regression_Tests_under_Valgrind and >> it showed leaks when I ran the test that I sent, e.g., >> >> ==32438== 31,584 (8,736 direct, 22,848 indirect) bytes in 168 blocks are >> definitely lost in loss record 756 of 758 >> ==32438== at 0x402D05E: calloc (vg_replace_malloc.c:711) >> ==32438== by 0x430EA7A: usm_malloc_usmStateReference (snmpusm.c:288) >> ==32438== by 0x43117A7: usm_process_in_msg (snmpusm.c:2431) >> ==32438== by 0x4312B44: usm_secmod_process_in_msg (snmpusm.c:2335) >> ==32438== by 0x42D45EF: snmpv3_parse (snmp_api.c:3938) >> >> When I run your new test, I agree it passes: >> ~/src/test-for-bart/testing @fenner-test-for-bart.sjc% ./RUNFULLTESTS -r >> T0221 >> large SNMPv3 bulkget .. ok >> >> If I add "--sendMessageMaxSize=1472", then it fails in the same way as my >> test fails: returning genError. >> >> Your subsequent patch may address this problem if the manager does not >> specify a max response size, but as this is part of the SNMPv3 protocol and >> we do not necessarily control what the manager does, it's not sufficient. >> >> Bill >> >> |
|
From: Bill F. <fe...@gm...> - 2019-05-20 15:27:41
|
Some of the back and forth with rstory happened on the admin list; some of it was unicast. I put together all of the patches, even though there are now at least 2 fixes for the problem, and published them at https://github.com/fenner/net-snmp/commits/rstory-getbulk-patches . I can't imagine that the changes are useful as they are (other than the added debugging, perhaps) but may be useful to see what kinds of things we ran into. And my opinion remains that the fundamental problem here is that the reverse encoding knows how to stop encoding in time, but doesn't know about the overhead that usm adds, and for some reason the changes in 5.8 try to address this by switching to forward encoding, which relies on the state that was freed (and really probably only helps because forward encoding uses a fixed-sized 1472-byte buffer). (It's possible that the delayed free that Sam introduced helps the "state that was freed" part. With 3 different solutions for the problem it's hard to figure out exactly how to proceed.) Bill On Mon, May 20, 2019 at 9:28 AM Bill Fenner <fe...@gm...> wrote: > On Tue, May 14, 2019 at 1:38 PM Bart Van Assche <bva...@ac...> > wrote: > >> On 5/14/19 4:01 PM, Bill Fenner wrote: >> > Perhaps getbulk no longer dumps core, but I can not get it to return >> > anything but GENERR any more, and, it seems to leak memory. >> > >> > Any "large enough" request seems to fail in this way, e.g., >> > snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime >> > sysUpTime sysUpTime .1 >> > >> > This is particularly frustrating because code was added to 5.8 to >> > rebuild a getbulk reply if it's too big. But there was already code >> > to not build the PDU too big, it's just not taking the v3 header into >> > account properly (that's my best guess, at least). So now there are >> > two different mechanisms to send a "right-size" reply and they both >> > don't work. Around 5.8 release time I was working with Robert Story >> > to fix this, but that effort kind of petered out and Robert's work >> > didn't make it into git. >> > >> > Can anyone get getbulk to work in the current 5.8-patches with SNMPv3? >> > >> > I've attached a test script with 504 failing test cases when I run it >> > against an unmodified V5-8-patches branch, and net-snmp leaks about a >> > meg of RAM during the test. This is an adaptation of my internal test >> > to the net-snmp test framework; the complete test would use all >> > supported values for -l, -a, -x but for now this is the simplest one >> > using nanp. >> >> >> Hi Bill, >> >> A new test has been added >> (testing/fulltests/default/T0221snmpbulkget_large_simple). That test >> passes on my setup. Can you have a look whether that test covers the >> issue you ran into? >> > > It doesn't - the problems arise when the agent decides that the message is > too big and doesn't fit in the buffer. (E.g., the usage > of --sendMessageMaxSize in my test, or, the repetition of .1 .1 .1 .1 on > the snmpbulkget command line). > > Regarding the "memory leak": RSS is not a reliable source of information >> to detect memory leaks. If you want to verify whether or not a new >> memory leak has been introduced please use Valgrind. >> > > Yes, my internal test uses valgrind and shows the leaks, I was using RSS > growth as a proxy. I also used a script something like > http://www.net-snmp.org/wiki/index.php/Running_Net-SNMP_Regression_Tests_under_Valgrind and > it showed leaks when I ran the test that I sent, e.g., > > ==32438== 31,584 (8,736 direct, 22,848 indirect) bytes in 168 blocks are > definitely lost in loss record 756 of 758 > ==32438== at 0x402D05E: calloc (vg_replace_malloc.c:711) > ==32438== by 0x430EA7A: usm_malloc_usmStateReference (snmpusm.c:288) > ==32438== by 0x43117A7: usm_process_in_msg (snmpusm.c:2431) > ==32438== by 0x4312B44: usm_secmod_process_in_msg (snmpusm.c:2335) > ==32438== by 0x42D45EF: snmpv3_parse (snmp_api.c:3938) > > When I run your new test, I agree it passes: > ~/src/test-for-bart/testing @fenner-test-for-bart.sjc% ./RUNFULLTESTS -r > T0221 > large SNMPv3 bulkget .. ok > > If I add "--sendMessageMaxSize=1472", then it fails in the same way as my > test fails: returning genError. > > Your subsequent patch may address this problem if the manager does not > specify a max response size, but as this is part of the SNMPv3 protocol and > we do not necessarily control what the manager does, it's not sufficient. > > Bill > > |
|
From: Anders W. <wal...@gm...> - 2019-05-20 14:31:44
|
I think that syntax will give you the octal value of "010", which will be decimal 8, so it will try to send to 192.168.1.8 Regards Anders Wallin On Mon, May 20, 2019 at 3:58 PM Deepak Sachan <sac...@gm...> wrote: > Heĺlo > In snmpd.conf trap server address is defined as > Trap2sink 192.168.1.10 public 162 > If i edit the snmpd.conf file and changed address to 192.168.1.010 then > traps are not received at trap receiver. > Help required. > Thanks in advance > _______________________________________________ > Net-snmp-users mailing list > Net...@li... > Please see the following page to unsubscribe or change other options: > https://lists.sourceforge.net/lists/listinfo/net-snmp-users > |
|
From: Deepak S. <sac...@gm...> - 2019-05-20 13:57:19
|
Heĺlo In snmpd.conf trap server address is defined as Trap2sink 192.168.1.10 public 162 If i edit the snmpd.conf file and changed address to 192.168.1.010 then traps are not received at trap receiver. Help required. Thanks in advance |
|
From: Bill F. <fe...@gm...> - 2019-05-20 13:29:20
|
On Tue, May 14, 2019 at 1:38 PM Bart Van Assche <bva...@ac...> wrote: > On 5/14/19 4:01 PM, Bill Fenner wrote: > > Perhaps getbulk no longer dumps core, but I can not get it to return > > anything but GENERR any more, and, it seems to leak memory. > > > > Any "large enough" request seems to fail in this way, e.g., > > snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime > > sysUpTime sysUpTime .1 > > > > This is particularly frustrating because code was added to 5.8 to > > rebuild a getbulk reply if it's too big. But there was already code > > to not build the PDU too big, it's just not taking the v3 header into > > account properly (that's my best guess, at least). So now there are > > two different mechanisms to send a "right-size" reply and they both > > don't work. Around 5.8 release time I was working with Robert Story > > to fix this, but that effort kind of petered out and Robert's work > > didn't make it into git. > > > > Can anyone get getbulk to work in the current 5.8-patches with SNMPv3? > > > > I've attached a test script with 504 failing test cases when I run it > > against an unmodified V5-8-patches branch, and net-snmp leaks about a > > meg of RAM during the test. This is an adaptation of my internal test > > to the net-snmp test framework; the complete test would use all > > supported values for -l, -a, -x but for now this is the simplest one > > using nanp. > > > Hi Bill, > > A new test has been added > (testing/fulltests/default/T0221snmpbulkget_large_simple). That test > passes on my setup. Can you have a look whether that test covers the > issue you ran into? > It doesn't - the problems arise when the agent decides that the message is too big and doesn't fit in the buffer. (E.g., the usage of --sendMessageMaxSize in my test, or, the repetition of .1 .1 .1 .1 on the snmpbulkget command line). Regarding the "memory leak": RSS is not a reliable source of information > to detect memory leaks. If you want to verify whether or not a new > memory leak has been introduced please use Valgrind. > Yes, my internal test uses valgrind and shows the leaks, I was using RSS growth as a proxy. I also used a script something like http://www.net-snmp.org/wiki/index.php/Running_Net-SNMP_Regression_Tests_under_Valgrind and it showed leaks when I ran the test that I sent, e.g., ==32438== 31,584 (8,736 direct, 22,848 indirect) bytes in 168 blocks are definitely lost in loss record 756 of 758 ==32438== at 0x402D05E: calloc (vg_replace_malloc.c:711) ==32438== by 0x430EA7A: usm_malloc_usmStateReference (snmpusm.c:288) ==32438== by 0x43117A7: usm_process_in_msg (snmpusm.c:2431) ==32438== by 0x4312B44: usm_secmod_process_in_msg (snmpusm.c:2335) ==32438== by 0x42D45EF: snmpv3_parse (snmp_api.c:3938) When I run your new test, I agree it passes: ~/src/test-for-bart/testing @fenner-test-for-bart.sjc% ./RUNFULLTESTS -r T0221 large SNMPv3 bulkget .. ok If I add "--sendMessageMaxSize=1472", then it fails in the same way as my test fails: returning genError. Your subsequent patch may address this problem if the manager does not specify a max response size, but as this is part of the SNMPv3 protocol and we do not necessarily control what the manager does, it's not sufficient. Bill |
|
From: Dan P. <dan...@et...> - 2019-05-20 04:45:20
|
Hello Venkat, Are you changing the hostname by editing the /etc/hostname file directly or by using the hostname command? Regards, Dan Pattison On 2019-05-19 9:04 p.m., Venkateswarlu Konamki wrote: > Hi All, > Any update on this issue? > > Thanks, > Venkat > > > On Thu, May 16, 2019 at 10:40 AM Venkateswarlu Konamki > <ven...@gm... <mailto:ven...@gm...>> wrote: > > Hi All , > > I am facing issue with in system_mib with SysName and SysLocation. > > Recently i have upgraded net-snmp version from 5.3.01 to 5.7.3. In > 5.7.3, if i see the code is system_mib there are changes happened > for handling the mibs. > > First time when i am doing snmp walk i am able to get the correct > hostname and syslocation. > Next i have changed the hostname with CLI (not via snmpset). when > i do snmpwlak or get, hostname is still showing the old name. > > *Before changing the hostname : * > # snmpget -v2c -c test localhost .1.3.6.1.2.1.1.5.0 > .1.3.6.1.2.1.1.5.0 = STRING: "Venkat_Desktop" > # > administrator@Venkat:~$ hostname > Venkat_Desktop. > > *After changing the hostname from Venkat_Desktop to "Venkat_machine"* > # snmpget -v2c -c test localhost .1.3.6.1.2.1.1.5.0 > .1.3.6.1.2.1.1.5.0 = STRING: "Venkat_Desktop" > # > administrator@Venkat:~$ hostname > Venkat_machine. > > It is reflecting in hostname, but when i do via snmp it is still > showing the old hostname. > > I am notable to find the root cause for this one. > > Is any one faced same issue ? if yes. what is the fix for this ? > Please help on this > > > Thanks, > > Venkat > > > > _______________________________________________ > Net-snmp-coders mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders |
|
From: Venkateswarlu K. <ven...@gm...> - 2019-05-20 04:05:34
|
Hi All, Any update on this issue? Thanks, Venkat On Thu, May 16, 2019 at 10:40 AM Venkateswarlu Konamki < ven...@gm...> wrote: > Hi All , > > I am facing issue with in system_mib with SysName and SysLocation. > > Recently i have upgraded net-snmp version from 5.3.01 to 5.7.3. In 5.7.3, > if i see the code is system_mib there are changes happened for handling > the mibs. > > First time when i am doing snmp walk i am able to get the correct hostname > and syslocation. > Next i have changed the hostname with CLI (not via snmpset). when i do > snmpwlak or get, hostname is still showing the old name. > > *Before changing the hostname : * > # snmpget -v2c -c test localhost .1.3.6.1.2.1.1.5.0 > .1.3.6.1.2.1.1.5.0 = STRING: "Venkat_Desktop" > # > administrator@Venkat:~$ hostname > Venkat_Desktop. > > *After changing the hostname from Venkat_Desktop to "Venkat_machine"* > # snmpget -v2c -c test localhost .1.3.6.1.2.1.1.5.0 > .1.3.6.1.2.1.1.5.0 = STRING: "Venkat_Desktop" > # > administrator@Venkat:~$ hostname > Venkat_machine. > > It is reflecting in hostname, but when i do via snmp it is still showing > the old hostname. > > I am notable to find the root cause for this one. > > Is any one faced same issue ? if yes. what is the fix for this ? Please > help on this > > > Thanks, > > Venkat > |
|
From: Jaka S. <Jak...@Av...> - 2019-05-16 17:47:52
|
Hi! We are using version 5.7.3 on an embedded system. We noticed segmentation errors in our dynamically loded module. The issue was that one of the requests had null pointer at parent_data. The issue can be reproduced on any table i.e. >snmpgetnext -v2c -c public x.x.x.x 1.3.6.1.4.1.2509.9.15.2.3.1.13 1.3.6.1.4.1.2509.9.15.2.3.1.12< (the first oid is pointing at nonexistent "column" and second one is a valid oid). The nonexistent oid appears in the requests linked list as a request with parent_data null and processed with value 1. (gdb) x/64xb 0x1e733f8 0xbb45b8: 0xd8 0xf9 0xbf 0x00 0x00 0x00 0x00 0x00 0xbb45c0: 0xb8 0xb1 0x9f 0x00 0x10 0xe3 0xad 0x00 0xbb45c8: 0x09 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xbb45d0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xbb45d8: 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0xbb45e0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xbb45e8: 0xd8 0xf9 0xbf 0x00 0xf8 0x45 0xbb 0x00 0xbb45f0: 0x00 0x00 0x00 0x00 0x60 0xe2 0xad 0x00 Usually getnext on a >nonexistent column< oid returns >No Such Object available...< without calling our linked module. Is this a bug? Can you please adivse me how to handle this situation when encountered? Best regards, Jaka Simonic p.s. this should give additional clarification This only happens when oids are pointing at the same table and one of them is pointing at nonexistent column and another at an existing column. Otherwise the agent resolves the situation with appropriate messages. Here all of oid are nonexistent: snmpgetnext -v2c -c public x.x.x.x iso.3.6.1.4.1.2509.9.15.2.3.1.14.59.2001.1.5 iso.3.6.1.4.1.2509.9.15.2.3.1.14.59.2001.1.7 1.0.8802.1.1.2.1.4.1.1.91.0.8802.1.1.2.1.4.1.1.8 iso.3.6.1.4.1.2509.9.15.2.3.1.14.59.2001.1.5 = No Such Object available on this agent at this OID iso.3.6.1.4.1.2509.9.15.2.3.1.14.59.2001.1.7 = No Such Object available on this agent at this OID iso.0.8802.1.1.2.1.4.1.1.91.0.8802.1.1.2.1.4.1.1.8 = No Such Object available on this agent at this OID |
|
From: Venkateswarlu K. <ven...@gm...> - 2019-05-16 05:11:19
|
Hi All , I am facing issue with in system_mib with SysName and SysLocation. Recently i have upgraded net-snmp version from 5.3.01 to 5.7.3. In 5.7.3, if i see the code is system_mib there are changes happened for handling the mibs. First time when i am doing snmp walk i am able to get the correct hostname and syslocation. Next i have changed the hostname with CLI (not via snmpset). when i do snmpwlak or get, hostname is still showing the old name. *Before changing the hostname : * # snmpget -v2c -c test localhost .1.3.6.1.2.1.1.5.0 .1.3.6.1.2.1.1.5.0 = STRING: "Venkat_Desktop" # administrator@Venkat:~$ hostname Venkat_Desktop. *After changing the hostname from Venkat_Desktop to "Venkat_machine"* # snmpget -v2c -c test localhost .1.3.6.1.2.1.1.5.0 .1.3.6.1.2.1.1.5.0 = STRING: "Venkat_Desktop" # administrator@Venkat:~$ hostname Venkat_machine. It is reflecting in hostname, but when i do via snmp it is still showing the old hostname. I am notable to find the root cause for this one. Is any one faced same issue ? if yes. what is the fix for this ? Please help on this Thanks, Venkat |
|
From: Bart V. A. <bva...@ac...> - 2019-05-15 23:27:21
|
On 5/14/19 4:01 PM, Bill Fenner wrote:
> Perhaps getbulk no longer dumps core, but I can not get it to return
> anything but GENERR any more, and, it seems to leak memory.
>
> Any "large enough" request seems to fail in this way, e.g.,
> snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime
> sysUpTime sysUpTime .1
>
> This is particularly frustrating because code was added to 5.8 to
> rebuild a getbulk reply if it's too big. But there was already code
> to not build the PDU too big, it's just not taking the v3 header into
> account properly (that's my best guess, at least). So now there are
> two different mechanisms to send a "right-size" reply and they both
> don't work. Around 5.8 release time I was working with Robert Story
> to fix this, but that effort kind of petered out and Robert's work
> didn't make it into git.
>
> Can anyone get getbulk to work in the current 5.8-patches with SNMPv3?
>
> I've attached a test script with 504 failing test cases when I run it
> against an unmodified V5-8-patches branch, and net-snmp leaks about a
> meg of RAM during the test. This is an adaptation of my internal test
> to the net-snmp test framework; the complete test would use all
> supported values for -l, -a, -x but for now this is the simplest one
> using nanp.
Hi Bill,
How about the patch below? I am not aware of any requirement in any RFC
to limit the maximum size of an SNMP reply to a single network MTU.
Thanks,
Bart.
Subject: [PATCH] libsnmp: Increase the maximum session receive size from
1472to 2**31-1 bytes
This patch adjusts a limit that was introduced by commit 6e83b3cd891d
(" - respect msgMaxSize in received v3 PDUs (in the weak sense that
if the serialized response PDU is more than it, we don't send it)")
# v5.7.
---
snmplib/snmp_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/snmplib/snmp_api.c b/snmplib/snmp_api.c
index c9a5b1edee34..e133ab6eb603 100644
--- a/snmplib/snmp_api.c
+++ b/snmplib/snmp_api.c
@@ -769,7 +769,7 @@ snmp_sess_init(netsnmp_session * session)
session->retries = SNMP_DEFAULT_RETRIES;
session->version = SNMP_DEFAULT_VERSION;
session->securityModel = SNMP_DEFAULT_SECMODEL;
- session->rcvMsgMaxSize = SNMP_MAX_MSG_SIZE;
+ session->rcvMsgMaxSize = netsnmp_max_send_msg_size();
session->sndMsgMaxSize = netsnmp_max_send_msg_size();
session->flags |= SNMP_FLAGS_DONT_PROBE;
}
|
|
From: Bart V. A. <bva...@ac...> - 2019-05-14 17:38:33
|
On 5/14/19 4:01 PM, Bill Fenner wrote: > Perhaps getbulk no longer dumps core, but I can not get it to return > anything but GENERR any more, and, it seems to leak memory. > > Any "large enough" request seems to fail in this way, e.g., > snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime > sysUpTime sysUpTime .1 > > This is particularly frustrating because code was added to 5.8 to > rebuild a getbulk reply if it's too big. But there was already code > to not build the PDU too big, it's just not taking the v3 header into > account properly (that's my best guess, at least). So now there are > two different mechanisms to send a "right-size" reply and they both > don't work. Around 5.8 release time I was working with Robert Story > to fix this, but that effort kind of petered out and Robert's work > didn't make it into git. > > Can anyone get getbulk to work in the current 5.8-patches with SNMPv3? > > I've attached a test script with 504 failing test cases when I run it > against an unmodified V5-8-patches branch, and net-snmp leaks about a > meg of RAM during the test. This is an adaptation of my internal test > to the net-snmp test framework; the complete test would use all > supported values for -l, -a, -x but for now this is the simplest one > using nanp. Hi Bill, A new test has been added (testing/fulltests/default/T0221snmpbulkget_large_simple). That test passes on my setup. Can you have a look whether that test covers the issue you ran into? Regarding the "memory leak": RSS is not a reliable source of information to detect memory leaks. If you want to verify whether or not a new memory leak has been introduced please use Valgrind. Bart. |
475 messages has been excluded from this view by a project administrator.
