The 512-byte limit per varbind applies to 7.1.3 and all releases back to
6.0.3. Before that some processes observed it, while other did not, which
left them vulnerable to the kind of attacks that CERT warned everyone about
back in the year 2000. In response to that advisory, the code was
tightened up.
Several processes were re-written for the next release so that the limit
could be raised to 1024, but that code is not yet available and I don't
know what the exact release data will be. Until then trapd will reject as
invalid any trap containing a varbind value which exceeds 512 characters in
length.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
sean.lawrence@can
tire.com
Sent by: To
nv-l-bounces@list Tivoli NetView Discussions
s.ca.ibm.com <nv-l@lists.ca.ibm.com>
cc
07/28/2006 07:57 Subject
AM Re: [NV-L] Netview truncating trap
variables at 249 chars
Please respond to
Tivoli NetView
Discussions
<nv-l@lists.ca.ib
m.com>
Hi James,
We are using 7.1.3 as well, I assume that the 512-byte limit is the
problem. The sendtrap works fine until I send it with the full
length string for .1.3.6.1.4.1.9.9.311.1.1.2.1.16
Sean Lawrence
Systems Automation
Ext 5728
James Shanks <jshanks@us.ibm.com>
Sent by: nv-l-bounces@lists.ca.ibm.com
07/27/2006 04:51 PM
Please respond to Tivoli NetView Discussions
To: Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
cc:
Subject: Re: [NV-L] Netview truncating trap variables at 249
chars
I had some time while awaiting a build to run, so I took a closer look at
your snmptrap. I found a number of issues with it, assuming that it was a
cut-and paste of what you actually tried to send.
/usr/OV/bin/snmptrap -d dev109.cs.ctc .1.3.6.1.4.1.9.9.311 42.116.24.30 6
2 '' .1.3.6.1.4.1.9.9.311.1.1.2.1.2 octetstring "1.0"
(1) there is a period or dot missing after the 311 and before the 42
(2) I'm not sure whether dev109.cs.ctc is the source or the destination,
but you must specify both.
(3) timeticks will default, but the syntax is back-to-back double quotes
not single ones
I find it easier to put this kind of thing in a script and get it working
piecemeal, staring with the basic command and then expanding one varbind
at
a time, so that's what I did.
I modified yours to work in my environment, The destination was the AIX
box I ran this one, hence the command hostname enclosed in back-ticks. The
source I spoofed as a box called jshanks2. If you use a hostname it has
to
resolve to a real address in your network; other wise you can use a dummy
IP address.
#!/bin/ksh
set -x
/usr/OV/bin/snmptrap -d \
`hostname` .1.3.6.1.4.1.9.9.311.42.116.24.30 \
jshanks2.raleigh.ibm.com 6 2 "" \
.1.3.6.1.4.1.9.9.311.1.1.2.1.2 octetstring "1.0" \
.1.3.6.1.4.1.9.9.311.1.1.2.1.3 timeticks 1153834707 \
.1.3.6.1.4.1.9.9.311.1.1.2.1.4 timeticks 1153834707 \
.1.3.6.1.4.1.9.9.311.1.1.2.1.5 octetstring "000016A" \
.1.3.6.1.4.1.9.9.311.1.1.2.1.6 integer 2 \
.1.3.6.1.4.1.9.9.311.1.1.2.1.7 octetstring "2 - Active" \
.1.3.6.1.4.1.9.9.311.1.1.2.1.8 integer 2 \
.1.3.6.1.4.1.9.9.311.1.1.2.1.9 integer 0 \
.1.3.6.1.4.1.9.9.311.1.1.2.1.10 octetstring "unknown" \
.1.3.6.1.4.1.9.9.311.1.1.2.1.11 integer 1 \
.1.3.6.1.4.1.9.9.311.1.1.2.1.12 octetstring "42.116.24.30" \
.1.3.6.1.4.1.9.9.311.1.1.2.1.13 octetstring "Routers" \
.1.3.6.1.4.1.9.9.311.1.1.2.1.14 integer 6 \
.1.3.6.1.4.1.9.9.311.1.1.2.1.15 octetstring "s0986-cr-r1751-1.ns.ctc" \
.1.3.6.1.4.1.9.9.311.1.1.2.1.16 octetstring
"Unresponsive::Component=s0986-cr-s2950-1.ns.ctc;Type=SWITCH;Description=Cisco
\
Internetwork Operating System Software \X0D\X0AIOS (tm) C2950 Software \
(C2950-I6Q4L2-M), Version 12.1(19)EA1c, RELEASE SOFTWARE \
(fc2)\X0D\X0ACopyright (c) 1986-2004 by cisco Systems, \
Inc.\X0D\X0ACompiled Mon 02-Feb-04 23:29 by \
yenanh;Vendor=CISCO;SystemObjectID=.1.3.6.1.4.1.9.1.325;ReadCommunity=born2
\
run;DiscoveredFirstAt=27-Jun-2006 \
8:49:33 \
AM;DisplayClassName=Switch;IsManaged=true;SNMPAddress=42.248.30.202;Discove
\
redLastAt=13-Jul-2006 \
2:00:08 AM;"
That's as far as I went. I issued that and got an invalid trap message in
trapd.log, because the last varbind is 532 characters long and trapd has a
512-byte limit in this version
The next version will see that limit raised to 1024, but there is nothing
to be done about it in 7.1.4.
Hope this helps
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
James
Shanks/Raleigh/IB
M@IBMUS To
Sent by: Tivoli NetView Discussions
nv-l-bounces@list <nv-l@lists.ca.ibm.com>
s.ca.ibm.com cc
Subject
07/27/2006 12:11 Re: [NV-L] Netview truncating trap
PM variables at 249 chars
Please respond to
Tivoli NetView
Discussions
<nv-l@lists.ca.ib
m.com>
Send an event command. Just "event" will do, and look again.
If dev109.cs.ctc is your NetView box, and you send the snmptrap, and then
immediately go look for it in trapd.log, then you may not see it because
trapd.log uses buffered I/O. It writes out the last record only on
receipt
of the new one.
But it should show in the trapd trace if you turned on the hex packet
capture as I instructed
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
sean.lawrence@can
tire.com
Sent by: To
nv-l-bounces@list Tivoli NetView Discussions
s.ca.ibm.com <nv-l@lists.ca.ibm.com>
cc
07/27/2006 10:56 Subject
AM Re: [NV-L] Netview truncating trap
variables at 249 chars
Please respond to
Tivoli NetView
Discussions
<nv-l@lists.ca.ib
m.com>
This is what cisco should be sending.
.1.3.6.1.4.1.9.9.311 42.116.24.30 6 2 '' .1.3.6.1.4.1.9.9.311.1.1.2.1.16
octetstring
"Unresponsive::Component=s0986-cr-s2950-1.ns.ctc;Type=SWITCH;Description=Cisco
Internetwork Operating System Software \X0D\X0AIOS (tm) C2950 Software
(C2950-I6Q4L2-M), Version 12.1(19)EA1c, RELEASE SOFTWARE
(fc2)\X0D\X0ACopyright (c) 1986-2004 by cisco Systems,
Inc.\X0D\X0ACompiled Mon 02-Feb-04 23:29 by
yenanh;Vendor=CISCO;SystemObjectID=.1.3.6.1.4.1.9.1.325;ReadCommunity=born2run;DiscoveredFirstAt=27-Jun-2006
8:49:33
AM;DisplayClassName=Switch;IsManaged=true;SNMPAddress=42.248.30.202;DiscoveredLastAt=13-Jul-2006
2:00:08 AM;"
This is an example of what Netview is receiving.
.1.3.6.1.4.1.9.9.311.1.1.2.1.16 octetstring
"Unresponsive::Component=42.248.30.201
[s0986-cr-r1751-1.ns.ctc];IPStatus=TIMEDOUT;InterfaceName=IF-s0986-cr-r1751-1.ns.ctc/14
[Fa0/0.100] [42.248.30.201] [management
vlan];InterfaceType=L2VLAN;InterfaceOperStatus=UP;NetworkNumber=42.248.30.200;Interf"
When I run the following sendtrap having only changed
.1.3.6.1.4.1.9.9.311.1.1.2.1.16 field to the full length string, I get no
indication in Netview that the trap was sent. Nothing in the logs, nothing
in the console. This sendtrap command works fine with the shorter string.
/usr/OV/bin/snmptrap -d dev109.cs.ctc .1.3.6.1.4.1.9.9.311 42.116.24.30 6
2 '' .1.3.6.1.4.1.9.9.311.1.1.2.1.2 octetstring "1.0"
.1.3.6.1.4.1.9.9.311.1.1.2.1.3 timeticks "1153834707"
.1.3.6.1.4.1.9.9.311.1.1.2.1.4 timeticks "1153834707"
.1.3.6.1.4.1.9.9.311.1.1.2.1.5 octetstring "000016A"
.1.3.6.1.4.1.9.9.311.1.1.2.1.6 integer 2 .1.3.6.1.4.1.9.9.311.1.1.2.1.7
octetstring "2 - Active" .1.3.6.1.4.1.9.9.311.1.1.2.1.8 integer 2
.1.3.6.1.4.1.9.9.311.1.1.2.1.9 integer 0 .1.3.6.1.4.1.9.9.311.1.1.2.1.10
octetstring "unknown" .1.3.6.1.4.1.9.9.311.1.1.2.1.11 integer 1
.1.3.6.1.4.1.9.9.311.1.1.2.1.12 octetstring "42.116.24.30"
.1.3.6.1.4.1.9.9.311.1.1.2.1.13 octetstring "Routers"
.1.3.6.1.4.1.9.9.311.1.1.2.1.14 integer 6 .1.3.6.1.4.1.9.9.311.1.1.2.1.15
octetstring "s0986-cr-r1751-1.ns.ctc" .1.3.6.1.4.1.9.9.311.1.1.2.1.16
octetstring
"Unresponsive::Component=s0986-cr-s2950-1.ns.ctc;Type=SWITCH;Description=Cisco
Internetwork Operating System Software \X0D\X0AIOS (tm) C2950 Software
(C2950-I6Q4L2-M), Version 12.1(19)EA1c, RELEASE SOFTWARE
(fc2)\X0D\X0ACopyright (c) 1986-2004 by cisco Systems,
Inc.\X0D\X0ACompiled Mon 02-Feb-04 23:29 by
yenanh;Vendor=CISCO;SystemObjectID=.1.3.6.1.4.1.9.1.325;ReadCommunity=born2run;DiscoveredFirstAt=27-Jun-2006
8:49:33
AM;DisplayClassName=Switch;IsManaged=true;SNMPAddress=42.248.30.202;DiscoveredLastAt=13-Jul-2006
2:00:08 AM;" .1.3.6.1.4.1.9.9.311.1.1.2.1.17 integer 3
.1.3.6.1.4.1.9.9.311.1.1.2.1.18 octetstring "3 - Critical"
.1.3.6.1.4.1.9.9.311.1.1.2.1.19 integer 0 .1.3.6.1.4.1.9.9.311.1.1.2.1.20
octetstring "1022" .1.3.6.1.4.1.9.9.311.1.1.2.1.21 octetstring "um1"
.1.3.6.1.4.1.9.9.311.1.1.2.1.22 octetstring "um2"
.1.3.6.1.4.1.9.9.311.1.1.2.1.23 octetstring "um3"
.1.3.6.1.4.1.9.9.311.1.1.2.1.24 integer 3 .1.3.6.1.4.1.9.9.311.1.1.2.1.25
integer 0 .1.3.6.1.4.1.9.9.311.1.1.2.1.26 octetstring "&"
.1.3.6.1.4.1.9.9.311.1.1.2.1.27 octetstring "Adrian Nims"
.1.3.6.1.4.1.9.9.311.1.1.2.1.28 octetstring "UnresponsiveOnly"
.1.3.6.1.4.1.9.9.311.1.1.2.1.29 octetstring "00000SB"
Sean Lawrence
Systems Automation
Ext 5728
James Shanks <jshanks@us.ibm.com>
Sent by: nv-l-bounces@lists.ca.ibm.com
07/27/2006 08:50 AM
Please respond to Tivoli NetView Discussions
To: Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
cc:
Subject: Re: [NV-L] Netview truncating trap variables at
249
chars
Depends on where this occurs. NetView for UNIX or Windows?
Truncating it where? In the Event display? In trapd.log? In TEC?
249 is an odd number. The maximum length of a varbind that trapd will
support in this version is 512 characters, and I have tested this many
times. But it makes a difference where and how the results are displayed.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
sean.lawrence@can
tire.com
Sent by: To
nv-l-bounces@list Tivoli NetView Discussions
s.ca.ibm.com <nv-l@lists.ca.ibm.com>
cc
07/27/2006 08:05 Subject
AM [NV-L] Netview truncating trap
variables at 249 chars
Please respond to
Tivoli NetView
Discussions
<nv-l@lists.ca.ib
m.com>
I am implementing the CISCO-EPM-NOTIFICATION-MIB and field
cenAlarmDescription (1.3.6.1.4.1.9.9.311.1.1.2.1.16249) contains for than
249 characters. Netview is truncating this field. Is there a setting I can
change to prevent this?
Sean Lawrence
Systems Automation
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|