unable to locally set up trap destination but remotely works fine

Discussion:

(too old to reply)

Peter Upczak

2016-04-27 16:54:43 UTC

day 4 on this, reading FAQ & mail archives, web blogs and posts, no results.

Configuration:
target agent NET-snmp 5.7.1 running on embedded linux NS9210 ARM processor
This is a highly constrained environment / small footprint / low resource
target.

uname -a

Linux cme9210js 2.6.35.14-g7fd7fd3-dirty #2 Thu Mar 10 16:16:41 EST 2016
armv5tejl GNU/Linux

< system stuff snipped >
226 root 5532 S /usr/sbin/snmpd -f -I -vmstat -I -cpu -Lsd -Lf
/var/ (screen truncation)
255 root 5532 S /usr/sbin/snmpd -f -I -vmstat -I -cpu -Lsd -Lf
/var/ (screen truncation)
256 root 5532 S /usr/sbin/snmpd -f -I -vmstat -I -cpu -Lsd -Lf
/var/ (screen truncation)
257 root 5532 S /usr/sbin/snmpd -f -I -vmstat -I -cpu -Lsd -Lf
/var/ (screen truncation)

snmpd is run from init.d, launched by start-stop-daemon. The default mode is
SNMPv3. V1, V2c are not used.

tail /var/log/messages

Jan 1 00:00:15 (none) daemon.info snmpd[226]: NET-SNMP version 5.7.1

From the target's shell, I want to create a trap-destination that is an

external snmptrapd server. The agent is configured to listen on both eth0
and lo interfaces.

From the target's shell, I can send a trap with snmptrap from the target to

the trap-receiver machine ok.

From the target's shell, I can do snmpget's to its lo interface and receive

the local agent's values back over SNMPv3.
I cannot accomplish the first step to setting trap configs using snmpset.

However, if I mimic the trap-destination steps on an external linux host
(Intel / Fedora23) to the target, it works fine.
Here's the host side output:

(ROOT)@localhost: # snmpset -d -Lo -M ../mibs -m ALL -v3 -l authpriv -u
SNMPv3ShaAesUser -a SHA -A password -x AES -X password 10.11.16.93
snmpTargetAddrRowStatus.\'testTarget\' i 6

Sending 64 bytes to UDP: [10.11.16.93]:161->[0.0.0.0]:0
0000: 30 3E 02 01 03 30 11 02 04 0B 11 62 5D 02 03 00 0>...0.....b]...
0016: FF E3 04 01 04 02 01 03 04 10 30 0E 04 00 02 01 ..........0.....
0032: 00 02 01 00 04 00 04 00 04 00 30 14 04 00 04 00 ..........0.....
0048: A0 0E 02 04 3D C1 4E FE 02 01 00 02 01 00 30 00 ....=.N.......0.

Received 108 byte packet from UDP: [10.11.16.93]:161->[0.0.0.0]:50117
0000: 30 6A 02 01 03 30 11 02 04 0B 11 62 5D 02 03 00 0j...0.....b]...
0016: FF E3 04 01 00 02 01 03 04 1E 30 1C 04 0D 80 00 ..........0.....
0032: 1F 88 80 7F 12 6E 7B 0E 00 00 00 02 01 08 02 02 .....n{.........
0048: 02 44 04 00 04 00 04 00 30 32 04 0D 80 00 1F 88 .D......02......
0064: 80 7F 12 6E 7B 0E 00 00 00 04 00 A8 1F 02 04 3D ...n{..........=
0080: C1 4E FE 02 01 00 02 01 00 30 11 30 0F 06 0A 2B .N.......0.0...+
0096: 06 01 06 03 0F 01 01 04 00 41 01 01 .........A..

Sending 157 bytes to UDP: [10.11.16.93]:161->[0.0.0.0]:0
0000: 30 81 9A 02 01 03 30 11 02 04 0B 11 62 5C 02 03 0.....0.....b\..
0016: 00 FF E3 04 01 07 02 01 03 04 42 30 40 04 0D 80 ***@...
0032: 00 1F 88 80 7F 12 6E 7B 0E 00 00 00 02 01 08 02 ......n{........
0048: 02 02 44 04 10 53 4E 4D 50 76 33 53 68 61 41 65 ..D..SNMPv3ShaAe
0064: 73 55 73 65 72 04 0C 30 3E 1E CE 83 AF 70 DA 4B sUser..0>....p.K
0080: 2B 3B B5 04 08 43 9F BB 0B 1E 96 CA 28 04 3E A5 +;...C......(.>.
0096: 92 BE 42 A9 3B 62 CE D9 F3 E7 16 EB 9A 47 4E 1F ..B.;b.......GN.
0112: E8 71 99 76 E2 47 C4 E5 20 E1 A6 B0 46 0C C2 47 .q.v.G.. ...F..G
0128: 41 8C 3F A2 45 68 B8 10 C7 5F 32 5A 00 71 9F 6C A.?.Eh..._2Z.q.l
0144: 87 FB 79 71 E0 63 7D F3 F0 43 D1 AE FF ..yq.c}..C...

Received 157 byte packet from UDP: [10.11.16.93]:161->[0.0.0.0]:50117
0000: 30 81 9A 02 01 03 30 11 02 04 0B 11 62 5C 02 03 0.....0.....b\..
0016: 00 FF E3 04 01 03 02 01 03 04 42 30 40 04 0D 80 ***@...
0032: 00 1F 88 80 7F 12 6E 7B 0E 00 00 00 02 01 08 02 ......n{........
0048: 02 02 44 04 10 53 4E 4D 50 76 33 53 68 61 41 65 ..D..SNMPv3ShaAe
0064: 73 55 73 65 72 04 0C 67 F6 98 CB 21 91 4F 89 D7 sUser..g...!.O..
0080: ED 5A EF 04 08 D8 7D AE 18 B8 FA 5C 26 04 3E F8 .Z....}....\&.>.
0096: 60 7C D9 F0 BD 42 1D AB DA ED 24 6F 5D 7F 9D 9A `|...B....$o]...
0112: 8F BD 5D E9 0B 58 4D B1 0E 39 4F C2 8D 5F 38 9F ..]..XM..9O.._8.
0128: FD CF D6 76 E3 A6 54 01 04 CA BA 66 8A 0F 7A B3 ...v..T....f..z.
0144: 74 B5 00 2B 29 D8 C4 BA DD 1F E9 FD ED t..+)........

SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'testTarget' = INTEGER: destroy(6)

From Fedora host, systematically configuring the table works to the degree

that I can use a mib browser in V3 to look at my target's snmpTargetAddr
table entries, and they return the applied content.

That entire initial volley consists of:
snmpset -d -Lo -M ../mibs -m ALL -v3 -l authpriv -u SNMPv3ShaAesUser -a SHA
-A password -x AES -X password 10.11.16.93
snmpTargetAddrRowStatus.\'testTarget\' i 6
snmpset -d -Lo -M ../mibs -m ALL -v3 -l authpriv -u SNMPv3ShaAesUser -a SHA
-A password -x AES -X password 10.11.16.93
snmpTargetAddrRowStatus.\'testTarget\' i 5
snmpset -d -Lo -M ../mibs -m ALL -v3 -l authpriv -u SNMPv3ShaAesUser -a SHA
-A password -x AES -X password 10.11.16.93
snmpTargetAddrTDomain.\'testTarget\' o 1.3.6.1.6.1.1
snmpset -d -Lo -M ../mibs -m ALL -v3 -l authpriv -u SNMPv3ShaAesUser -a SHA
-A password -x AES -X password 10.11.16.93
snmpTargetAddrTAddress.\'testTarget\' x 0A0A0A5F00A2
snmpset -d -Lo -M ../mibs -m ALL -v3 -l authpriv -u SNMPv3ShaAesUser -a SHA
-A password -x AES -X password 10.11.16.93
snmpTargetAddrTagList.\'testTarget\' s testTag
snmpset -d -Lo -M ../mibs -m ALL -v3 -l authpriv -u SNMPv3ShaAesUser -a SHA
-A password -x AES -X password 10.11.16.93
snmpTargetAddrParams.\'testTarget\' s testParams
snmpset -d -Lo -M ../mibs -m ALL -v3 -l authpriv -u SNMPv3ShaAesUser -a SHA
-A password -x AES -X password 10.11.16.93
snmpTargetAddrStorageType.\'testTarget\' i 3
snmpset -d -Lo -M ../mibs -m ALL -v3 -l authpriv -u SNMPv3ShaAesUser -a SHA
-A password -x AES -X password 10.11.16.93
snmpTargetAddrRowStatus.\'testTarget\' i 1

But the same exercise, when run from the target's shell doesn't work.
Here's the target side output (to any of its eth0 IP, lo, localhost,
127.0.0.1):

/usr/sbin/snmp-support/scripts # snmpset -d -Lo -M ../mibs -m ALL -v3 -l
authpriv -u SNMPv3ShaAesUser -a SHA -A password -x AES -X passphrase
10.11.16.93 snmpTargetAddrRowStatus.\'testTarget\' i 6

snmpTargetAddrRowStatus.'testTarget': Unknown Object Identifier
(snmpTargetAddrRowStatus.'testTarget')

That's all I get, no matter what I try (so far).

../mibs/ on both the target and the Fedora host are the same content:
-rwxrwx---. 1 root root 68104 Apr 27 11:41 DISMAN-EVENT-MIB.txt
-rwxrwx---. 1 root root 24694 Apr 27 11:41 NOTIFICATION-LOG-MIB.txt
-rwxrwx---. 1 root root 15490 Apr 27 11:42 SNMP-COMMUNITY-MIB.txt
-rwxr-x---. 1 root root 22342 Apr 27 11:42 SNMP-FRAMEWORK-MIB.txt
-rwxrwx---. 1 root root 20014 Apr 27 11:42 SNMP-NOTIFICATION-MIB.txt
-rwxrwx---. 1 root root 9106 Apr 27 11:42 SNMP-PROXY-MIB.txt
-rwxrwx---. 1 root root 22769 Apr 27 11:42 SNMP-TARGET-MIB.txt
-rwxrwx---. 1 root root 43927 Apr 27 11:42 SNMP-TLS-TM-MIB.txt
-rwxr-x---. 1 root root 29305 Apr 27 11:42 SNMPv2-MIB.txt
-rwxrwx---. 1 root root 8924 Apr 27 11:42 SNMPv2-SMI.txt
-rwxr-x---. 1 root root 38034 Apr 27 11:42 SNMPv2-TC.txt

I am running as root in both places as well (don't have a choice on the
target).
Any ideas? I'm all out of them.
thanks.

This document may contain technical data which is restricted for export
under the International Traffic Arms Regulations (ITAR) or the Export
Administration Regulations (EAR). By accepting this data, the consignee
agrees to honor the requirements of the Arms Export Control Act (22 U.S.C.
2778). This message contains information that may be confidential and
privileged. Unless you are the addressee (or authorized to receive mail
for the addressee), you should not use, copy or disclose to anyone this
message or any information contained in this message. If you have received
this message in error, please so advise the sender by reply e-mail and
delete this message. Thank you for your cooperation.

Peter Upczak

2016-04-29 16:36:24 UTC

Permalink

An interesting update to this. With the ARM target's agent logging some
debug, I see that it is happily digesting
snmpTargetAddrRowStatus.\'testTarget\` (for example) as OID
.1.3.6.1.6.3.12.1.2.1.9.116.101.115.116.84.97.114.103.101.116 from the
snmpset running on the Fedora host.

On the ARM target, I replaced the MIB text formatted specifier with the raw
OID and it works just fine.
So this means some combo of:
a) snmpset is unable to read (or perhaps fully buffer) the MIBs on the
target
b) the ARM build of snmpset is maybe resulting in some kind of munged up
endianness mishandling of input text
c) the ARM target is so constrained in terms of storage and/or memory that
it's simply crapping out and this is the best-effort error message it can
give me.

I've messed with a few things regard a) to no avail.
if it's b) and/or c), I'm hosed.

At least I know I ** can ** make this work in the short term.

Still, any thoughts / advise appreciated.
cheers,

-----Original Message-----
From: "Peter Upczak" <***@acumentrics.com>
To: net-snmp-***@lists.sourceforge.net
Date: Wed, 27 Apr 2016 12:54:43 -0400
Subject: unable to locally set up trap destination but remotely works fine

day 4 on this, reading FAQ & mail archives, web blogs and posts, no results.

Configuration:
target agent NET-snmp 5.7.1 running on embedded linux NS9210 ARM processor
This is a highly constrained environment / small footprint / low resource
target.

uname -a

Linux cme9210js 2.6.35.14-g7fd7fd3-dirty #2 Thu Mar 10 16:16:41 EST 2016
armv5tejl GNU/Linux

tail /var/log/messages

Jan 1 00:00:15 (none) daemon.info snmpd[226]: NET-SNMP version 5.7.1

From the target's shell, I want to create a trap-destination that is an

external snmptrapd server. The agent is configured to listen on both eth0
and lo interfaces.

From the target's shell, I can send a trap with snmptrap from the target to

the trap-receiver machine ok.

From the target's shell, I can do snmpget's to its lo interface and receive

From Fedora host, systematically configuring the table works to the degree

Peter Upczak

2016-04-29 17:26:12 UTC

Permalink

This is my final chapter on this topic.
Replacing snmpTargetAddrRowStatus.\`testTarget\`
with
.1.3.6.1.6.3.12.1.2.1.9.\'testTarget\'
also works when running on the ARM target.
Other experiments I've now run have ruled out b), leaving only c) as the
culprit (from previous post).

I will consider this matter closed now. However, in the face of
non-completion of parsing, maybe there is space for slightly improved
diagnostic output. Just a thought. I am not complaining.

thanks.

-----Original Message-----
From: "Peter Upczak" <***@acumentrics.com>
To: net-snmp-***@lists.sourceforge.net
Date: Fri, 29 Apr 2016 12:36:24 -0400
Subject: Re: unable to locally set up trap destination but remotely works
fine

An interesting update to this. With the ARM target's agent logging some
debug, I see that it is happily digesting
snmpTargetAddrRowStatus.\'testTarget\` (for example) as OID
.1.3.6.1.6.3.12.1.2.1.9.116.101.115.116.84.97.114.103.101.116 from the
snmpset running on the Fedora host.

On the ARM target, I replaced the MIB text formatted specifier with the raw
OID and it works just fine.
So this means some combo of:
a) snmpset is unable to read (or perhaps fully buffer) the MIBs on the
target
b) the ARM build of snmpset is maybe resulting in some kind of munged up
endianness mishandling of input text
c) the ARM target is so constrained in terms of storage and/or memory that
it's simply crapping out and this is the best-effort error message it can
give me.

I've messed with a few things regard a) to no avail.
if it's b) and/or c), I'm hosed.

At least I know I ** can ** make this work in the short term.

Still, any thoughts / advise appreciated.
cheers,

-----Original Message-----
From: "Peter Upczak" <***@acumentrics.com>
To: net-snmp-***@lists.sourceforge.net
Date: Wed, 27 Apr 2016 12:54:43 -0400
Subject: unable to locally set up trap destination but remotely works fine

day 4 on this, reading FAQ & mail archives, web blogs and posts, no results.

Configuration:
target agent NET-snmp 5.7.1 running on embedded linux NS9210 ARM processor
This is a highly constrained environment / small footprint / low resource
target.

uname -a

Linux cme9210js 2.6.35.14-g7fd7fd3-dirty #2 Thu Mar 10 16:16:41 EST 2016
armv5tejl GNU/Linux

tail /var/log/messages

Jan 1 00:00:15 (none) daemon.info snmpd[226]: NET-SNMP version 5.7.1

From the target's shell, I want to create a trap-destination that is an

external snmptrapd server. The agent is configured to listen on both eth0
and lo interfaces.

From the target's shell, I can send a trap with snmptrap from the target to

the trap-receiver machine ok.

From the target's shell, I can do snmpget's to its lo interface and receive

From Fedora host, systematically configuring the table works to the degree