This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

ASN1 file with (…)Ellipsis is not decoded properly everytime

0

Hi, Actually i am trying to add some private data dissectors on top of s1ap dissectors. so i wrote private.asn. This file is used alongwith s1ap-files in asn2wrs tool to generate packet-s1ap.c and packet-s1ap.h. I copied modified packet-s1ap.c and packet-s1ap.h to epan/dissectors. Everything is fine, but when it comes after one of (...)Ellipsis in asn file, sometimes it decode properly, sometimes does not(giving warning and dissection after that ie is wrong). Now the question is - we are using (...)Ellipsis so that any number of bytes can be expected from packet for (...)Ellipsis and the IE after (...)Ellipsis will be decoded properly. Please give some idea from asn1/s1ap/per development perspective.

I am using wireshark 1.12.8 as base.

asked 30 Jan '17, 04:09

Abhisek's gravatar image

Abhisek
16111216
accept rate: 0%

Not that it should affect any answers to your question, but you should note that the 1.12.x releases are no longer supported (since July 2016) and won't be getting security updates.

See the wiki LifeCycle page for more info.

(30 Jan '17, 04:14) grahamb ♦

Could some one please put some light on whether Ellipsis is used so that any number of bytes can be expected from packet for (...)Ellipsis

(30 Jan '17, 05:32) Abhisek

Could you please clarify how you use ellipsis in your PER ASN.1 description?

In 3GPP specifications it is usually used in a sequence to extend it in the future with an extension addition group (using the [[ ]] syntax), and in enums to add newer values. This was properly supported by Wireshark 1.12.x as far as I can remember.

But I do not understand the description of your issue so maybe if you post an extract of your ASN.1 file and the decoding you got, it will be easier to figure out what's happening. What warning are you getting?

(30 Jan '17, 06:26) Pascal Quantin

the snippets of ASN.1 are as below:

PCMD-Data ::= SEQUENCE { pCMD-FirstUeMeasurementDataList PCMD-UeMeasurementDataList OPTIONAL, pCMD-LastUeMeasurementDataList PCMD-UeMeasurementDataList OPTIONAL, pCMD-LastUeMeasurementDataList PCMD-UeMeasurementDataList OPTIONAL, ..., measDataNotPresent MeasDataNotPresent OPTIONAL, rrcEstablishmentCause RrcEstablishmentCause OPTIONAL,

now, the bytes between pCMD-LastUeMeasurementDataList and measDataNotPresent is different in two different packets and one packet is dissecting properly(byte diff 16) and for other packet is not dissecting properly(byte diff 14).

(30 Jan '17, 22:53) Abhisek

I confirm that such syntax should be handled properly by Wireshark. But as you did not provide information about the warning displayed, nor an example I cannot help you.

(31 Jan '17, 01:41) Pascal Quantin