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

Hello all,

In my work, I have to check from time to time RoHC related data transfer. It would be very useful to see such decoded data directly in Wireshark (I have pcap file), where I have LTE traffic. I tried to do this for a long time (maybe almost 2 years), but without any results. I think, that I always configured all correctly, but the result was the same - no decoded RoHC data and in "Configuration" field (PDCP-LTE part) always stay the same: "[ROHC Compression: False]". I have this protocol stack:

  • Ethernet II
  • IPv4
  • UDP
  • (here should be RoHC part, but I see only "data" - undecoded part)

In PDCP-LTE protocol preferences, I have checked option "Attempt to decode ROHC data". It seems, that everything is configured OK (apart from ROHC, all other fields in other headers - MAC, RLC, PDCP - are decoded correctly). In some pages, I've read, that the only way to decode RoHC is to have protocol stack with DCT2000 catapult layer, but I can't believe, that it is the only way.

I will be very grateful, if somebody would like to help me. I used different version of Wireshark, now I use the newest one: 2.0.1.

EDIT: Because it seems, that without sample file nobody can help, I attached this sample file:

Some properites of traffic here:

  1. RoHC should be detected on DRB7 and uncompressed profile should be used (so it seems to be easy to decode)
  2. MAC-LTE settings: I had to uncheck "Attempt to dissect LCID 1&2 as srb 1&2"and use mapping from static table (LCID to DRB: 3:5:AM; 4:6:UM,SN=5; 5:7:UM,SN=5)
  3. RLC-LTE settings: default values
  4. PDCP-LTE settings: no ciphering for DRB7, I didn't set values for other DRBs

asked 25 Feb '16, 04:33

zaklopotany's gravatar image

accept rate: 0%

edited 01 Mar '16, 00:40

Any ciphering in play? Without looking at the capture file details its hard to tell. Please share a sample capture file.

(25 Feb '16, 08:02) Jaap ♦

Hi Jaap,

Thanks for your comment, I forgot to clarify this. During this time, I checked both cases: without ciphering and with ciphering enabled (in this case, I always entered appropriate encryption keys). The result was always the same - no RoHC data decoded.

Regarding sample file - unfortunately, I'm affraid, that I'm not allowed to attach such file...

(29 Feb '16, 00:29) zaklopotany

IF you can share the capture, then save it in a publicly accessible spot, e.g. Google Drive, Dropbox etc. and then edit your question with a link to the file.

If you can't share the capture, then it's very difficult to help any more on this Q&A site.

Another option might be to raise a bug on the Wireshark Bugzilla where attached captures can be marked as private, so that only Wireshark Core Developers have access to it.

(29 Feb '16, 01:09) grahamb ♦

I'm probably not the best qualified one to advise as I wasn't able to make Wireshark 2.0.2 read even the UDP encapsulation of MAC-LTE itself in your sample file even though I've checked UDP's preference try heuristic dissectors first, but if by

I've read that the only way to decode RoHC is to have protocol stack with DCT2000 catapult layer, but I can't believe that it is the only way.

you refer to @Pascal Quantin's comments to this older answer, I'd rather look at the "Note that ROHC support is only partial" remark there.

Also if your need is only occasional, and as you forge the eth/ip/udp headers to your mac-lte frames anyway, you may prefer to extract the ROHC part alone and provide it with a forged ethernet header with ethertype 0x22f1, as described in this and the immediately following comment to bug 8856. Also note Pascal's remark that an IR packet has to be present in the capture so that the ROHC dissection could work properly.

(01 Mar '16, 07:34) sindy

Hi Sindy,

I have to write, that in Wireshark 2.0.1 I also met this kind of problem once (I mean decoding MAC-LTE). Suddenly, the data below UDP wasn't recognized as MAC-LTE. I don't know why, but one setting has changed without my action. To solve this issue, I had to go to “Analyze”->”Enabled Protocols…” and there set once again checkbox "mac_lte_udp" in "MAC-LTE". Maybe you have the same problem...

And thank you for your suggestion regarding encapsulation in ethernet frame. If there is no idea to decode this easier, I will surely check this solution.

(01 Mar '16, 07:51) zaklopotany

Alternatively, you could generate the dct2000 encapsulation header already for the MAC-LTE layer. The advantage of encapsulation of MAC-LTE into eth/ip/udp header is that you can mix it with other encapsulation types in a common pcap(ng) file, but if this is not your need, providing the MAC-LTE frames with the dpt2000 header instead of the eth/ip/udp one could save you the burden of extracting the ROHC data into a separate file and cooking the eth headers for them.

But as indicated, I suspect that you'd get the same results regardless what encapsulation you use for the MAC-LTE, as the eth/ip/udp pseudo-header should convey the same per-frame info like the dct2000 one.

(01 Mar '16, 08:37) sindy
showing 5 of 6 show 1 more comments

As explained in the previous threads, for now you cannot decode RoHC packets without having some meta data indicating whether the payload is actually compressed, whether you used large CID or not, the profiles used, ... This is something that is either provided by the DCT2000 capture equipment, or that can be manually provided on a per packet basis when using the PDCP UDP framing protocol (so it will NOT work when capturing at MAC level.

One could eventually add the extraction of some RoHC parameters from RRC Connection Reconfiguration messages configuring the DRB, but it would require some non negligible work and your capture does not even seem to contain the RRC messages exchanged on SRB1.

TO say it simply: no you cannot decode RoHC traffic as-is with Wireshark for now.

permanent link

answered 02 Mar '16, 07:07

Pascal%20Quantin's gravatar image

Pascal Quantin
accept rate: 30%

Do I read you right that

  • in dct2000 encapsulation, a single frame may contain all the LTE layers starting from MAC through PDCP to RoHC, and still the RoHC dissector can do its job because this encapsulation provides space for the metadata necessary to properly interpret the PDCP payload,

  • the UDP "encapsulation" or "pseudo-header" of MAC-LTE layer provides no space for the metadata necessary for the RoHC dissection, so even if @zaklopotany would have these metadata, there would be no possibility to attach them to the frame, so if an UDP "encapsulation" needs to be used, it must be the PDCP - UDP one which provides space for the metadata but not for the LTE layers below PDCP?

(02 Mar '16, 13:14) sindy

Catapult DCT2000 can capture data at different layers and from what I can see in the code support PDCP LTE meta data when the PDCP PDUs are captured, not really MAC LTE ones. The same thing applies to the UDP framing info format. The best way to handle this would be to extract the info from RRC messages and have RRC dissector configure the PDCP one. This is a significant work though.

(03 Mar '16, 00:45) Pascal Quantin

Hi Pascal,

Your answer seems to be clear. Together with other comments, I have now full view on this issue. Thank all of you for your help.

(04 Mar '16, 01:24) zaklopotany
Your answer
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: 25 Feb '16, 04:33

question was seen: 1,789 times

last updated: 04 Mar '16, 01:24

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