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

Re: MAC Address As Index

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

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".

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.

  Bill

Re: MAC Address As Index

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

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),
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.

I guess it all boils down to using netsnmp_table_data_add_index (using
only types) Vs netsnmp_table_row_add_index (types and indexes).

agent_check_process(0)

[Deepak S. <sac...@gm...>]

I am using net-snmp 5.7. Using Agent X.
I have written a code like

while(1){
-
-
-
if(flag)
agent_check_process(0);
 }

Whenever flag changes  0 to 1 it reconnect Agent X every time and program
has to wait 10 to15 seconds until it reconnect and process pending requests.
1. Is here any way not to reconnect every time??  or just temporary suspend
the agent_check_process(0) .
2. I don`t want to process pending requests.

Thanks in Advance.

Re: MAC Address As Index

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

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);


  Bill


On Mon, Sep 16, 2019 at 10:23 AM Krishna Chaitanya <cha...@gm...>
wrote:

> On Tue, Sep 3, 2019 at 5:23 PM Krishna Chaitanya
> <cha...@gm...> wrote:
> >
> > On Tue, Aug 27, 2019 at 2:12 PM Krishna Chaitanya
> > <cha...@gm...> wrote:
> > >
> > > On Mon, Aug 26, 2019 at 9:22 PM Bill Fenner <fe...@gm...> wrote:
> > > >
> > > > On Tue, Aug 20, 2019 at 8:45 AM Krishna Chaitanya <
> cha...@gm...> wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> When using MAC Address as an index ( I am using MacAddress type from
> > > >> SNMPv2-TC.) the output is incorrect because the length of the string
> > > >> is prefixed as mac address is defined as OCTET STR there is an extra
> > > >> byte and the last byte of mac address is interpreted as next OID.
> > > >>
> > > >> snmpwalk:
> > > >>    HistValue."wlp8s0f0".'....B.'.hist_2.2.19
> > > >> snmpwalk -OX
> > > >>   HistValue["wlp8s0f0"][STRING: 06:00:90:e6:42:99][hist_2][2].19
> > > >>
> > > >> In the above examples last but one OID 2 is hist_2. Is there a way
> to
> > > >> disable prefixing of length?
> > > >
> > > >
> > > > The prefixing of length is done by the agent.  Are you asking about
> a MIB module that you implemented?  Try changing your object definition
> from ASN_OCTET_STR to ASN_PRIV_IMPLIED_OCTET_STR.
> > > Yes, I am using my own MIB and changing to ASN_PRIV_IMPLIED_OCTET_STR
> > > in the subagent worked.
> > > Thanks, Bill.
> >
> > After this change, I was getting a lot of duplicate data exists
> > errors, upon further debugging found a similar issue
> > which is quite old
> >
> https://www.mail-archive.com/net...@li.../msg06286.html
> .
> > In the current code even though there is support to handle IMPLIED
> > strings, but subsequent indexes are not processed.
> > See snippet below: out of 4 indexes only 2 are processed (the indexes
> > after ASN_PRIV_IMPLIED_OCTET_STR
> > failed to parse. Any ideas?
> >
> > histStatsData: Request Mode is: 160 name: wlp8s0f0 col: 3
> > histStatsData: Add row
> > duplicate table data attempted to be entered. row exists
> > helper:table:req: Got GETNEXT (161) mode request for handler table:
> > base oid:SNMPv2-SMI::mib-2.43932.2.2
> > helper:table:col:   have at least a column (3)
> > helper:table:     have 17 bytes of index
> > helper:table:   looking for 4 indexes
> >
> > parse_oid_indexes: Parsed str(4): wlp8s0f0
> > helper:table:   got 1 (incomplete=0)
> >
> > parse_oid_indexes: Parsed str(196):
> > helper:table:   got 1 (incomplete=0)
> >
> > helper:table:   oid indexes not complete:
> >
> SNMPv2-SMI::mib-2.43932.2.2.1.3.8.119.108.112.56.115.48.102.48.0.128.225.66.153.1.2.15
> > helper:table:results:   found 2 indexes
> > helper:table:results:   column: 3, indexes: 2   index: type=4(04),
> > value=STRING: "wlp8s0f0"   index: type=196(c4), value=Variable has bad
> > type
> >
>
> As a workaround moved the MAC address index to last and it works fine
> with ASN_IMPLIED_OCTER_STR, this should be good enough for parsing
> programmatically, but
> for end-user its a bit counter-intuitive, having MAC Address as the
> 2nd index out of 4 is
> more readable. This was the diff in MIB:
>
> -  INDEX { ifaceName, remoteMAC, HistClass, HistBinIndex}
> +  INDEX { ifaceName, HistClass, HistBinIndex, remoteMAC}
>

Re: MAC Address As Index

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

On Tue, Sep 3, 2019 at 5:23 PM Krishna Chaitanya
<cha...@gm...> wrote:
>
> On Tue, Aug 27, 2019 at 2:12 PM Krishna Chaitanya
> <cha...@gm...> wrote:
> >
> > On Mon, Aug 26, 2019 at 9:22 PM Bill Fenner <fe...@gm...> wrote:
> > >
> > > On Tue, Aug 20, 2019 at 8:45 AM Krishna Chaitanya <cha...@gm...> wrote:
> > >>
> > >> Hi,
> > >>
> > >> When using MAC Address as an index ( I am using MacAddress type from
> > >> SNMPv2-TC.) the output is incorrect because the length of the string
> > >> is prefixed as mac address is defined as OCTET STR there is an extra
> > >> byte and the last byte of mac address is interpreted as next OID.
> > >>
> > >> snmpwalk:
> > >>    HistValue."wlp8s0f0".'....B.'.hist_2.2.19
> > >> snmpwalk -OX
> > >>   HistValue["wlp8s0f0"][STRING: 06:00:90:e6:42:99][hist_2][2].19
> > >>
> > >> In the above examples last but one OID 2 is hist_2. Is there a way to
> > >> disable prefixing of length?
> > >
> > >
> > > The prefixing of length is done by the agent.  Are you asking about a MIB module that you implemented?  Try changing your object definition from ASN_OCTET_STR to ASN_PRIV_IMPLIED_OCTET_STR.
> > Yes, I am using my own MIB and changing to ASN_PRIV_IMPLIED_OCTET_STR
> > in the subagent worked.
> > Thanks, Bill.
>
> After this change, I was getting a lot of duplicate data exists
> errors, upon further debugging found a similar issue
> which is quite old
> https://www.mail-archive.com/net...@li.../msg06286.html.
> In the current code even though there is support to handle IMPLIED
> strings, but subsequent indexes are not processed.
> See snippet below: out of 4 indexes only 2 are processed (the indexes
> after ASN_PRIV_IMPLIED_OCTET_STR
> failed to parse. Any ideas?
>
> histStatsData: Request Mode is: 160 name: wlp8s0f0 col: 3
> histStatsData: Add row
> duplicate table data attempted to be entered. row exists
> helper:table:req: Got GETNEXT (161) mode request for handler table:
> base oid:SNMPv2-SMI::mib-2.43932.2.2
> helper:table:col:   have at least a column (3)
> helper:table:     have 17 bytes of index
> helper:table:   looking for 4 indexes
>
> parse_oid_indexes: Parsed str(4): wlp8s0f0
> helper:table:   got 1 (incomplete=0)
>
> parse_oid_indexes: Parsed str(196):
> helper:table:   got 1 (incomplete=0)
>
> helper:table:   oid indexes not complete:
> SNMPv2-SMI::mib-2.43932.2.2.1.3.8.119.108.112.56.115.48.102.48.0.128.225.66.153.1.2.15
> helper:table:results:   found 2 indexes
> helper:table:results:   column: 3, indexes: 2   index: type=4(04),
> value=STRING: "wlp8s0f0"   index: type=196(c4), value=Variable has bad
> type
>

As a workaround moved the MAC address index to last and it works fine
with ASN_IMPLIED_OCTER_STR, this should be good enough for parsing
programmatically, but
for end-user its a bit counter-intuitive, having MAC Address as the
2nd index out of 4 is
more readable. This was the diff in MIB:

-  INDEX { ifaceName, remoteMAC, HistClass, HistBinIndex}
+  INDEX { ifaceName, HistClass, HistBinIndex, remoteMAC}

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

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

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.

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

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

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")

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

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

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.

-- 
Thanks,
Regards,
Chaitanya T K.

Re: MAC Address As Index

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

On Thu, Sep 12, 2019 at 6:59 PM Krishna Chaitanya
<cha...@gm...> wrote:
>
> On Wed, Sep 11, 2019 at 3:04 PM Niels Baggesen
> <nb...@us...> wrote:
> >
> > On Wed, Sep 11, 2019 at 12:40:38PM +0530, Krishna Chaitanya wrote:
> > > > BTW, somehow the response from Neils is missed but found it in the archive.
> > > >
> > > > https://www.mail-archive.com/net...@li.../msg21705.html
> > > >
> > > > MacAddress TC from SNMPv2-TC is a fixed size string, so, the length
> > > > should not be prefixed.
> > > >
> > >
> > > Any ideas on how to get proper MAC address display without any side
> > > effects? Any help is appreciated.
> >
> > The MacAddress TC mentioned above has a DISPLAY-HINT "1x:", does that
> > not display the way you want? Otherwise show us what you see, and what
> > is wrong with it.
> >
> Missed your reply again, now added filters and then found it.
>
> Yes, the TC should work properly, but unfortunately, it doesn't, My
> display is as below:
> You can see that the "6" is prefixed and ".1/.2/.3" are part of MAC addresses.
>
> This may not be a display only problem, currently, I am debugging a case where
> deleting a single entry from the table makes it go haywire, it deletes
> the wrong entry,
> the same issue could probably be the reason (not sure though).

FYI, Just tried changing the MAC address the problem persists, so, this issue
is not the reason.
>
> $ snmptable -v3 -a MD5 -l authNoPriv localhost -OX -Ci
>                         index mpduTx
> ["wlp1s0"][6:52:54:0:c8:53].1    302
> ["wlp1s0"][6:52:54:0:c8:53].2    307
> ["wlp1s0"][6:52:54:0:c8:53].3    328
>
>
> The MIB entry snippets are as below:
>
> MacAddress, TEXTUAL-CONVENTION FROM SNMPv2-TC
> ...
> bwtBh2GenStatsEntry OBJECT-TYPE
>   SYNTAX BwtBh2GenStatsEntry
>   MAX-ACCESS not-accessible
>   STATUS current
>   DESCRIPTION
>     "A row in BH2 Gen stats table"
>   INDEX { ifaceName, remoteMAC }
>   ::= {bwtBh2GenStatsTable 1}
> ....
> remoteMAC OBJECT-TYPE
>        SYNTAX MacAddress
>        MAX-ACCESS not-accessible
>        STATUS current
>        DESCRIPTION
>            "Remote MAC address to which these statistics relate"
>     ::= { bwtBh2GenStatsEntry 2 }



-- 
Thanks,
Regards,
Chaitanya T K.

Re: MAC Address As Index

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

On Wed, Sep 11, 2019 at 3:04 PM Niels Baggesen
<nb...@us...> wrote:
>
> On Wed, Sep 11, 2019 at 12:40:38PM +0530, Krishna Chaitanya wrote:
> > > BTW, somehow the response from Neils is missed but found it in the archive.
> > >
> > > https://www.mail-archive.com/net...@li.../msg21705.html
> > >
> > > MacAddress TC from SNMPv2-TC is a fixed size string, so, the length
> > > should not be prefixed.
> > >
> >
> > Any ideas on how to get proper MAC address display without any side
> > effects? Any help is appreciated.
>
> The MacAddress TC mentioned above has a DISPLAY-HINT "1x:", does that
> not display the way you want? Otherwise show us what you see, and what
> is wrong with it.
>
Missed your reply again, now added filters and then found it.

Yes, the TC should work properly, but unfortunately, it doesn't, My
display is as below:
You can see that the "6" is prefixed and ".1/.2/.3" are part of MAC addresses.

This may not be a display only problem, currently, I am debugging a case where
deleting a single entry from the table makes it go haywire, it deletes
the wrong entry,
the same issue could probably be the reason (not sure though).

$ snmptable -v3 -a MD5 -l authNoPriv localhost -OX -Ci
                        index mpduTx
["wlp1s0"][6:52:54:0:c8:53].1    302
["wlp1s0"][6:52:54:0:c8:53].2    307
["wlp1s0"][6:52:54:0:c8:53].3    328


The MIB entry snippets are as below:

MacAddress, TEXTUAL-CONVENTION FROM SNMPv2-TC
...
bwtBh2GenStatsEntry OBJECT-TYPE
  SYNTAX BwtBh2GenStatsEntry
  MAX-ACCESS not-accessible
  STATUS current
  DESCRIPTION
    "A row in BH2 Gen stats table"
  INDEX { ifaceName, remoteMAC }
  ::= {bwtBh2GenStatsTable 1}
....
remoteMAC OBJECT-TYPE
       SYNTAX MacAddress
       MAX-ACCESS not-accessible
       STATUS current
       DESCRIPTION
           "Remote MAC address to which these statistics relate"
    ::= { bwtBh2GenStatsEntry 2 }

Multi-threaded net-snmp client

[Pratyush M. <pra...@gm...>]

Hi Katia,

I saw the thread of this emailMulti-threaded net-snmp client and found what
I have been looking for. I want to create a multi threaded application for
fetching a set of data from multiple devices.

I tried referring to your project at the link you provided but
unfortunately it was not available at medianetlab.gr/open source

Can you please provide me with a fresh link for the project so I can have a
look at it?

Thanks,
Pratyush

Re: MAC Address As Index

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

On Wed, Sep 11, 2019 at 12:40:38PM +0530, Krishna Chaitanya wrote:
> > BTW, somehow the response from Neils is missed but found it in the archive.
> >
> > https://www.mail-archive.com/net...@li.../msg21705.html
> >
> > MacAddress TC from SNMPv2-TC is a fixed size string, so, the length
> > should not be prefixed.
> >
> 
> Any ideas on how to get proper MAC address display without any side
> effects? Any help is appreciated.

The MacAddress TC mentioned above has a DISPLAY-HINT "1x:", does that
not display the way you want? Otherwise show us what you see, and what
is wrong with it.

/Niels

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

Re: MAC Address As Index

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

On Tue, Sep 3, 2019, 5:23 PM Krishna Chaitanya <cha...@gm...>
wrote:

> On Tue, Aug 27, 2019 at 2:12 PM Krishna Chaitanya
> <cha...@gm...> wrote:
> >
> > On Mon, Aug 26, 2019 at 9:22 PM Bill Fenner <fe...@gm...> wrote:
> > >
> > > On Tue, Aug 20, 2019 at 8:45 AM Krishna Chaitanya <
> cha...@gm...> wrote:
> > >>
> > >> Hi,
> > >>
> > >> When using MAC Address as an index ( I am using MacAddress type from
> > >> SNMPv2-TC.) the output is incorrect because the length of the string
> > >> is prefixed as mac address is defined as OCTET STR there is an extra
> > >> byte and the last byte of mac address is interpreted as next OID.
> > >>
> > >> snmpwalk:
> > >>    HistValue."wlp8s0f0".'....B.'.hist_2.2.19
> > >> snmpwalk -OX
> > >>   HistValue["wlp8s0f0"][STRING: 06:00:90:e6:42:99][hist_2][2].19
> > >>
> > >> In the above examples last but one OID 2 is hist_2. Is there a way to
> > >> disable prefixing of length?
> > >
> > >
> > > The prefixing of length is done by the agent.  Are you asking about a
> MIB module that you implemented?  Try changing your object definition from
> ASN_OCTET_STR to ASN_PRIV_IMPLIED_OCTET_STR.
> > Yes, I am using my own MIB and changing to ASN_PRIV_IMPLIED_OCTET_STR
> > in the subagent worked.
> > Thanks, Bill.
>
> After this change, I was getting a lot of duplicate data exists
> errors, upon further debugging found a similar issue
> which is quite old
>
> https://www.mail-archive.com/net...@li.../msg06286.html
> .
> In the current code even though there is support to handle IMPLIED
> strings, but subsequent indexes are not processed.
> See snippet below: out of 4 indexes only 2 are processed (the indexes
> after ASN_PRIV_IMPLIED_OCTET_STR
> failed to parse. Any ideas?
>
> histStatsData: Request Mode is: 160 name: wlp8s0f0 col: 3
> histStatsData: Add row
> duplicate table data attempted to be entered. row exists
> helper:table:req: Got GETNEXT (161) mode request for handler table:
> base oid:SNMPv2-SMI::mib-2.43932.2.2
> helper:table:col:   have at least a column (3)
> helper:table:     have 17 bytes of index
> helper:table:   looking for 4 indexes
>
> parse_oid_indexes: Parsed str(4): wlp8s0f0
> helper:table:   got 1 (incomplete=0)
>
> parse_oid_indexes: Parsed str(196):
> helper:table:   got 1 (incomplete=0)
>
> helper:table:   oid indexes not complete:
>
> SNMPv2-SMI::mib-2.43932.2.2.1.3.8.119.108.112.56.115.48.102.48.0.128.225.66.153.1.2.15
> helper:table:results:   found 2 indexes
> helper:table:results:   column: 3, indexes: 2   index: type=4(04),
> value=STRING: "wlp8s0f0"   index: type=196(c4), value=Variable has bad
> type
>
>
> BTW, somehow the response from Neils is missed but found it in the archive.
>
> https://www.mail-archive.com/net...@li.../msg21705.html
>
> MacAddress TC from SNMPv2-TC is a fixed size string, so, the length
> should not be prefixed.
>

Any ideas on how to get proper MAC address display without any side
effects? Any help is appreciated.

>

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

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

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: requirement alarm description on OID 1.3.6.1.4.1.8072.3.2.10

[Magnus F. <ma...@ly...>]

On Thu, Sep 05, 2019 at 04:14:24PM +0530, MAD GAMING wrote:
> Dear Team
> Please support to provide alarm description for below OID
> 
> 1.3.6.1.4.1.8072.3.2.10
> 
> appeared over storage p2000 base SPA..

You did not provide much information to work with but I'd guess the system
that generated the alarm runs some version of linux.

linux OBJECT-TYPE
  -- FROM       NET-SNMP-TC
::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) netSnmp(8072) netSnmpEnumerations(3) netSnmpAgentOIDs(2) 10 }

/MF

Re: Net-snmp version that supports HMAC-SHA-224 and greater

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

"Adolf Misquith (amisquit) via Net-snmp-coders"
<net...@li...> writes:

> What version of snmp supports greater HMAC-SHA-256 and greater?

5.8 :-)

> Further, a new user is added with the following step:
> 
> createUser testUser SHA "test123" AES
> 
> Is there a possibility to configure HMAC-SHA-224/256/384/512 (for the agent) as default and not confine to a given user?

Each user gets their own algorithm; it's built into how the protocol
works.  We could create defaults using new configuration commands to do
so, but at this time that's not done.
-- 
Wes Hardaker
Please mail all replies to net...@li...

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

[Jeff G. <je...@op...>]

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

missing information in logmatch trap

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

Hi

I am using net-snmp 5.7.3 on Ubuntu and have a few questions regarding
logmatch trap

- How can we get more information in a logmatch trap other than the pattern
matched?

For example  if we have below

logmatch loginFailure /var/log/auth.log 30 Failed password
monitor -r 10 -o logMatchName -o logMatchFileName -o logMatchCurrentCount
-o logMatchRegEx "Log Match" != logMatchCurrentCount

we get the below trap

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3774203) 10:29:02.03
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: 3 UCD-SNMP-MIB::logMatchName.1 =
STRING: loginFailure UCD-SNMP-MIB::logMatchFilename.1 = STRING:
/var/log/auth.log UCD-SNMP-MIB::logMatchCurrentCount.1 = INTEGER: 3
UCD-SNMP-MIB::logMatchRegEx.1 = STRING: Failed password

for the below message in auth.log

Sep  5 19:51:43  sshd[23557]: Failed password for root from xx.xx.xx.xx
port 41569 ssh2

Is it possible to get the user name in the string as part of the logmatch
trap? Like 'root' in above example.

If it is not possible via the logmatch implementation, can we execute a
script when the pattern is matched that can do additional checking and
raise a trap instead?

Thanks in advance.

requirement alarm description on OID 1.3.6.1.4.1.8072.3.2.10

[MAD G. <ada...@gm...>]

Dear Team
Please support to provide alarm description for below OID

1.3.6.1.4.1.8072.3.2.10

appeared over storage p2000 base SPA..

Regards
Adarsh Mehta
+91 9780009461

Net-SNMP 5.8.1.pre1 available for testing

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

Darn it,

I sent an announcement the other day to -coders but sent it from the
wrong address and it got stuck in moderation.

*Anyway*,

----

Folks,

I've just published 5.8.1.pre1 and is available for testing.  Get the
tar-balls from here:

https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8.1-pre-releases/

Stay tuned for an announcement about the push toward github in the next
hour as well.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: OpenSSL v1.1.1 Support

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

David Hauck <da...@ne...> writes:

> I noticed the recent 'CHANGES' file entry in the V5-8-patches branch
> references the following:

Thanks.  That came from a log message, but I assume your text is correct
so have changed the file.

-- 
Wes Hardaker
Please mail all replies to net...@li...

OpenSSL v1.1.1 Support

[David H. <da...@ne...>]

Hi,

I noticed the recent 'CHANGES' file entry in the V5-8-patches branch references the following:

     - Add support for OpenSSL 1.1.0

Should this instead read:

     - Add support for OpenSSL 1.1.1

These are two different versions of OpenSSL, with the former going EOL this month while the latter is the current LTS release.

Regards,
-David

Important announcement about Net-SNMP moving to github

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

The net-snmp admin team has been discussing moving our code repository
to github, and today we're making the first steps toward that goal.
Below documents the pieces that are now moved, followed by a list of
items that aren't yet changing.

==== What's changing

1) Net-SNMP git repository:

   The Net-SNMP source code repository can now be found inside our
   Net-SNMP organization on the github site:

       https://github.com/net-snmp/net-snmp

   The URLs for accessing the git repository are:

       gi...@gi...:net-snmp/net-snmp.git
       https://github.com/net-snmp/net-snmp.git

2) Issue/bug tracking:

   We are also moving our issue/bug tracking to github as well.  Thus,
   for reporting new issues (including anything relating to the just
   published 5.8.1.pre1 pre-release), please use the github issue tracker:

   https://github.com/net-snmp/net-snmp/issues

   The net-snmp redirection address has been switched to point this as
   well:

   https://www.net-snmp.org/bugs/

3) Patch submission:

   Similarily, patch submission should now be done using github pull
   requests instead:

   https://github.com/net-snmp/net-snmp/pulls
   https://www.net-snmp.org/patches/

=== What's NOT changing

At this time, we're leaving a number of things at sourceforge.  Some
of them may transition in the future, but many of these are
complicated to move or simply can't move at all:

- The Net-SNMP website (ie, www.net-snmp.org will still be hosted on
  sourceforge)
- The Net-SNMP wiki (www.net-snmp.org/wiki)
- The mailing lists:
    - net-snmp-announce    
    - net-snmp-users
    - net-snmp-coders
- The downloads.html file currently points to sourceforge,
  but this may change sometime soon. 

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: MAC Address As Index

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

On Tue, Aug 27, 2019 at 2:12 PM Krishna Chaitanya
<cha...@gm...> wrote:
>
> On Mon, Aug 26, 2019 at 9:22 PM Bill Fenner <fe...@gm...> wrote:
> >
> > On Tue, Aug 20, 2019 at 8:45 AM Krishna Chaitanya <cha...@gm...> wrote:
> >>
> >> Hi,
> >>
> >> When using MAC Address as an index ( I am using MacAddress type from
> >> SNMPv2-TC.) the output is incorrect because the length of the string
> >> is prefixed as mac address is defined as OCTET STR there is an extra
> >> byte and the last byte of mac address is interpreted as next OID.
> >>
> >> snmpwalk:
> >>    HistValue."wlp8s0f0".'....B.'.hist_2.2.19
> >> snmpwalk -OX
> >>   HistValue["wlp8s0f0"][STRING: 06:00:90:e6:42:99][hist_2][2].19
> >>
> >> In the above examples last but one OID 2 is hist_2. Is there a way to
> >> disable prefixing of length?
> >
> >
> > The prefixing of length is done by the agent.  Are you asking about a MIB module that you implemented?  Try changing your object definition from ASN_OCTET_STR to ASN_PRIV_IMPLIED_OCTET_STR.
> Yes, I am using my own MIB and changing to ASN_PRIV_IMPLIED_OCTET_STR
> in the subagent worked.
> Thanks, Bill.

After this change, I was getting a lot of duplicate data exists
errors, upon further debugging found a similar issue
which is quite old
https://www.mail-archive.com/net...@li.../msg06286.html.
In the current code even though there is support to handle IMPLIED
strings, but subsequent indexes are not processed.
See snippet below: out of 4 indexes only 2 are processed (the indexes
after ASN_PRIV_IMPLIED_OCTET_STR
failed to parse. Any ideas?

histStatsData: Request Mode is: 160 name: wlp8s0f0 col: 3
histStatsData: Add row
duplicate table data attempted to be entered. row exists
helper:table:req: Got GETNEXT (161) mode request for handler table:
base oid:SNMPv2-SMI::mib-2.43932.2.2
helper:table:col:   have at least a column (3)
helper:table:     have 17 bytes of index
helper:table:   looking for 4 indexes

parse_oid_indexes: Parsed str(4): wlp8s0f0
helper:table:   got 1 (incomplete=0)

parse_oid_indexes: Parsed str(196):
helper:table:   got 1 (incomplete=0)

helper:table:   oid indexes not complete:
SNMPv2-SMI::mib-2.43932.2.2.1.3.8.119.108.112.56.115.48.102.48.0.128.225.66.153.1.2.15
helper:table:results:   found 2 indexes
helper:table:results:   column: 3, indexes: 2   index: type=4(04),
value=STRING: "wlp8s0f0"   index: type=196(c4), value=Variable has bad
type


BTW, somehow the response from Neils is missed but found it in the archive.
https://www.mail-archive.com/net...@li.../msg21705.html

MacAddress TC from SNMPv2-TC is a fixed size string, so, the length
should not be prefixed.

Re: New release of net-snmp

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

Hugh McMaster <hug...@ou...> writes:

> There has been a lot of good work since the previous release of
> net-snmp 13 months ago.
> 
> Is there an estimate or release target for a new version?

Actually, it was my job to release a 5.8.1.pre1 on Friday.  I failed
that trying to get ready for a 3 day weekend in the US.  I'll get it out
tomorrow.
-- 
Wes Hardaker
Please mail all replies to net...@li...