| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
This note is a bit heavy with numbers but if you know something about
SNMP please read on.
Below are two SNMP packets read off the ethernet when trying to set
ipNetToMediaIfIndex and
ipNetToMediaPhysAddress
The SET request is from DECmcc 1.2 and the GET_Response is from a DS700
running BL42.1 .
I have broken down the ASN.1 as best I can and this leaves me with some
problems as follows:-
1.The SET_Request specifies Ojects:-
1.3.6.1.2.1.4.22.1.1.9.16.129.54.129.0.129.126 and
1.3.6.1.2.1.4.22.1.2.9.16.129.54.129.0.129.126
each are 17 (11hex) bytes long (the 1.3 being encoded as 2B)
As I read MIB II ipNetTomediaIfIndex is 1.3.6.1.2.1.4.22.1.1.i.n
and ipNetToMediaPhysAddress is 1.3.6.1.2.1.4.22.1.2.i.n
Where i = iterface number (in this case 9)
and n = relevent IP address (in this case 16.182.128.254)
My questions are why is IP address 16.129.54.129 specified ?
What is the 0.129.126 after the IP address ?
2.The object ipNetToMediaPhyAddress should be of syntax "Physaddress"
which should be a 6 byte octet string NOT an n byte character string.
DECmcc does not parse or convert the string input. In fact if you specify a
physaddress of "I love Mom" it will send it right out on the wire.
Cleverly if you specify the address "bbbbbb" it will send out the octet
string 62 62 62 62 62 62 which is a valid address but not quite what you
would expect !
Has anyone else tested this?
Ethernet packet received at 21-AUG-1992 10:36:30.04 ( 0usec.)
Destination address Source address Protocol type
08-00-2B-26-AA-A0 AA-00-04-00-15-A6 08-00
RBS701 SCOTMN TCP
Protocol = ARPA_INTERNET, Message type = IP_DATAGRAM
IP_HEADER :
VERSION : 4
IHL : 5
SERVICE_TYPE : 0
TOTAL_LENGTH : 121
IDENTIFICATION : 56049
FRAGMENT_FLAGS : 00 = "Last Fragment", "May Fragment"
FRAGMENT_OFFSET : 0
TIME_TO_LIVE : 30
PROTOCOL : 17
HEADER_CHECKSUM : 789E
SOURCE_ADDR : 16 182 128 254
DEST_ADDR : 16 182 128 160
NEXT_PROTOCOL :
Protocol = UDP, Message type = UDP_MESSAGE
UDP_DATAGRAM :
SOURCE_PORT : 1315
DEST_PORT : 161
LENGTH : 101
CHECKSUM : 5872
NEXT_PROTOCOL :
SELECT_OTHER :
30 82 00 59 02 01 00 04 06 70 75 62 6C 69
SEQ LS=2 -len=59- INTG len=1 Ver=0 STRG len=6 p u b l i
63 A3 82 00 4A 02 01 02 02 01 00 02 01 00
c STRQ LS=2 -len=4A- INTG len=1 RQID=2 INTG len=1 Err=0 INTG len=1 ERX=0
30 3F 30 82 00 16 06 11 2B 06 01 02 01 04
SEQ len=3F SEQ LS=2 -len=16- OBJ len=11 1.3 .6 .1 .2 .1 .4
16 01 01 09 10 81 36 81 00 81 7E 02 01 09
.22 .1 .1 .9 .16 .129 .54 .129 .0 .129 .126 INTG len=1 val=9
30 82 00 21 06 11 2B 06 01 02 01 04 16 01
SEQ LS=2 -len=21- OBJ len=11 1.3 .6 .1 .2 .1 .4 .22 .1
02 09 10 81 36 81 00 81 7E 04 0C 61 61 30
.2 .9 .16 .129 .54 .129 .0 .129 .126 STRG len=C a a 0
30 31 31 31 31 31 31 31 31
0 1 1 1 1 1 1 1 1
Ethernet packet received at 21-AUG-1992 10:36:30.05 ( 0usec.)
Destination address Source address Protocol type
AA-00-04-00-15-A6 08-00-2B-26-AA-A0 08-00
SCOTMN RBS701 TCP
Protocol = ARPA_INTERNET, Message type = IP_DATAGRAM
IP_HEADER :
VERSION : 4
IHL : 5
SERVICE_TYPE : 0
TOTAL_LENGTH : 121
IDENTIFICATION : 72
FRAGMENT_FLAGS : 00 = "Last Fragment", "May Fragment"
FRAGMENT_OFFSET : 0
TIME_TO_LIVE : 30
PROTOCOL : 17
HEADER_CHECKSUM : 2279
SOURCE_ADDR : 16 182 128 160
DEST_ADDR : 16 182 128 254
NEXT_PROTOCOL :
Protocol = UDP, Message type = UDP_MESSAGE
UDP_DATAGRAM :
SOURCE_PORT : 161
DEST_PORT : 1315
LENGTH : 101
CHECKSUM : 576F
NEXT_PROTOCOL :
SELECT_OTHER :
30 82 00 59 02 01 00 04 06 70 75 62 6C 69
SEQ LS=2 -len=59- INTG len=1 Ver=0 STRG len=6 p u b l i
63 A2 82 00 4A 02 01 02 02 01 03 02 01 02
c GTRP LS=2 -len=4A- INTG len=1 RQID=2 INTG len=1 Err=3 INTG len=1 ERX=2
30 3F 30 82 00 16 06 11 2B 06 01 02 01 04
SEQ len=3F SEQ LS=2 -len=16- OBJ len=11 1.3 .6 .1 .2 .1 .4
16 01 01 09 10 81 36 81 00 81 7E 02 01 09
.22 .1 .1 .9 .16 .129 .54 .129 .0 .129 .126 INTG len=1 val=9
30 82 00 21 06 11 2B 06 01 02 01 04 16 01
SEQ LS=2 -len=21- OBJ len=11 1.3 .6 .1 .2 .1 .4 .22 .1
02 09 10 81 36 81 00 81 7E 04 0C 61 61 30
.2 .9 .16 .129 .54 .129 .0 .129 .126 STRG len=C a a 0
30 31 31 31 31 31 31 31 31
0 1 1 1 1 1 1 1 1
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3602.1 | YAHEY::BOSE | Mon Aug 24 1992 11:06 | 31 | ||
RE 1) If the SNMP AM is indeed sending out a request for the object 1.3.6.1.2.1.4.22.1.1.9.16.129.54.129.0.129.126 for interface 9 and address 16.182.128.254 then there is something wrong somewhere. The correct object id it should be sending in the PDU should be 1.3.6.1.2.1.4.22.1.1.9.16.182.128.254, as you must have already figured out. I tried out the following command from DECmcc and from the packet dump everything looked ok. MCC> show snmp myunix ip nettomediatable (1,16.126.16.56) all char You can dump out the packets on the screen by setting the logical MCC_TCPIP_AM_LOG to 60 and mail the log to me so that I may take a look. RE 2) You have stumbled across a bug in the SNMP AM. The datatype for ipNetToMediaPhysAddress was erroneously defined as a Latin1String instead of an Octet String which causes the sort of behaviour you are seeing. In the next two replies I will post patch files for VMS and Ultrix which will change the definitions in the dictionary and correct this problem. Make sure no other MCC processes are running while updating the dictionary so that write operations can be carried out. Rahul. | |||||
| 3602.2 | VMS dictionary patch file. | YAHEY::BOSE | Mon Aug 24 1992 11:07 | 22 | |
$ manage/tool/dict
USE CLASS SNMP -
SUBCLASS INTERFACE -
ATTRIBUTE ifPhysAddress
! value_data_type
SET DEFINITION CODE 1 TYPE LU COUNT 1 LENGTH 4 -
VALUE 2
USE CLASS SNMP -
SUBCLASS ATTABLE -
ATTRIBUTE atPhysAddress
! value_data_type
SET DEFINITION CODE 1 TYPE LU COUNT 1 LENGTH 4 -
VALUE 2
USE CLASS SNMP -
SUBCLASS IP -
SUBCLASS NETTOMEDIATABLE -
ATTRIBUTE ipNetToMediaPhysAddress
! value_data_type
SET DEFINITION CODE 1 TYPE LU COUNT 1 LENGTH 4 -
VALUE 2
EXIT
$ exit
| |||||
| 3602.3 | Ultrix dictionary patch script | YAHEY::BOSE | Mon Aug 24 1992 11:07 | 24 | |
#!/bin/csh -f
mcc_dap << \%
USE CLASS SNMP -
SUBCLASS INTERFACE -
ATTRIBUTE ifPhysAddress
! value_data_type
SET DEFINITION CODE 1 TYPE LU COUNT 1 LENGTH 4 -
VALUE 2
USE CLASS SNMP -
SUBCLASS ATTABLE -
ATTRIBUTE atPhysAddress
! value_data_type
SET DEFINITION CODE 1 TYPE LU COUNT 1 LENGTH 4 -
VALUE 2
USE CLASS SNMP -
SUBCLASS IP -
SUBCLASS NETTOMEDIATABLE -
ATTRIBUTE ipNetToMediaPhysAddress
! value_data_type
SET DEFINITION CODE 1 TYPE LU COUNT 1 LENGTH 4 -
VALUE 2
EXIT
\%
exit 0
| |||||
| 3602.4 | More traces | COMICS::BUTT | Venturing between the viaducts. | Tue Aug 25 1992 12:06 | 43 |
Rahul
Here's the trace requested. It all looks OK but below is what actually goes
onto the wire !!! You will see that the 16.129.54.129.0.129.126 is on the
ethernet with an object lenght of 17 bytes. Strange but true.
<< Sent SNMP message: >>
[ 16 ] (
[ 2 ] 00000000
[ 4 ] 70 75 62 6c 69 63 -- public
[ 3 ] (
[ 2 ] 00000002
[ 2 ] 00000000
[ 2 ] 00000000
[ 16 ] (
[ 16 ] (
[ 6 ] 01 00 00 00 03 00 00 00 06 00 00 00 01 00
00 00 02 00 00 00
01 00 00 00 04 00 00 00 16 00 00 00 01 00 00 00 01 00 00 00
09 00 00 00 10 00 00 00 b6 00 00 00 80 00 00 00 fe 00 00 00
[ 2 ] 00000009
)
)
)
)
**************************************************
Packet read off the wire.
EThernet tcp/UDP headers removed.
30 82 00 34 02 01 00 04 06 70 75 62 6C 69 0..4.....publi
63 A3 82 00 25 02 01 02 02 01 00 02 01 00 c�..%.........
30 1A 30 82 00 16 06 11 2B 06 01 02 01 04 0.0.....+.....
16 01 01 09 10 81 36 81 00 81 7E 02 01 09 ......6...~...
| |||||
| 3602.5 | What you see on the wire is correct. | YAHEY::BOSE | Tue Aug 25 1992 19:01 | 56 | |
**************************************************
Packet read off the wire.
EThernet tcp/UDP headers removed.
.........................................
..................06 11 2B 06 01 02 01 04
16 01 01 09 10 81 36 81 00 81 7E ........
The above is what you are seeing on the wire. Now, lets take
the object id you expect to see and encode it in ASN.1
Expected oid : 1.3.6.1.2.1.4.22.1.2.9.16.182.128.254
Using the BER, the first two elements in the sequence form a
sub-identifier with the value X*40 + Y where X is the value of
the first element, and Y is the value of the second element.
Thus 1.3 is encoded as 43 (2B hex).
Subsequent elements are encoded with the most significant bit
of each octet set to one if another octet follows. Thus, the
sub-identifier is represented by concatenating one or more
7-bit values together, and treating the resulting bit-string
as an unsigned number. All the elements except the last three
can be represented using 7 bits and use up only one octet.
The elements 182.128.254 however need two octets each and are
encoded as follows :
element bin. val. hex. val.
------ --------- ---------
_________________ indicates if another octet follows.
| |
182 10000001 00110110 81 36
||||||| |||||||
| |
v v
0000001 0110110 => 182
Similarly,
128 10000001 00000000 81 00
254 10000001 01111110 81 7E
Now, the tag value for object identifiers is 6, and the total
number of octets to represent this oid is 17 (11 hex).
So the ASN.1 encoding for 1.3.6.1.2.1.4.22.1.2.9.16.182.128.254
should be
06 11 2B 06 01 02 01 04 16 01 01 09 10 81 36 81 00 81 7E
which is exactly what you see on the wire.
Rahul.
| |||||