| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 954.1 | try single partition requests | TOOK::CALLANDER | | Thu Apr 25 1991 13:03 | 7 |
| could you please try the same commands specifying each partition (one per
command) instead of all attributes. This will help determine which partition
is causing the problem.
If you could post the results here it would be helpful.
thanks
|
| 954.2 | | TOOK::J_HALPIN | | Thu Apr 25 1991 16:29 | 27 |
|
This problem is being caused by differences in the way the DNA5 AM
and VMS NCL (and OSI-Router) encode an Address Prefix data type in
ASN.1
I traced the CMIP messages generated by both the DNA5 AM and
VMS NCL. Here what we got:
DNA5 AM: [APPL 43] 49 00 2A
VMS NCL: [APPL 43] 00 49 00 2A (The OSI-Router returns the
Address Prefix this way
also.)
That was the only difference between the two CMIP messages. So I
quickly built a new DNA5 AM that tacks on a null byte at the beginning,
and low and behold it now works.
The only problem is, I don't know why that null byte is being tacked
on at the beginning? It looks wrong to me, so I'm going to try and
find out which way is right.
JimH
|
| 954.3 | The answer is... | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Thu Apr 25 1991 16:46 | 13 |
| AddressPrefix is defined as an ASN.1 BITSTRING type (because AddressPrefixes
can have an odd number of bytes) -- check out NETMAN Chapter 11 and notice
the AddressPrefix is defined in terms of HexString. What you saw was an
(implicit) encoding of a BITSTRING (*not* an OCTETSTRING). Check the ASN.1
standard to understand what the 0 means.
One way to test that you have it right is that 49::12-3 should be accepted
as a valid AddressPrefix and encoded correctly (although VMS NCL doesn't
accept it, it should; ULTRIX NCL accepts it). The correct encoding is:
[APPLICATION 43 ] 04 49 12 30
Graham
|
| 954.4 | | TOOK::J_HALPIN | | Fri Apr 26 1991 12:26 | 24 |
|
Graham,
Thanks for explaining this, I understand now and I'll
filing this as a QAR. Just one more question, to make sure I really
understand this. In you previous reply you showed the address prefix
49::12-3, being encoded as
[APPL 43] 04 49 12 30
where the first byte is a count of unused bits in the last byte.
Correct?
Now according to what I'm reading in NETMAN, if that Address Prefix
had been 49::12-3: Would that get encoded as above, or as:
[APPL 43] 00 49 12 03
JimH
|
| 954.5 | Hmmm. | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Fri Apr 26 1991 14:24 | 22 |
| > Now according to what I'm reading in NETMAN, if that Address Prefix
> had been 49::12-3: Would that get encoded as above, or as:
>
> [APPL 43] 00 49 12 03
I don't have my copy of NETMAN to hand but that is certainly not right. If
in doubt, write down the bitstring that is used in the definition
explicitly. That ASN.1 would represent the bitstring 0100 1001 0001 0010
0000 0011. I.e. the padding has come *between* the 2 and the 3.
DECnet-ULTRIX turns 49::12-3: into
[APPLICATION 43 ] 00 49 01 23
(which is bitstring 0100 1001 0000 0001 0010 0011)
The answer as to whether that is right or whether [APPL 43] 04 49 12 30 is
right depends on whether the padding goes at the front or the end. In fact,
I don't even know if the address 49::12-3: is legal or whether it should be
49::1-23: (any comment Mark?).
Graham
|
| 954.6 | 49::12-3 encodes as [Application 43] 04 49 12 30 | CAPN::SYLOR | Architect = Buzzword Generator | Fri May 03 1991 13:25 | 13 |
| The encoding of 49::12-3 should be
[Application 43] 04 49 12 30
Note that in ASN.1, they number the bits in an octet most significant bit is
#1, least significant is #8.
The spec says,
put the # of bits to ignore in the first octet
put the first hex digit in bits 1-4 of the second octet,
put the second hex digit in bits 5-8 of the second octet,
put the third hex digit in bits 1-4 of the third octet,
...
Mark
|