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

Netsnmp 5.7.3 compilation issue

[Venkat K <ven...@gm...>]

Hi All,

I am facing below compilation error in ubuntu 14.04 version while cross
compiling netsnmp for MIPS.

/.libs/libnetsnmpmibs.so: undefined reference to `system_module_oid_len'
./.libs/libnetsnmpmibs.so: undefined reference to `system_module_oid'
./.libs/libnetsnmpmibs.so: undefined reference to `system_module_count'
collect2: ld returned 1 exit status

Is there any package i have to install ? Please let me know

Thanks,
Venkateswarlu

snmp_save_persistent()

[Mark E. <el...@ie...>]

Hi,

I want to update a line in an application configuration file during the
commit phase of an SNMP SET operation.  I am noticing the read_config_store
appends a new line to the configuration file when I want to replace a line.
This config file lives in the net-snmp persistent directory.

I've had no problems using the register_config_handler() routine and am
getting the callback when my token is read during snmpd startup.

As of now, I am searching for a way to do essentially what
snmp_save_persistent() does, short of adding the warning banner to the top
of the file.

Looking at the Net-SNMP implemented code base, it appears the preferred
method for updating configuration from the daemon is to move the
configuration off to the side and write a new configuration file with the
changed values.

If anyone can suggest a method for either:
(a) overwriting the given token line with the new value, or
(b) short of re-writting snmp_save_persistent, achieve the desired behavior
without the banner.
(c) using other means to achieve same goal

Any follow-ups are appreciated!

Regards,



Mark Ellison

Re: SNMPv3: authPriv: Scoped PDU: ASN.1 Parse error

[Krishna C. <cha...@gm...>]

On Tue, Sep 24, 2019 at 9:21 AM prabu varadharajan
<pra...@gm...> wrote:
>
> Hi Krishna,
>
> Can you please try the Net-SNMP-5.7.3 with OpenSSL-1.1.0g once? Hope there will be no issues with AES/DES!

Sorry for the late reply. 5.7.3 doesn't compile with 1.1.0, please see
https://sourceforge.net/p/net-snmp/bugs/2893/.

Netsnmp Master reinit on SIGHUP

[Paban A. <pab...@gm...>]

Hi,

After restart snmpd using SIGHUP, agentadress is not updating. I don't find
any code to reinit master agent.

Is there have fix for it?

Regards
Paban

A question for error of snmpset command

[<bao...@pi...>]

hello, I have a question of snmpset command. Do you know how to solve this problem.

I execute the command "snmpset -v 3 -u [username] -l authPriv -a sha -A [password] -x aes -X [cipherkey] [ip] ".1.3.6.1.4.1.2011.5.25.42.3.1.1.1.1.3.33" x "3F FF FF FF FF FF F8".

Unfortunately, I execute this command successfully for one time. After that I only get the same error message as:

"Error in packet.  
Reason: (genError) A general failure occured"

By the way, I can execute the command "snmpwalk" successfully all the time.

Thank you.




bao...@pi...

Invalid authentication protocol specified after -3a flag: SHA-512

[Wu, M. (N. - CN/Hangzhou) <mer...@no...>]

Hello,

When I use snmpget to get some, there are some wrong, could you please give some support? Thanks!

snmpget -v3 -l authPriv -u username -a SHA-512 -A password -x AES -X cmb9.admin host_ip  1.3.6.1.4.1.28458.1.64.3.1.1.1.0
Invalid authentication protocol specified after -3a flag: SHA-512

NET-SNMP version: 5.8
OS: CentOS Linux release 7.6.1810 (Core)

B.R.
Merry Wu

Re: Linux: Initial interface list for IF-MIB

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

On 2019-10-23 14:03, Sam Tannous wrote:
> (Posting this here to get a wider audience for my stuck patch review.)
> 
> I have a patch in review (https://github.com/net-snmp/net-snmp/pull/24)
> where I'm trying to prune a large number of interfaces (~2000 or more).

Did the conversation in that pull request really get stuck? Please have
another look at init_mteObjects and _init_default_mteObject_lists(). I
think these two functions implement a mechanism for initializing a MIB
after the config data has been read instead of before config data has
been read.

Thanks,

Bart.

Linux: Initial interface list for IF-MIB

[Sam T. <sta...@cu...>]

(Posting this here to get a wider audience for my stuck patch review.)

I have a patch in review (https://github.com/net-snmp/net-snmp/pull/24)
where I'm trying
to prune a large number of interfaces (~2000 or more).

The patch introduces a new configuration option to limit the number
of interfaces that the IF-MIB will process. On Linux servers with a
large number of interfaces (ppp, dummy, bridge, etc.), the IF-MIB
timer based stats collector can take a large amount of CPU processing.

The new config option "include_ifmib_iface_prefix" takes a space
separated string of ifname prefixes ("eth lo bridg") and will only
include interfaces with these prefixes in the IF-MIB tables.

If this config option is not present (the default), all interfaces
will continue to be processed in the IF-MIB.

This patch is largely based on work by Collet Thibaut from

https://sourceforge.net/p/net-snmp/patches/1352/
The problem I'm trying to solve is that even though my configuration
option is parsed and I have checks in place to prevent
non-matched prefixes from being included in the IF-MIB,
for the first 300 seconds after snmpd is started, all the interfaces
are included.  So even with my patch, the CPU for snmpd will be
rather high (depending on the number if interfaces) for these first 5
minutes.

So even though I can register a callback for SNMP_CALLBACK_POST_READ_CONFIG,
I'm not sure how to limit (or prune) the interface list that is somehow
generated
in ifTable_interface.c. There's some initialization magic (m2c?) that has
to happen
to prevent *all* interfaces from being included until the 300 second cache
timer pops.

Is there an easy way to bring up snmpd and remove (or change) the interfaces
included in the IF-MIB? I have the prefix list (index_list) already filled
in at startup.

How would I do this from my post-read callback function?

Any hints would be appreciated.

Thanks,
Sam

Fwd: does netsnmp support IPv6 varbind

[Surya M. <soo...@gm...>]

*Question : Does netsnmp support IPv6 varbind as type IPAdress?*

1- *I "get bad notation" error when I am trying to send trap having IPv6
address with type IPAdress(a) as highlighted(in red italics underlined)*

[root@IWFVM00141 ~]# snmptrap -d -v 2c -c public 16.166.98.198:5163 123
.1.3.6.1.4.1.18497.2.6.2 .1.3.6.1.4.1.18497.2.2.1 s "Test Trap"
.1.3.6.1.4.1.18497.2.2.2 s "snmp_testing_start" .1.3.6.1.4.1.18497.2.2.3 i
120 .1.3.6.1.4.1.18497.2.2.4 *a 2001:4888:67:13:643:201:0:20*
.1.3.6.1.4.1.18497.2.2.4: *Bad value notation
(2001:4888:67:13:643:201:0:20)*

2- *But when I send the same trap modifying type of IPv6 address as
String(s), it goes fine without error*
[root@IWFVM00141 ~]# snmptrap -d -v 2c -c public 16.166.98.198:5163 123
.1.3.6.1.4.1.18497.2.6.2 .1.3.6.1.4.1.18497.2.2.1 s "Test Trap"
.1.3.6.1.4.1.18497.2.2.2 s "snmp_testing_start" .1.3.6.1.4.1.18497.2.2.3 i
120 .1.3.6.1.4.1.18497.2.2.4 *s 2001:4888:67:13:643:201:0:20*

Sending 198 bytes to UDP: [16.166.98.198]:5163->[0.0.0.0]:0
0000: 30 81 C3 02  01 01 04 06  70 75 62 6C  69 63 A7 81    0.......public..
0016: B5 02 04 7D  19 93 23 02  01 00 02 01  00 30 81 A6    ...}..#......0..
0032: 30 0D 06 08  2B 06 01 02  01 01 03 00  43 01 7B 30    0...+.......C.{0
0048: 19 06 0A 2B  06 01 06 03  01 01 04 01  00 06 0B 2B    ...+...........+
0064: 06 01 04 01  81 90 41 02  06 02 30 18  06 0B 2B 06    ......A...0...+.
0080: 01 04 01 81  90 41 02 02  01 04 09 54  65 73 74 20    .....A.....Test
0096: 54 72 61 70  30 21 06 0B  2B 06 01 04  01 81 90 41    Trap0!..+......A
0112: 02 02 02 04  12 73 6E 6D  70 5F 74 65  73 74 69 6E    .....snmp_testin
0128: 67 5F 73 74  61 72 74 30  10 06 0B 2B  06 01 04 01    g_start0...+....
0144: 81 90 41 02  02 03 02 01  78 30 2B 06  0B 2B 06 01    ..A.....x0+..+..
0160: 04 01 81 90  41 02 02 04  04 1C 32 30  30 31 3A 34    ....A.....2001:4
0176: 38 38 38 3A  36 37 3A 31  33 3A 36 34  33 3A 32 30    888:67:13:643:20
0192: 31 3A 30 3A  32 30                                    1:0:20

*3-  While the trap having IPv4 address with type as IPAdress(a), goes fine
without error as highlighted(in red italics underlined) *
[root@IWFVM00141 ~]# snmptrap -d -v 2c -c public 16.166.98.198:5163 123
.1.3.6.1.4.1.18497.2.6.2 .1.3.6.1.4.1.18497.2.2.1 s "Test Trap"
.1.3.6.1.4.1.18497.2.2.2 s "snmp_testing_start" .1.3.6.1.4.1.18497.2.2.3 i
120 .1.3.6.1.4.1.18497.2.2.4 *a 16.166.97.22*

Sending 174 bytes to UDP: [16.166.98.198]:5163->[0.0.0.0]:0
0000: 30 81 AB 02  01 01 04 06  70 75 62 6C  69 63 A7 81    0.......public..
0016: 9D 02 04 50  69 9C 88 02  01 00 02 01  00 30 81 8E    ...Pi........0..
0032: 30 0D 06 08  2B 06 01 02  01 01 03 00  43 01 7B 30    0...+.......C.{0
0048: 19 06 0A 2B  06 01 06 03  01 01 04 01  00 06 0B 2B    ...+...........+
0064: 06 01 04 01  81 90 41 02  06 02 30 18  06 0B 2B 06    ......A...0...+.
0080: 01 04 01 81  90 41 02 02  01 04 09 54  65 73 74 20    .....A.....Test
0096: 54 72 61 70  30 21 06 0B  2B 06 01 04  01 81 90 41    Trap0!..+......A
0112: 02 02 02 04  12 73 6E 6D  70 5F 74 65  73 74 69 6E    .....snmp_testin
0128: 67 5F 73 74  61 72 74 30  10 06 0B 2B  06 01 04 01    g_start0...+....
0144: 81 90 41 02  02 03 02 01  78 30 13 06  0B 2B 06 01    ..A.....x0...+..
0160: 04 01 81 90  41 02 02 04  40 04 10 A6  61 16          ....A...@...a.


Thanks
Surya

[Net-Snmp] Build Snmp lib in Android

[Tran Q. L. (FGA.PDC) <Li...@fs...>]

Dear Net-Snmp developer team,

Currently, I'm trying to build your project (https://sourceforge.net/p/net-snmp/code/ci/master/tree/) in Android to build it in 64 bit architecture. But when I create a project and compiler it, I got tons of error. Please help me to know what I'm doing wrong.
Following is some information about project I developed.

1.       Project create to build on Eclipse IDE

2.       Architecture: Armeabi-v7a Armeabi-v8a, x86, x86_x64

3.       Target SDK: 21

Please inform to me if you need any information more. I look forward to hearing from you.

Thanks and best regards,
LinhTQ2

net-snmpd timeout on HPUX due to diverging interface data information

[Menase, L. (TS E. R. Team) <lau...@hp...>]

Hi net-snmp-coders,

Analyzing why when done to hpux  time snmpwalk -v 1 -c public localhost 1.3.6.1.2.1.25.3.2 always getting timeout, I found that it is due to the way it fetches the mib info using nm library.
For each query for instance
snmpwalk -v 1 -c public localhost 1.3.6.1.2.1.25.3.2.1.3.1035
HOST-RESOURCES-MIB::hrDeviceDescr.1035 = STRING: network interface lan900

It scans the full interface table, but reload the interface table at every calls.
As a consequence
Fetching
1.3.6.1.2.1.25.3.2.1.3.1025  need 3 fetch of the interface table, while 1.3.6.1.2.1.25.3.2.1.3.1079 ( lan944) will fetch it 3 + 5 + 7 +...+ 109 times  so 3024 times


Tests had been made on 5.6.1.1 for compilation facility but the same apply to 5.8

Since the function  Interface_Scan_Next() is always called  to walk the interface table after an Interface_Scan_Init()  which always reset the scanIndex to 0,  I propose to get the count and the if_ptr only when scanIndex is 0 ( or ifptr is 0)
Changes are the same on 5.8 but in the function
Interface_Scan_NextInt() and not Interface_Scan_Next()

int
Interface_Scan_Next(short *Index, char *Name, nmapi_phystat * Retifnet)
{
    static nmapi_phystat *if_ptr = (nmapi_phystat *) 0;
-     int             count = Interface_Scan_Get_Count();
+    static int             count = 0;
    unsigned int    ulen;
    int             ret;
+    int count_prev;

-        if (count) {
-             if_ptr =
-                 (nmapi_phystat *) malloc(sizeof(nmapi_phystat) * count);
-             if (if_ptr == NULL)
-                 return (0);
+    if (!if_ptr || (saveIndex==0)) {
+        count_prev=count;
+        count=Interface_Scan_Get_Count();
+        if (count) {
+            if (!if_ptr){
+                if_ptr =
+                     (nmapi_phystat *) malloc(sizeof(nmapi_phystat) * count);
+            } else if (count != count_prev)    {
+                if_ptr =
+                     (nmapi_phystat *) realloc((void *)if_ptr,sizeof(nmapi_phystat) * count);
+            }
+            if (if_ptr == NULL) {
+                return (0);
+                count = 0;
+            }
+            ulen = (unsigned int) count *sizeof(nmapi_phystat);
+            if ((ret = get_physical_stat(if_ptr, &ulen)) < 0)
+                return (0);             /* EOF */
+
        } else
            return (0);         /* EOF */

    }

    if (saveIndex >= count)
        return (0);             /* EOF */

-     ulen = (unsigned int) count *sizeof(nmapi_phystat);
-     if ((ret = get_physical_stat(if_ptr, &ulen)) < 0)
-          return (0);             /* EOF */

    if (Retifnet)
        *Retifnet = if_ptr[saveIndex];
    if (Name)
        strcpy(Name, if_ptr[saveIndex].nm_device);
    saveIndex++;
    if (Index)
        *Index = saveIndex;
    return (1);                 /* DONE */
}


Best regards,
Laurent Menase

Re: [netsnmp-coders] missing information in logmatch trap

[Thommandra G. <trg...@gm...>]

Thanks a lot Bill.

I will use the inbuf variable to send a trap(will use a dummy custom MIB
table) using sendv2_trap().

Thanks for the help.

Regards,
Gowtham

On Sun, Sep 29, 2019, 20:57 Bill Fenner <fe...@gm...> wrote:

> On Sat, Sep 28, 2019 at 10:14 AM Thommandra Gowtham <
> trg...@gm...> wrote:
>
>> Thank you Bill for your response.
>>
>> When you said that I have configured two separate features, can you
>> explain? How else can we get a logmatch trap by just one directive?
>>
>
> You currently can not. That is how I imagine the feature you're looking
> for would be implemented.  What you have now is: logmatch increments a
> counter when the log is seen, and disman sends you a trap when the counter
> changes.  It's the fact that the interface between those pieces is a
> counter that means that you can not get the actual message.
>
> For b), which part of the code has the actual string that is matched? I
>> can probably use it to raise a trap if needed.
>>
>
>
> https://github.com/net-snmp/net-snmp/blob/master/agent/mibgroup/ucd-snmp/logmatch.c#L291
> If you want to know just what part of the line matched the regexp, then
> you will have to pass in nmatch and pmatch arguments to regexec(),
> otherwise if you just want the whole line it's in "inbuf" at that point.
>
>   Bill
>
>

psuedo IP address in trap payload

[Pushpa T. <pus...@gm...>]

Hi All,

Does net-snmp support providing Psuedo IP in outgoing trap

*settings:*
1.  Linux Device has vlans
eth1.222 IP : 192.168.1.222   <------ Interface-1
eth1.444 IP : 192.168.2.444    <------ Interface-2

Uses 'snmptrap' tool to send traps out.

*Requirement:*
1. All traps should go out from eth1.444. But it should have IP of eth1.222
(i.e 192.168.1.222). Is this possible via snmp?


Thank You,
Pushpa.T

Re: [netsnmp-coders] missing information in logmatch trap

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

On Sat, Sep 28, 2019 at 10:14 AM Thommandra Gowtham <trg...@gm...>
wrote:

> Thank you Bill for your response.
>
> When you said that I have configured two separate features, can you
> explain? How else can we get a logmatch trap by just one directive?
>

You currently can not. That is how I imagine the feature you're looking for
would be implemented.  What you have now is: logmatch increments a counter
when the log is seen, and disman sends you a trap when the counter
changes.  It's the fact that the interface between those pieces is a
counter that means that you can not get the actual message.

For b), which part of the code has the actual string that is matched? I can
> probably use it to raise a trap if needed.
>

https://github.com/net-snmp/net-snmp/blob/master/agent/mibgroup/ucd-snmp/logmatch.c#L291
If you want to know just what part of the line matched the regexp, then you
will have to pass in nmatch and pmatch arguments to regexec(), otherwise if
you just want the whole line it's in "inbuf" at that point.

  Bill

Re: [netsnmp-coders] missing information in logmatch trap

[Thommandra G. <trg...@gm...>]

Thank you Bill for your response.

When you said that I have configured two separate features, can you
explain? How else can we get a logmatch trap by just one directive?

For b), which part of the code has the actual string that is matched? I can
probably use it to raise a trap if needed.

I have raised a request as suggested by you
https://github.com/net-snmp/net-snmp/issues/19

On Fri, Sep 27, 2019 at 11:22 PM Bill Fenner <fe...@gm...> wrote:

> Hi Gowtham,
>
> Please file your request at https://github.com/net-snmp/net-snmp/issues .
> The reason the info is not present in the trap is because you have
> configured two separate features:
>
> 1. count log file matches in the logMatch table - note that there is no
> place in this table for a list of matches -
> http://www.net-snmp.org/docs/mibs/ucdavis.html#logMatchTable
> 2. report via DISMAN (monitor) when the count goes up
>
> In order to provide the actual match, the code would have to be changed to
> either
> a) send the trap from inside the logMatch code, and/or
> b) maintain a list of matches in a new table
>
> so it's not as straightforward as it may sound.
>
>   Bill
>
> On Tue, Sep 24, 2019 at 2:26 AM Thommandra Gowtham <trg...@gm...>
> wrote:
>
>> Hi Jeff,
>>
>> Can I get a response for the request?
>>
>> Thanks,
>> Gowtham
>>
>> On Sat, Sep 7, 2019 at 9:23 AM Thommandra Gowtham <trg...@gm...>
>> wrote:
>>
>>> Jeff,
>>>
>>> Thanks for your reply.
>>>
>>> It was a deliberate mail to net-snmp-coders. Because, I knew about the
>>> pattern matching but that would not suffice because we get a trap like
>>> below when we give a '.*' in pattern
>>>
>>> DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3022) 0:00:30.22
>>> SNMPv2-MIB::snmpTrapOID.0 = OID: DISMAN-EVENT-MIB::mteTriggerFired
>>> DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: Log Match
>>> DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING:
>>> DISMAN-EVENT-MIB::mteHotContextName.0 = STRING:
>>> DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::logMatchCurrentCount.1
>>> DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 9 UCD-SNMP-MIB::logMatchName.1 =
>>> STRING: loginFailure UCD-SNMP-MIB::logMatchFilename.1 = STRING:
>>> /var/log/auth.log UCD-SNMP-MIB::logMatchCurrentCount.1 = INTEGER: 9
>>> UCD-SNMP-MIB::logMatchRegEx.1 = STRING: Failed password .*
>>>
>>> For the following config,
>>> logmatch loginFailure /var/log/auth.log 30 Failed password for .*
>>> and line in log fine as below
>>> Sep  5 19:51:43  sshd[23557]: Failed password for root from xx.xx.xx.xx
>>> port 41569 ssh2
>>>
>>> It will match the string but it will not print the username in the trap
>>> data. So, I was looking for any code changes that an be done to make it
>>> expand the pattern and then send that data in trap.
>>>
>>> REgards,
>>> Gowtham
>>>
>>> On Sat, Sep 7, 2019 at 2:26 AM Jeff Gehlbach <je...@op...> wrote:
>>>
>>>> On 9/5/19 10:58 PM, Thommandra Gowtham wrote:
>>>>
>>>> > - How can we get more information in a logmatch trap other than the
>>>> > pattern matched?
>>>>
>>>> Making your pattern match more text should do the trick. For example:
>>>>
>>>> logmatch loginFailure /var/log/auth.log 30 Failed password for .*
>>>>
>>>> BTW, this kind of question isn't really what the net-snmp-coders list is
>>>> for. The net-snmp-users list is a better fit:
>>>>
>>>> https://sourceforge.net/projects/net-snmp/lists/net-snmp-users
>>>>
>>>> -jeff
>>>>
>>>>
>>>> _______________________________________________
>>>> Net-snmp-coders mailing list
>>>> Net...@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
>>
>

Re: [netsnmp-coders] missing information in logmatch trap

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

Hi Gowtham,

Please file your request at https://github.com/net-snmp/net-snmp/issues .
The reason the info is not present in the trap is because you have
configured two separate features:

1. count log file matches in the logMatch table - note that there is no
place in this table for a list of matches -
http://www.net-snmp.org/docs/mibs/ucdavis.html#logMatchTable
2. report via DISMAN (monitor) when the count goes up

In order to provide the actual match, the code would have to be changed to
either
a) send the trap from inside the logMatch code, and/or
b) maintain a list of matches in a new table

so it's not as straightforward as it may sound.

  Bill

On Tue, Sep 24, 2019 at 2:26 AM Thommandra Gowtham <trg...@gm...>
wrote:

> Hi Jeff,
>
> Can I get a response for the request?
>
> Thanks,
> Gowtham
>
> On Sat, Sep 7, 2019 at 9:23 AM Thommandra Gowtham <trg...@gm...>
> wrote:
>
>> Jeff,
>>
>> Thanks for your reply.
>>
>> It was a deliberate mail to net-snmp-coders. Because, I knew about the
>> pattern matching but that would not suffice because we get a trap like
>> below when we give a '.*' in pattern
>>
>> DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3022) 0:00:30.22
>> SNMPv2-MIB::snmpTrapOID.0 = OID: DISMAN-EVENT-MIB::mteTriggerFired
>> DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: Log Match
>> DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING:
>> DISMAN-EVENT-MIB::mteHotContextName.0 = STRING:
>> DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::logMatchCurrentCount.1
>> DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 9 UCD-SNMP-MIB::logMatchName.1 =
>> STRING: loginFailure UCD-SNMP-MIB::logMatchFilename.1 = STRING:
>> /var/log/auth.log UCD-SNMP-MIB::logMatchCurrentCount.1 = INTEGER: 9
>> UCD-SNMP-MIB::logMatchRegEx.1 = STRING: Failed password .*
>>
>> For the following config,
>> logmatch loginFailure /var/log/auth.log 30 Failed password for .*
>> and line in log fine as below
>> Sep  5 19:51:43  sshd[23557]: Failed password for root from xx.xx.xx.xx
>> port 41569 ssh2
>>
>> It will match the string but it will not print the username in the trap
>> data. So, I was looking for any code changes that an be done to make it
>> expand the pattern and then send that data in trap.
>>
>> REgards,
>> Gowtham
>>
>> On Sat, Sep 7, 2019 at 2:26 AM Jeff Gehlbach <je...@op...> wrote:
>>
>>> On 9/5/19 10:58 PM, Thommandra Gowtham wrote:
>>>
>>> > - How can we get more information in a logmatch trap other than the
>>> > pattern matched?
>>>
>>> Making your pattern match more text should do the trick. For example:
>>>
>>> logmatch loginFailure /var/log/auth.log 30 Failed password for .*
>>>
>>> BTW, this kind of question isn't really what the net-snmp-coders list is
>>> for. The net-snmp-users list is a better fit:
>>>
>>> https://sourceforge.net/projects/net-snmp/lists/net-snmp-users
>>>
>>> -jeff
>>>
>>>
>>> _______________________________________________
>>> Net-snmp-coders mailing list
>>> Net...@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
>

Re: snmpv3 context partial output

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

On Mon, Sep 23, 2019 at 11:48 AM T S, SURYA <sur...@hp...> wrote:

> So is there any way to merge null subtree with context subtree in netsnmp,
> so that I can get access to entire oid with context specifc oids on
> snmpwalk with context.
>

I looked into this a couple of months ago.  In my opinion, it would require
rewriting the OID tree code to support this feature well.

If you had a list of registrations that you'd like to have appear in the
alternate contexts, then for each context you *might* be able to register a
proxy handler in your snmpd.conf for each registration.  E.g.,

proxy [snmp credentials] -Cn VRF-1 system localhost

I haven't tried this because I didn't want to rewrite the config file for
every VRF.

  Bill

Re: [netsnmp-coders] missing information in logmatch trap

[Thommandra G. <trg...@gm...>]

Hi Jeff,

Can I get a response for the request?

Thanks,
Gowtham

On Sat, Sep 7, 2019 at 9:23 AM Thommandra Gowtham <trg...@gm...>
wrote:

> Jeff,
>
> Thanks for your reply.
>
> It was a deliberate mail to net-snmp-coders. Because, I knew about the
> pattern matching but that would not suffice because we get a trap like
> below when we give a '.*' in pattern
>
> DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3022) 0:00:30.22
> SNMPv2-MIB::snmpTrapOID.0 = OID: DISMAN-EVENT-MIB::mteTriggerFired
> DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: Log Match
> DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING:
> DISMAN-EVENT-MIB::mteHotContextName.0 = STRING:
> DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::logMatchCurrentCount.1
> DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 9 UCD-SNMP-MIB::logMatchName.1 =
> STRING: loginFailure UCD-SNMP-MIB::logMatchFilename.1 = STRING:
> /var/log/auth.log UCD-SNMP-MIB::logMatchCurrentCount.1 = INTEGER: 9
> UCD-SNMP-MIB::logMatchRegEx.1 = STRING: Failed password .*
>
> For the following config,
> logmatch loginFailure /var/log/auth.log 30 Failed password for .*
> and line in log fine as below
> Sep  5 19:51:43  sshd[23557]: Failed password for root from xx.xx.xx.xx
> port 41569 ssh2
>
> It will match the string but it will not print the username in the trap
> data. So, I was looking for any code changes that an be done to make it
> expand the pattern and then send that data in trap.
>
> REgards,
> Gowtham
>
> On Sat, Sep 7, 2019 at 2:26 AM Jeff Gehlbach <je...@op...> wrote:
>
>> On 9/5/19 10:58 PM, Thommandra Gowtham wrote:
>>
>> > - How can we get more information in a logmatch trap other than the
>> > pattern matched?
>>
>> Making your pattern match more text should do the trick. For example:
>>
>> logmatch loginFailure /var/log/auth.log 30 Failed password for .*
>>
>> BTW, this kind of question isn't really what the net-snmp-coders list is
>> for. The net-snmp-users list is a better fit:
>>
>> https://sourceforge.net/projects/net-snmp/lists/net-snmp-users
>>
>> -jeff
>>
>>
>> _______________________________________________
>> Net-snmp-coders mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>>
>

Re: SNMPv3: authPriv: Scoped PDU: ASN.1 Parse error

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

Hi Krishna,

Can you please try the Net-SNMP-5.7.3 with OpenSSL-1.1.0g once? Hope there
will be no issues with AES/DES!

On Fri, Sep 13, 2019 at 8:08 PM Krishna Chaitanya <cha...@gm...>
wrote:

> On Fri, Sep 13, 2019 at 3:07 PM Krishna Chaitanya
> <cha...@gm...> wrote:
> >
> > On Fri, Sep 13, 2019 at 12:58 AM Krishna Chaitanya
> > <cha...@gm...> wrote:
> > >
> > > Hi Guys,
> > >
> > > I am facing the exact problem
> > > https://sourceforge.net/p/net-snmp/mailman/message/19231076/
> > >
> > > I am using authPriv, snmpd says USM processing completed, user
> > > verified, but when trying to process scopedPDU it fails with "ASN.1
> > > parse error" Any ideas?
> > >
> > > If I give EngineID and Credentials, Wireshark is able to decrypt the
> > > packet and display as getBulkRequest with proper OIDs.
> > > Logs:
> > >
> > > dumph_recv:           SNMP Version  02 01 03     Integer: 3 (0x03)
> > > dumph_recv:           SNMPv3 Message
> > > dumph_recv:             SNMP Version Number  02 01 03     Integer: 3
> (0x03)
> > > dumph_recv:             msgGlobalData
> > > dumph_recv:               msgID  02 04 32 93 78 21     Integer:
> > > 848525345 (0x32937821)
> > > dumph_recv:               msgMaxSize  02 03 00 FF E3     Integer:
> 65507 (0xFFE3)
> > > dumph_recv:               msgFlags  04 01 07     String: .
> > > dumph_recv:               msgSecurityModel  02 01 03     Integer: 3
> (0x03)
> > > dumph_recv:             SM msgSecurityParameters
> > > usm: USM processing begun...
> > > dumph_recv:               msgAuthoritativeEngineID  #################
> > > dumph_recv:               msgAuthoritativeEngineBoots #######
> > > dumph_recv:               msgAuthoritativeEngineTime #########
> > > dumph_recv:               msgUserName  #######
> > > dumph_recv:               msgAuthenticationParameters  ###########
> > > dumph_recv:               msgPrivacyParameters  ##########
> > > usm: match on user privUser
> > > usm: Verification succeeded.
> > > usm: USM processing completed.
> > > dumph_recv:               ScopedPDU
> > > snmp_parse: Parsed SNMPv3 message (secName:privUser,
> > > secLevel:authPriv): ASN.1 parse error in message
> > >
> > > Any help is appreciated.
> > >
> > The wireshark reports "Data not conforming to RFC3411", there was a bug
> in
> > earlier version, but even the latest version says this, so, probably
> > something wrong
> > with ASN.1 format? It expects the EngineID to be 8 bytes (after
> > removing the 5 bytes of
> > enterprise + 5th octet) for NET-SNMP enterprise, but its actually 12
> bytes?
> > 04 11 80 00 1F 88 80 D2 F2 6E 14 8C 5F 4C 5D 00 (random + time)
> >
> > If I configure a custom engineId in snmpd.conf, then the wireshark
> > error is gone, but the issue
> > of ASN.1 error still persists.
> >
> > 04 0C 80 00 1f 88 04 22 68 65 6c 6c 6f 22 ("hello")
> Did some experiments: At least able to get 1 combo working.
>
> With
> NET-SNMP version:  5.7.3 + OpenSSL 1.0.2g  1 Mar 2016
>   Both AES and DES doesn't work
>
> With
> NET-SNMP version:  5.8 (git) + OpenSSL 1.1.1  11 Sep 2018
> AES works but DES doesn't.
>
> In the case of DES, the decrypted Scoped PDU is different compared
> to Wireshark, so, probably decrypted wrongly.
>
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>


-- 
With Best Regards,
Anandaprabu V <https://www.linkedin.com/in/anandaprabu-v-10867671/>
Cell : +91 9500650885 | Skype : prabuvaradharajan

Fwd: snmptrapd

[jayshankar n. <jay...@gm...>]

>
> Hi,
>>
>> I  am using variant of snmptrapd.
>>
>
> In what way is it a variant?
>

It using the same piece of code till snmp_input. The delay is observed in
snmp_input, After
which we process the pdu

>
>
>> The snmptrapd is processing trap packet at 4min delay. Why so much
>> delay??.
>>
>
> Does this delay happen with unmodified snmptrapd?.
>
Till snmp_input the code is same. Then the code is modified. the log in
orginal snmptrapd shows no delay.


>
>   Bill
>


Thanks,
Jayshankar

<https://www.avast.com/en-in/recommend?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=default3&tag=f0d330c6-6310-4708-ab04-87ae5d81508e>
I’m
protected online with Avast Free Antivirus. Get it here — it’s free forever.
<https://www.avast.com/en-in/recommend?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=default3&tag=f0d330c6-6310-4708-ab04-87ae5d81508e>
<#m_4525411273052183496_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

snmpv3 context partial output

[T S, S. <sur...@hp...>]

Hi All,

I need a help regarding snmpv3 context implementation in netsnmp.

I am doing an snmpv3 walk with context mapped to a VRF internally.
I am only getting oids of features registered with netsnmp_register_mib() with context name in reginfo. These feature run particular to VRF, eg: BGP, OSPF running in VRF_1,  VRF_2 etc..

But I am missing all other common oid's with this walk. Eg: system mib, host-resources mibs etc. and this resulting partial results in root oid walk. System mib code in net-snmp doesn't have context support.
I am getting access to enire oid tree w/o context related oids (eg bgp,ospf oids)on default context ie. NULL("") context walk.

So is there any way to merge null subtree with context subtree in netsnmp, so that I can get access to entire oid with context specifc oids on snmpwalk with context.
Please also let me know whether we can provide this support via snmpd.conf, or else how we can make this work with netsnmp code.


Thanks,
Surya




Thanks in advance.




Thanks,
Surya T S
[logo]

Re: snmptrapd

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

On Wed, Sep 18, 2019 at 7:13 AM jayshankar nair <jay...@gm...>
wrote:

> Hi,
>
> I  am using variant of snmptrapd.
>

In what way is it a variant?


> The snmptrapd is processing trap packet at 4min delay. Why so much delay??.
>

Does this delay happen with unmodified snmptrapd?

  Bill

snmptrapd

[jayshankar n. <jay...@gm...>]

Hi,

I  am using variant of snmptrapd. The snmptrapd is processing trap packet
at 4min delay. Why so much delay??.

The delay is observed in function
int
snmp_input(int op, netsnmp_session *session,
           int reqid, netsnmp_pdu *pdu, void *magic) in
snmptrapd_handlers.c.

Its here i am processing the pdu and extracting variables.

Any inputs.

Thanks,
Jayshankar

Re: MAC Address As Index

[Krishna C. <cha...@gm...>]

On Tue, Sep 17, 2019 at 5:09 PM Krishna Chaitanya
<cha...@gm...> wrote:
>
> On Tue, Sep 17, 2019 at 4:51 PM Bill Fenner <fe...@gm...> wrote:
> >
> > On Tue, Sep 17, 2019 at 4:27 AM Krishna Chaitanya <cha...@gm...> wrote:
> >>
> >> On Tue, Sep 17, 2019 at 5:18 AM Bill Fenner <fe...@gm...> wrote:
> >> >
> >> > You can do this if you use snmp_varlist_add_variable() to create the index info (you can't use netsnmp_table_helper_add_indexes).  The code would be something like
> >> >
> >> >     table_info = SNMP_MALLOC_TYPEDEF( netsnmp_table_registration_info );
> >> >     snmp_varlist_add_variable(&table_info->indexes,
> >> >                                   NULL,
> >> >                                   0,
> >> >                                   ASN_TYPE_OF_IFACE_NAME,
> >> >                                   NULL,
> >> >                                   0);
> >> >     snmp_varlist_add_variable(&table_info->indexes,
> >> >                                   NULL,
> >> >                                   0,
> >> >                                   ASN_IMPLIED_OCTET_STR,
> >> >                                   "XXXXXX",
> >> >                                   6);
> >> >     snmp_varlist_add_variable(&table_info->indexes,
> >> >                                   NULL,
> >> >                                   0,
> >> >                                   ASN_TYPE_OF_HIST_CLASS,
> >> >                                   NULL,
> >> >                                   0);
> >> >     snmp_varlist_add_variable(&table_info->indexes,
> >> >                                   NULL,
> >> >                                   0,
> >> >                                   ASN_TYPE_OF_HISTBIN_INDEX,
> >> >                                   NULL,
> >> >                                   0);
> >> >
> >> Thanks, Bill. I was using  "netsnmp_table_set_add_indexes" for the
> >> initial addition (don't have access to index_data but only type),
> >
> >
> > You should be able to replace "table_info" above by "tset->table" and add the 4 calls to snmp_varlist_add_variable in place of the call to "netsnmp_table_set_add_indexes".
> Yes.
> >> and then when the data is available I either use
> >> "netsnmp_table_dataset_replace_row/netsnmp_table_dataset_add_row"
> >> using the API "netsnmp_table_row_add_index" for index.
> >
> >
> > This will continue to work.  The real difference is setting vp->val_len in the indexes that you supply when you're registering the table.  For most types this is not relevant but for the ASN_PRIV_IMPLIED types if you do not set the length, as you saw it will consume the whole rest of the data and not parse the indexes from the OID after that.
> Okay, I will try that, in my case the Len is fixed anyway.
I just gave a dummy string with proper len while adding the
table_data_index and gave proper string and len while
adding the row index, it seems to be working fine.

Thanks a lot for the help, Bill.

Re: MAC Address As Index

[Krishna C. <cha...@gm...>]

On Tue, Sep 17, 2019 at 4:51 PM Bill Fenner <fe...@gm...> wrote:
>
> On Tue, Sep 17, 2019 at 4:27 AM Krishna Chaitanya <cha...@gm...> wrote:
>>
>> On Tue, Sep 17, 2019 at 5:18 AM Bill Fenner <fe...@gm...> wrote:
>> >
>> > You can do this if you use snmp_varlist_add_variable() to create the index info (you can't use netsnmp_table_helper_add_indexes).  The code would be something like
>> >
>> >     table_info = SNMP_MALLOC_TYPEDEF( netsnmp_table_registration_info );
>> >     snmp_varlist_add_variable(&table_info->indexes,
>> >                                   NULL,
>> >                                   0,
>> >                                   ASN_TYPE_OF_IFACE_NAME,
>> >                                   NULL,
>> >                                   0);
>> >     snmp_varlist_add_variable(&table_info->indexes,
>> >                                   NULL,
>> >                                   0,
>> >                                   ASN_IMPLIED_OCTET_STR,
>> >                                   "XXXXXX",
>> >                                   6);
>> >     snmp_varlist_add_variable(&table_info->indexes,
>> >                                   NULL,
>> >                                   0,
>> >                                   ASN_TYPE_OF_HIST_CLASS,
>> >                                   NULL,
>> >                                   0);
>> >     snmp_varlist_add_variable(&table_info->indexes,
>> >                                   NULL,
>> >                                   0,
>> >                                   ASN_TYPE_OF_HISTBIN_INDEX,
>> >                                   NULL,
>> >                                   0);
>> >
>> Thanks, Bill. I was using  "netsnmp_table_set_add_indexes" for the
>> initial addition (don't have access to index_data but only type),
>
>
> You should be able to replace "table_info" above by "tset->table" and add the 4 calls to snmp_varlist_add_variable in place of the call to "netsnmp_table_set_add_indexes".
Yes.
>> and then when the data is available I either use
>> "netsnmp_table_dataset_replace_row/netsnmp_table_dataset_add_row"
>> using the API "netsnmp_table_row_add_index" for index.
>
>
> This will continue to work.  The real difference is setting vp->val_len in the indexes that you supply when you're registering the table.  For most types this is not relevant but for the ASN_PRIV_IMPLIED types if you do not set the length, as you saw it will consume the whole rest of the data and not parse the indexes from the OID after that.
Okay, I will try that, in my case the Len is fixed anyway.