I reported this back in 2020, but I think there was confusion caused by my
response. Snmpd definitely throws an error if a trapsink contains a TCP
transport specifier:
# cat /etc/snmp/snmpd.conf
rocommunity public
trapsink tcp:10.224.4.161 public
# snmpd -f -Le
snmpd: netsnmp_create_notificat
But with noAuthNoPriv, the encoded passphrases aren’t being sent, and the
receiver is not trying to decode them. When an authPriv trap is received, the
trap receiver uses the authoritative engine ID to decode the passphrases and
ensure they match the preconfigured USM user’s passphrases, which
directives and files may have changed for newer versions, and locations may
be different for your version/distro of net-snmp.
Hope that helps,
Brian
From: Feroz
Sent: Wednesday, January 13, 2021 2:39 AM
To: Atkins, Brian
Cc: net-snmp-users@lists.sourceforge.net
Subject: Re: snmptrapd for V3 informs
I don’t have one handy, but keep in mind that the engineID used to encode the
usmUser credentials, for both snmptrapd and the agent, is the one for snmptrapd
itself, not the agent sending the INFORM:
With SNMPv3 informs, the authoritative engine ID is the engine that receives
the inform, unlike
Ok, I was chasing a red herring. I just discovered that my snmptrapd
configured to accept TCP had been stopped, so the problem was that it couldn't
establish the session, not that it couldn't parse/handle the sink statement.
Apologies for not discovering this 10min sooner.
From: Atk
When I try to add a transport specifier to any trap sink statement, I get a
failure. The man page for snmpd.conf references LISTENING ADDRESSES in
snmpd(8), so I assume the format should be [protocol:]address[:port]. The
examples support this. What am I missing?
The following sink statements
You will need to use createUser in your snmpd.conf file with passwords and hash
settings. On Debian 10, put then in /etc/snmp/snmpd.conf. The createUser
statements will be removed and encoded passwords will be added to
/var/lib/snmp/snmpd.conf in usmUser statements.
NOTE: since you want to us
and one without the -e option).
From: John Bize
Sent: Friday, July 17, 2020 1:44 PM
To: Atkins, Brian ; Colin Anderson
; net-snmp-users@lists.sourceforge.net
Subject: Re: SNMPv3 authPriv informs (trapsess)
NetApp Security WARNING: This is an external email. Do not click links or open
attachments
Also, if you use traps, the authoritativeEngineID will be the one on the agent.
That is the default, so there will be no need to specify a -e argument on the
createUser call.
From: Atkins, Brian
Sent: Friday, July 17, 2020 1:38 PM
To: John Bize ; Colin Anderson
; net-snmp-users
The authoritativeEngineID is specified on the createUser, not trapsess. See
http://www.net-snmp.org/docs/man/snmpd.conf.html
From: John Bize
Sent: Friday, July 17, 2020 1:37 PM
To: Atkins, Brian ; Colin Anderson
; net-snmp-users@lists.sourceforge.net
Subject: Re: SNMPv3 authPriv informs
Bize
Sent: Friday, July 17, 2020 1:02 PM
To: Colin Anderson ; Atkins, Brian
; net-snmp-users@lists.sourceforge.net
Subject: Re: SNMPv3 authPriv informs (trapsess)
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the
Also, a user configured with a remote engineID in order to support V3 inform
messages, as described below, would never be able to perform other SNMP
operations (GET, GET-NEXT, SET) because the authoritative engineID would not
match the target, correct?
From: Atkins, Brian
Sent: Monday, October
I'm checking my understanding of how to configure a trapsess for V3 informs in
snmpd.conf. I want to avoid putting the authentication and encryption
passwords in the config file, so I'm relying on USM user lookup, such as:
trapsess -v3 -Ci -l authPriv -u user1
with "user1" being defined using
13 matches
Mail list logo