Wireshark-bugs: [Wireshark-bugs] [Bug 4433] Wrong decoding of LTE S1AP UEContextReleaseCommand

Date: Sun, 31 Jan 2010 23:03:17 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4433

--- Comment #8 from Anders Broman <anders.broman@xxxxxxxxxxxx> 2010-01-31 23:03:11 PST ---
Hi,
When PER encoding is used there is no bits indicating "SEQUENCE OF" etc
X.691:
18    Encoding the sequence type
NOTE – (Tutorial) A sequence type begins with a preamble which is a bit-map. If
the sequence type has no extension marker, then the bit-map merely records the
presence or absence of default and optional components in the type, encoded as
a fixed length bit-field. If the sequence type does have an extension marker,
then the bit-map is preceded by a single bit that says whether values of
extension additions are actually present in the encoding. The preamble is
encoded without any length determinant provided it is less than 64K bits long,
otherwise a length determinant is encoded to obtain fragmentation. The preamble
is followed by the fields that encode each of the components, taken in turn. If
there are extension additions, then immediately before the first one is encoded
there is the encoding (as a normally small length) of a count of the number of
extension additions in the type being encoded, followed by a bit-map equal in
length to this count which records the presence or absence of values of each
extension addition. This is followed by the encodings of the extension
additions as if each one was the value of an open type field.

So assuming that the dissection is staring on the correct bit(as the unaligned
version of PER is used thee is no octet aligning)
At offset 0x49 Value 30
Bit 8 and 7 belongs to the previous element.
Bit 6
..1. .... Extension Bit: True
This should have been false as there is no extension(this is the "..." in the
asn1).
...1 .... Optional Field Bit: True (iE-Extensions is present)
This should also have been false as the optional ie-extension field is absent.

Next should follow the lenght of the integer used for MME-UE-S1AP-ID
Constrained Integer Length: 1
Thsi should have been:
.... 11.. (3) giving the lenght value of 4

So unless the dissection is starting on the wrong bit I think the encoding is
wrong.

Possibly if this asn1 code was used it's ok

UE-S1AP-ID-pair ::= SEQUENCE{
    mME-UE-S1AP-ID        MME-UE-S1AP-ID,
    eNB-UE-S1AP-ID        ENB-UE-S1AP-ID,
}

But then it's not according to the standard...
Regards
Anders

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.