This is our old Q&A Site. Please post any new questions and answers at

In an ISDN trace the hex value is different in the summary and within the hex dump The control field shows 0xEA01, the hex value in the storage dump showa 01ea


Wolfgang Schulte woschul at

asked 24 Sep '16, 02:30

schulte's gravatar image

accept rate: 0%

I'm afraid the only person who can really answer the question is the author of the dissector.

None of the subfields of the control field is split between the octets, so there is no objective reason why one of the octets should be deemed "LSB" and the other one "MSB". Nor anything in Q.921 implies a particular LSB/MSB role of the octets within the field.

So my speculation is that because in some cases the control field has two octets and in other cases only one, it seemed logical to treat the 4th octet of the frame, which is, depending on the case, either the first one of the two or the only one to be transmitted, as a LSB when displaying the control field as a whole. Because normally you suppress the leading zeroes when printing an integer, not the trailing ones. But doing so causes the endianness of the control field in the dissector to be reverted as compared to the address field.

Does it cause you any practical issue? You can always file a bug at Wireshark bugzilla, and the presence or absence of a practical issue would determine its severity.

(24 Sep '16, 04:05) sindy
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 24 Sep '16, 02:30

question was seen: 650 times

last updated: 24 Sep '16, 04:05

p​o​w​e​r​e​d by O​S​Q​A