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 14: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 14: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 14: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 15:06 | 43 |
3602.5 | What you see on the wire is correct. | YAHEY::BOSE | Tue Aug 25 1992 22: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. |