net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

Re: [net-snmp:patches] #1388 patch for bug 2923: snmpv3 bulkget errors result in double free core dump

[Bill F. <fe...@gm...>]

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/
>

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Bart V. A. <bva...@ac...>]

On 5/13/19 12:10 PM, Vijay, Anjali wrote:
> Thanks for the help. Meanwhile, I had changed the buffer size back to 
> 1472 and it seems to be working fine like the previous version, net-snmp 
> 5.7.3. Do you think this can cause any serious impact?

Hi Anjali,

I think that approach is risky. It's easy for an SNMP manager to send an 
snmp get, getnext or getbulk request with multiple OIDs. Even if the 
request fits in a 1472 byte network packet, the response may exceed that 
packet size. Unless if you know from beforehand what kind of requests 
the SNMP manager(s) will send and if you know from beforehand what the 
maximum string length will be, I think it's safe to use a larger buffer 
size.

Bart.

RE: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Vijay, A. <anj...@hp...>]

Hi Bart,

Thanks for the help. Meanwhile, I had changed the buffer size back to 1472 and it seems to be working fine like the previous version, net-snmp 5.7.3. Do you think this can cause any serious impact?

Regards,
Anjali Vijay

From: Bart Van Assche <bva...@ac...>
Sent: Sunday, April 28, 2019 3:39 AM
To: Vijay, Anjali <anj...@hp...>; net...@li...
Subject: Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

On 4/25/19 5:56 PM, Bart Van Assche wrote:
On 4/25/19 8:00 AM, Vijay, Anjali wrote:
I recently started working with net-snmp-5.8. I had a query over a change that was made to agentx_parse() in agent/mibgroup/agentx/protocol.c. I noticed that the buffer of  SNMP_MAX_MSG_SIZE (1472) in net-snmp-5.7.3 has been replaced with the size 65536 in net-snmp-5.8.

u_char buffer[65536];

I didn't find any clarification in the ChangeLogs for this large increase of size. Can this size be reduced? It would be of great help if anyone can clear me out on this since my application has memory constraints.

Hi Anjali,

I will have a look and see whether it is possible to modify the AgentX code without reducing performance and without dropping support for large AgentX packets. BTW, the following commit increased the buffer size:

c09140c934eb ("CHANGES: snmpd: Increase maximum AgentX packet size to 64kB.")

Hi Anjali,

A candidate fix has been checked in on the v5.8 and master branches. Please verify.

Bart.

Re: Update UCD-SNMP-MIB variable type

[Niels B. <nb...@us...>]

On Mon, May 13, 2019 at 10:08:58AM +0200, Ilya Etingof wrote:
> 
> > The currelt 5.8 release (and unreleased 5.7 update) should already
> > contain objects like memTotalRealX which are defined as
> > CounterBasedGauge64
> > 
> > Unfortunately I don't have hardware to test it :-)
> 
> Just in case on-line agent emulation [1] could be helpful:
> 
> $ snmpget -v2c -c mib2dev/ucd-snmp-mib demo.snmplabs.com UCD-SNMP-MIB::memTotalRealX.0
> UCD-SNMP-MIB::memTotalRealX.0 = Counter64: 18345168853242336474 kB
> 
> You can have it off-line as well [2].
> 
> 1. http://demo.snmplabs.com
> 2. http://snmplabs.com/snmpsim

Well, what is interesting is if the real agent get the real value. It
is about debugging the agent running on the physical hardware.

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - nb...@us...
The purpose of computing is insight, not numbers   ---   R W Hamming

Re: Update UCD-SNMP-MIB variable type

[Ilya E. <il...@gl...>]

> The currelt 5.8 release (and unreleased 5.7 update) should already
> contain objects like memTotalRealX which are defined as
> CounterBasedGauge64
> 
> Unfortunately I don't have hardware to test it :-)

Just in case on-line agent emulation [1] could be helpful:

$ snmpget -v2c -c mib2dev/ucd-snmp-mib demo.snmplabs.com UCD-SNMP-MIB::memTotalRealX.0
UCD-SNMP-MIB::memTotalRealX.0 = Counter64: 18345168853242336474 kB

You can have it off-line as well [2].

1. http://demo.snmplabs.com
2. http://snmplabs.com/snmpsim

Re: Update UCD-SNMP-MIB variable type

[Niels B. <nb...@us...>]

On Mon, May 13, 2019 at 02:56:46AM -0400, Josef Ridky wrote:
> Hi folks,
> 
> I would like to know your opinion on following issue.
> 
> UCD-SNMP-MIB [1] uses INTEGER32 instead of COUNTER64 for memory OIDs which limits the reporting to 2 TiB (using KiB as the base).
> Large modern servers often contain more than 2 TiB of memory leading to the OIDs rolling over and reporting negative values.
> 
> How can it be solved? 
> Can we just change the variable type? (I don't think so) 
> Or can we add new variables, that will be COUNTER64 type? 
> Or can the base be set to e.g. MiB instead of KiB in configuration?

The currelt 5.8 release (and unreleased 5.7 update) should already
contain objects like memTotalRealX which are defined as
CounterBasedGauge64

Unfortunately I don't have hardware to test it :-)

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - nb...@us...
The purpose of computing is insight, not numbers   ---   R W Hamming

Update UCD-SNMP-MIB variable type

[Josef R. <jr...@re...>]

Hi folks,

I would like to know your opinion on following issue.

UCD-SNMP-MIB [1] uses INTEGER32 instead of COUNTER64 for memory OIDs which limits the reporting to 2 TiB (using KiB as the base).
Large modern servers often contain more than 2 TiB of memory leading to the OIDs rolling over and reporting negative values.

How can it be solved? 
Can we just change the variable type? (I don't think so) 
Or can we add new variables, that will be COUNTER64 type? 
Or can the base be set to e.g. MiB instead of KiB in configuration?

[1] http://www.net-snmp.org/docs/mibs/ucdavis.html

Regards

Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

Re: Authentication failed for user

[Wes H. <har...@us...>]

Simon Chamlian <sim...@mp...> writes:

> I am issuing an inform, (which works fine as I get the inform) but
> getting the following error:

If I understand you correctly,

1) you're using snmpinform to send the inform to some receiver
2) the receiver gets the inform properly, and prints/logs/whatever it
3) but snmpinform is still saying authentication failed for the user

I think that the receiver is not sending back a properly authenticated
message (a response indicating it got the INFORM message)
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: [net-snmp:code] 4 new commits to Code

[Bill F. <fe...@us...>]

On Tue, May 7, 2019 at 7:41 PM Bart Van Assche <bva...@ac...> wrote:

> On 5/7/19 9:42 AM, Bill Fenner wrote:
> > I was hoping you might have an idea of a more graceful solution that
> > allows keeping const'ness.  If not, I can check in my change.
>
> Hi Bill,
>
> Please have a look at commit 068b4686739c ("libsnmp: Rework the
> MDblock() implementation").
>

Yes, this is great, thanks!

  Bill

Re: [net-snmp:code] 4 new commits to Code

[Bart V. A. <bva...@ac...>]

On 5/7/19 9:42 AM, Bill Fenner wrote:
> I was hoping you might have an idea of a more graceful solution that
> allows keeping const'ness.  If not, I can check in my change.

Hi Bill,

Please have a look at commit 068b4686739c ("libsnmp: Rework the
MDblock() implementation").

Thanks,

Bart.

Re: [net-snmp:code] 4 new commits to Code

[Bill F. <fe...@us...>]

On Mon, Apr 29, 2019 at 7:10 PM Bart Van Assche <bva...@ac...> wrote:

> On Mon, 2019-04-29 at 17:19 -0400, Bill Fenner wrote:
>
> On Sun, Apr 28, 2019 at 7:52 PM net-snmp Git repository <
> no...@co...> wrote:
>
> Branch: V5-8-patches
>
> configure: Determine endianness at compile time instead of at configure
> time
>
> The new test supports cross-compilation. In other words, --with-endianness
> no longer has to be specified during cross-compilation.
>
> By Bart Van Assche on 04/28/2019 20:40
> *View Changes*
> <https://sourceforge.net/p/net-snmp/code/ci/484524cda94838dfec8eb1ae92b069ea8ce448f6/>
>
>
> Hi Bart,
>
> This change exposes md5.c's "big lie" of const-ness.  Before, it was
> hidden behind #if BIG_ENDIAN, so I never saw it - now, it's exposed since
> MDReverse(X) can be called at runtime.  Obviously, MDReverse(X) can modify
> the value that's passed throughout as const.
>
> For now I've patched my local copy to eliminate the const lie throughout
> md5.[ch].
>
>
> Hi Bill,
>
> Do you plan to check in your patch or do you perhaps prefer that I look
> further into this?
>

I was hoping you might have an idea of a more graceful solution that allows
keeping const'ness.  If not, I can check in my change.

  Bill

SNMP Configuration

[Arun K. <aru...@gm...>]

Dear friends,

i want to configure snmp configuration on linux. can you please help me
configuration of mibs and other details. Thanks!

Re: Parsing the values returned from snmp_synch_response

[Niels B. <nb...@us...>]

On Thu, May 02, 2019 at 05:51:03PM +0000, Even Oscar Andersen wrote:
> (Repost of message sent to net-snmp-users, maybe this forum is more appropriate)
> 
> Hello,
> 
> I am calling snmp_synch_response, and try to use the resulting variables,
> 
> It seems part of the result return variable type 0x81, not sure what this variable is,
> It is not one of the ASN_ defines, but if I mask out 0x80 (not sure if this is correct),
> It seems to be ASN_BOOLEAN.

This is a SNMPv2 exception type. You can find it in include/net-snmp/library/snmp.h,
but here are the exceptions:


    /*
     * Exception values for SNMPv2p, SNMPv2c, SNMPv2u, SNMPv2*, and
     * SNMPv3 
	      */
#define SNMP_NOSUCHOBJECT    (ASN_CONTEXT | ASN_PRIMITIVE | 0x0) /* 80=128 */
#define SNMP_NOSUCHINSTANCE  (ASN_CONTEXT | ASN_PRIMITIVE | 0x1) /* 81=129 */
#define SNMP_ENDOFMIBVIEW    (ASN_CONTEXT | ASN_PRIMITIVE | 0x2) /* 82=130 */

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - nb...@us...
The purpose of computing is insight, not numbers   ---   R W Hamming

Parsing the values returned from snmp_synch_response

[Even O. A. <eve...@km...>]

(Repost of message sent to net-snmp-users, maybe this forum is more appropriate)

Hello,

I am calling snmp_synch_response, and try to use the resulting variables,

It seems part of the result return variable type 0x81, not sure what this variable is,
It is not one of the ASN_ defines, but if I mask out 0x80 (not sure if this is correct),
It seems to be ASN_BOOLEAN.

However,

I don't know how to interpret the variable union for ASN_BOOLEAN,
And if I look at snmp_set_var_value, ASN_BOOLEAN is not mentioned there.

Soo, can anyone tell me what kind of variable 0x81 is ?
And how do I get its value.


Also, what is the correct way to interpret variable_list::type, should I mask out
Something from the type, or use it as is ?


Regards,

Even

Re: SNMP Command

[Niels B. <nb...@us...>]

Den 26-04-2019 kl. 17:22 skrev HOUASLI, Samir via Net-snmp-coders:
> I use this command: snmpd -m 
> /home/snet/execution/staticCFG/MibCoSNET.txt -v1 -c public localhost .1.3.6.1.4.1.4747.14.5.16.2.0
which allows me to have as an output:
> LOG-MIB::sysOperEvalNodeCmdOrder.0 = INTEGER: oper(1)
> 
> I want to have as an output the red line which is the description of the 
> OID. *Can you tell me which command allows me to have that in the output 
> of the terminal?*

You probably meant snmpget not snmpd?

The closest thing we have is snmptranslate with the -Td argument.

But you can of course modify snmpget to your hearts desire :-)

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - nb...@us...
The purpose of computing is insight, not numbers   ---   R W Hamming

Re: [net-snmp:code] 4 new commits to Code

[Bart V. A. <bva...@ac...>]

On Mon, 2019-04-29 at 17:19 -0400, Bill Fenner wrote:
> On Sun, Apr 28, 2019 at 7:52 PM net-snmp Git repository <no...@co...> wrote:
> > Branch: V5-8-patches
> > 
> > 
> > configure: Determine endianness at compile time instead of at configure time
> > 
> > The new test supports cross-compilation. In other words, --with-endianness
> > 
> > no longer has to be specified during cross-compilation.
> > 
> > 
> > By Bart Van Assche on 04/28/2019 20:40
> > 
> > View Changes
> > 
> > 
> > 
> Hi Bart,
> 
> This change exposes md5.c's "big lie" of const-ness.  Before, it was hidden behind #if BIG_ENDIAN, so I never saw it - now, it's exposed since MDReverse(X) can be called at runtime.  Obviously,
> MDReverse(X) can modify the value that's passed throughout as const.
> 
> For now I've patched my local copy to eliminate the const lie throughout md5.[ch].

Hi Bill,

Do you plan to check in your patch or do you perhaps prefer that I look further into this?

Bart.

Re: [net-snmp:code] 4 new commits to Code

[Bill F. <fe...@us...>]

On Sun, Apr 28, 2019 at 7:52 PM net-snmp Git repository <
no...@co...> wrote:

> Branch: V5-8-patches
>
> configure: Determine endianness at compile time instead of at configure
> time
>
> The new test supports cross-compilation. In other words, --with-endianness
> no longer has to be specified during cross-compilation.
>
> By Bart Van Assche on 04/28/2019 20:40
> *View Changes*
> <https://sourceforge.net/p/net-snmp/code/ci/484524cda94838dfec8eb1ae92b069ea8ce448f6/>
>
> Hi Bart,

This change exposes md5.c's "big lie" of const-ness.  Before, it was hidden
behind #if BIG_ENDIAN, so I never saw it - now, it's exposed since
MDReverse(X) can be called at runtime.  Obviously, MDReverse(X) can modify
the value that's passed throughout as const.

For now I've patched my local copy to eliminate the const lie throughout
md5.[ch].

  Bill

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Vijay, A. <anj...@hp...>]

Thanks Bart !!


Regards,

Anjali S. Vijay


________________________________
From: Bart Van Assche <bva...@ac...>
Sent: Sunday, April 28, 2019 3:38 AM
To: Vijay, Anjali; net...@li...
Subject: Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

On 4/25/19 5:56 PM, Bart Van Assche wrote:
On 4/25/19 8:00 AM, Vijay, Anjali wrote:

I recently started working with net-snmp-5.8. I had a query over a change that was made to agentx_parse() in agent/mibgroup/agentx/protocol.c. I noticed that the buffer of  SNMP_MAX_MSG_SIZE (1472) in net-snmp-5.7.3 has been replaced with the size 65536 in net-snmp-5.8.



u_char buffer[65536];



I didn’t find any clarification in the ChangeLogs for this large increase of size. Can this size be reduced? It would be of great help if anyone can clear me out on this since my application has memory constraints.

Hi Anjali,

I will have a look and see whether it is possible to modify the AgentX code without reducing performance and without dropping support for large AgentX packets. BTW, the following commit increased the buffer size:

c09140c934eb ("CHANGES: snmpd: Increase maximum AgentX packet size to 64kB.")

Hi Anjali,

A candidate fix has been checked in on the v5.8 and master branches. Please verify.

Bart.

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Bart V. A. <bva...@ac...>]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 4/25/19 5:56 PM, Bart Van Assche
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:62d...@ac...">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div class="moz-cite-prefix">On 4/25/19 8:00 AM, Vijay, Anjali
        wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CS1...@CS...">
        <meta http-equiv="Content-Type" content="text/html;
          charset=windows-1252">
        <meta name="Generator" content="Microsoft Word 15 (filtered
          medium)">
        <style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
        <div class="WordSection1">
          <p class="MsoNormal">I recently started working with
            net-snmp-5.8. I had a query over a change that was made to
            agentx_parse() in agent/mibgroup/agentx/protocol.c. I
            noticed that the buffer of  SNMP_MAX_MSG_SIZE (1472) in
            net-snmp-5.7.3 has been replaced with the size 65536 in
            net-snmp-5.8. <o:p></o:p></p>
          <p class="MsoNormal"><o:p> </o:p></p>
          <p class="MsoNormal">u_char buffer[65536];<o:p></o:p></p>
          <p class="MsoNormal"><o:p> </o:p></p>
          <p class="MsoNormal">I didn’t find any clarification in the
            ChangeLogs for this large increase of size. Can this size be
            reduced? It would be of great help if anyone can clear me
            out on this since my application has memory constraints.<o:p></o:p></p>
        </div>
      </blockquote>
      <p>Hi Anjali,</p>
      <p>I will have a look and see whether it is possible to modify the
        AgentX code without reducing performance and without dropping
        support for large AgentX packets. BTW, the following commit
        increased the buffer size:<br>
      </p>
      <p>c09140c934eb ("CHANGES: snmpd: Increase maximum AgentX packet
        size to 64kB.")</p>
    </blockquote>
    <p>Hi Anjali,</p>
    <p>A candidate fix has been checked in on the v5.8 and master
      branches. Please verify.</p>
    <p>Bart.<br>
    </p>
  </body>
</html>

SNMP Command

[HOUASLI, S. <sam...@ca...>]

Good morning,
I want your help for a subject about the SNMP command.
              I am using linux and I want to use a SNMP command to see the description of an OID.

Here is a section from the mib:

sysOperEvalNodeCmdOrder OBJECT-TYPE
                                SYNTAX INTEGER
                                {
                                       undefined (0),
                                       oper (1),
                                       preoper (2),
                                       eval (3),
                                       unknown (4)
                                }
                                MAX-ACCESS read-write
                                STATUS current
                                DESCRIPTION
                                       "Command to set a single node to an OPER /EVAL state:
                                             Undefined (0),
                                             Set node in Operational mode (1),
                                             Set node in PreOperational mode (2),
                                             Set node in Evaluation mode (3),
                                             Set node in Unknown mode (4)"
                                ::= { sysOperEval 2 }


I use this command: snmpd -m /home/snet/execution/staticCFG/MibCoSNET.txt -v1 -c public localhost .1.3.6.1.4.1.4747.14.5.16.2.0   which allows me to have as an output: LOG-MIB::sysOperEvalNodeCmdOrder.0 = INTEGER: oper(1) .
I want to have as an output the red line which is the description of the OID.  Can you tell me which command allows me to have that in the output of the terminal?


Thank you
Have a nice day


Samir HOUASLI
Software Engineer MOE ODS



This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Bart V. A. <bva...@ac...>]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 4/25/19 8:00 AM, Vijay, Anjali
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CS1...@CS...">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">I recently started working with
          net-snmp-5.8. I had a query over a change that was made to
          agentx_parse() in agent/mibgroup/agentx/protocol.c. I noticed
          that the buffer of  SNMP_MAX_MSG_SIZE (1472) in net-snmp-5.7.3
          has been replaced with the size 65536 in net-snmp-5.8. <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">u_char buffer[65536];<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I didn’t find any clarification in the
          ChangeLogs for this large increase of size. Can this size be
          reduced? It would be of great help if anyone can clear me out
          on this since my application has memory constraints.<o:p></o:p></p>
      </div>
    </blockquote>
    <p>Hi Anjali,</p>
    <p>I will have a look and see whether it is possible to modify the
      AgentX code without reducing performance and without dropping
      support for large AgentX packets. BTW, the following commit
      increased the buffer size:<br>
    </p>
    <p>c09140c934eb ("CHANGES: snmpd: Increase maximum AgentX packet
      size to 64kB.")<br>
    </p>
    <p>Bart.<br>
    </p>
  </body>
</html>

Re: Authentication failed for user

[Simon C. <sim...@mp...>]

the source of the error is in:   net-snmp-5.8/snmplib/snmpusm.c




    /*
     * Check the authentication credentials of the message.
     */
    if (secLevel == SNMP_SEC_LEVEL_AUTHNOPRIV
        || secLevel == SNMP_SEC_LEVEL_AUTHPRIV) {
        if (sc_check_keyed_hash(user->authProtocol, user->authProtocolLen,
                                user->authKey, user->authKeyLen,
                                wholeMsg, wholeMsgLen,
                                signature, signature_length)
            != SNMP_ERR_NOERROR) {
            DEBUGMSGTL(("usm", "Verification failed.\n"));
            snmp_increment_statistic(STAT_USMSTATSWRONGDIGESTS);
            snmp_log(LOG_WARNING, "Authentication failed for %s\n",
user->name);
            return SNMPERR_USM_AUTHENTICATIONFAILURE;
        }

        DEBUGMSGTL(("usm", "Verification succeeded.\n"));
    }




On Thu, Apr 25, 2019 at 2:28 PM Simon Chamlian <sim...@mp...>
wrote:

> Hi,
>
> I am issuing an inform, (*which works fine* as I get the inform) but
> getting the following error:
>
> snmpinform -v 3 -r 1 -t 1 -u "User" -a MD5 -A "UserPass" -l authNoPriv
> 172.27.37.222 ""  DCI-MIB::DCITrapCritical DCI-MIB::NEID s "NE_Identif"
>
> *Authentication failed for User*
>
> Any reason why I am getting this error message?
>
> Thx,
> S
>
>
>

Authentication failed for user

[Simon C. <sim...@mp...>]

Hi,

I am issuing an inform, (*which works fine* as I get the inform) but
getting the following error:

snmpinform -v 3 -r 1 -t 1 -u "User" -a MD5 -A "UserPass" -l authNoPriv
172.27.37.222 ""  DCI-MIB::DCITrapCritical DCI-MIB::NEID s "NE_Identif"

*Authentication failed for User*

Any reason why I am getting this error message?

Thx,
S

To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Vijay, A. <anj...@hp...>]

Hi,

I recently started working with net-snmp-5.8. I had a query over a change that was made to agentx_parse() in agent/mibgroup/agentx/protocol.c. I noticed that the buffer of  SNMP_MAX_MSG_SIZE (1472) in net-snmp-5.7.3 has been replaced with the size 65536 in net-snmp-5.8.

u_char buffer[65536];

I didn't find any clarification in the ChangeLogs for this large increase of size. Can this size be reduced? It would be of great help if anyone can clear me out on this since my application has memory constraints.

Thanks,
Anjali S. Vijay

Re: SNMP Configure Script Issue: When I include a header file in include/net-snmp/library/snmp_logging.h

[prabu v. <pra...@gm...>]

Sorry for the late update.

This issue has been resolved by making use of the environmental variable CPP
before configuring the source code. Previously I was trying to use CPPFLAGS
and CFLAGS which were not the exact variables.

On Mon, Mar 25, 2019 at 8:28 PM prabu varadharajan <
pra...@gm...> wrote:

> Dear All,
>
> As per my understanding with respect to Autoconf, I've made the following
> changes and still observed the same fatal errors with less number.
>
> *Changes Done with respect to configure.d:*
>
> diff --git a/configure.d/config_modules_lib
> b/configure.d/config_modules_lib
> index bb69daa..cffed6c 100644
> --- a/configure.d/config_modules_lib
> +++ b/configure.d/config_modules_lib
> @@ -99,6 +99,9 @@ if test ! -d snmplib/transports ; then
>    mkdir snmplib/transports
>  fi
>
> +echo "CPPFLAGS = "$CPPFLAGS
> +
>  #
>  # Do transport module processing.
>  #
> diff --git a/configure.d/config_project_paths b/configure.d/
> config_project_paths
> index 9690c84..4878e1e 100644
> --- a/configure.d/config_project_paths
> +++ b/configure.d/config_project_paths
> @@ -5,6 +5,8 @@
>  ##
>  #########################################
>
> +CPPFLAGS="$CPPFLAGS -I$(pwd)/../../inc"
> +
>  ##
>  #   Prefix paths:
>  ##
>
> *After making changes, did reconfiguration using the following command:*
>
> $ autoreconf
>
> *The output logs of ./configure: *
>
>
>
>
>
>
>
>
>
>
>
>
>
> *checking ipv6 stack type... "linux-glibc, yes, using libc"checking for
> platform-specific source...  CPPFLAGS =
> -I/home/anand/workspace/modules/snmp/net-snmp-5.8.pre2/../../incchecking
> for and configuring transport modules to use... In file included from
> ./include/net-snmp/output_api.h:181:0,                 from
> ./include/net-snmp/library/snmp_client.h:32,                 from
> ./include/net-snmp/varbind_api.h:102,                 from
> ./include/net-snmp/library/snmp_api.h:33,                 from
> ./include/net-snmp/definitions.h:23,                 from
> ./include/net-snmp/types.h:462,                 from
> include/net-snmp/library/snmpUDPIPv6Domain.h:11,                 from
> module_tmp_header.h:160:./include/net-snmp/library/snmp_logging.h:8:23:
> fatal error: my_macros.h: No such file or directorycompilation terminated.*
>
> Before the reconfiguration(autoreconf), I observed around 12 fatal errors
> which have been reduced to 2 errors only. Please correct me if I'm going
> in the wrong direction and help me to resolve this issue!
>
> *Note:* The my_macros.h file is available in the
> /home/anand/workspace/modules/snmp/net-snmp-5.8.pre2/../../inc directory
> and in this scenario I did not make use of the ./configure option
> --with-cflags.
>
> Thanks in advance!
>
> On Fri, Mar 22, 2019 at 3:50 PM prabu varadharajan <
> pra...@gm...> wrote:
>
>> Thanks for the quick response, Magnus.
>>
>> Please find the compilation options below and let me know if anything
>> else required.
>>
>> libtool: compile:  gcc -I../include -I. -I../snmplib
>> -I/usr/include/libnl3
>> -I/home/anand/workspace/modules/snmp/explore/net-snmp-5.8.pre2/../inc/
>> -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -DNETSNMP_REMOVE_U64
>> -I/home/anand/workspace/modules/snmp/explore/net-snmp-5.8.pre2/../inc/
>> -Ulinux -Dlinux=linux -c transports/snmpUDPIPv6Domain.c  -fPIC -DPIC -o
>> transports/.libs/snmpUDPIPv6Domain.o
>>
>> For additional reference please find the configure options as well.
>>
>> *./configure --without-openssl --with-default-snmp-version=2
>> --with-sys-contact=contact --with-sys-location=location
>> --with-logfile=/var/log/snmpd.log --with-persistent-directory=/var/net-snmp
>> --disable-manuals --disable-scripts --disable-mibs --without-perl-modules
>> --disable-embedded-perl --enable-mini-agent --enable-fast-install
>> --enable-ipv6 --with-transports=UDPIPv6
>> --with-cflags=-I/home/anand/workspace/modules/snmp/explore/net-snmp-5.8.pre2/../inc/*
>>
>>
>>
>>
>> On Fri, Mar 22, 2019 at 3:22 PM Magnus Fromreide <ma...@ly...>
>> wrote:
>>
>>> On Fri, Mar 22, 2019 at 01:15:52PM +0530, prabu varadharajan wrote:
>>> > Dear All,
>>> >
>>> > Following is my project source code hierarchy,
>>> > + src
>>> >     |
>>> >     +---- snmp
>>> >     |
>>> >     +---- my_app
>>> >     |
>>> >     +---- inc
>>> >             |
>>> >             +---- local_snmp_macros.h
>>> >             +---- my_macros.h
>>> >
>>> > I have declared few functions and macros in both local_snmp_macros.h
>>> and
>>> > my_macros.h files which are being used by both snmp and my_app
>>> > applications. As of now I'm copying the header files before
>>> ./configure and
>>> > compilation from src/inc/ to src/snmp/agent/mibgroup and removing
>>> those on
>>> > clean which is not recommended. So now I would like to avoid this
>>> copying
>>> > overhead and include from src/inc itself.
>>> >
>>> > For this I have updated ./configure --with-cflags=-I$(pwd)/../inc and
>>> able
>>> > to build the application successfully but I'm getting following fatal
>>> errors.
>>> > In this case also I'm observing some* weird behaviour* like I have
>>> > included my_macros.h
>>> > and local_snmp_macros.h files in
>>> > src/snmp/include/net-snmp/library/snmp_logging.h whereas I'm getting
>>> fatal
>>> > errors for the *first one*(my_macros.h) only. I have tried exploring
>>> > Makefile.* and configure script as well but I could not resolve this
>>> one.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > *In file included from
>>> > ./include/net-snmp/output_api.h:181:0,                 from
>>> > ./include/net-snmp/library/snmp_client.h:32,                 from
>>> > ./include/net-snmp/varbind_api.h:102,                 from
>>> > ./include/net-snmp/library/snmp_api.h:33,                 from
>>> > ./include/net-snmp/definitions.h:23,                 from
>>> > ./include/net-snmp/types.h:462,                 from
>>> > include/net-snmp/library/snmpUDPIPv6Domain.h:11,                 from
>>> > module_tmp_header.h:164:./include/net-snmp/library/snmp_logging.h:7:23:
>>> > fatal error: my_macros.h: No such file or directorycompilation
>>> terminated.*
>>> >
>>> > *File include view for reference:*
>>> > #ifndef SNMP_LOGGING_H
>>> > #define SNMP_LOGGING_H
>>> >
>>> > #include <net-snmp/types.h>
>>> > #include <net-snmp/output_api.h>
>>> > #include "dummy.h"
>>> > #include <my_macros.h>
>>> > #include <local_snmp_macros.h>
>>> >
>>> > As per my understanding, I suspect the *configure* script only which
>>> could
>>> > have some bug. Please correct me if I'm wrong and help me to overcome
>>> from
>>> > this error.
>>> >
>>> > *Note: *I have observed same behaviour in noth Net-SNMP-5.5 and
>>> > Net-SNMP-5.8.pre2 as well.
>>> >
>>> > Please feel free to ask more details if required that I can provide to
>>> > resolve this issue. Or let me know if any reference link if this issue
>>> is
>>> > already reported and resolved.
>>>
>>> Could you please show the compile line before the error message
>>> (something
>>> like gcc blah blah something.c -o something.o)
>>>
>>
>>
>> --
>> With Best Regards,
>> Anandaprabu V <https://www.linkedin.com/in/anandaprabu-v-10867671/>
>> VVDN Technologies Pvt. Ltd <http://www.vvdntech.com/>, Chennai
>> Cell : +91 9500650885 | Skype : prabuvaradharajan
>>
>
>
> --
> With Best Regards,
> Anandaprabu V <https://www.linkedin.com/in/anandaprabu-v-10867671/>
> VVDN Technologies Pvt. Ltd <http://www.vvdntech.com/>, Chennai
> Cell : +91 9500650885 | Skype : prabuvaradharajan
>


-- 
With Best Regards,
Anandaprabu V <https://www.linkedin.com/in/anandaprabu-v-10867671/>
VVDN Technologies Pvt. Ltd <http://www.vvdntech.com/>, Chennai
Cell : +91 9500650885 | Skype : prabuvaradharajan