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:
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: https://drive.google.com/open?id=0B23kiO_viwuLUHlwRmpyR3JEcmM Some properites of traffic here:
asked 25 Feb '16, 04:33  zaklopotany edited 01 Mar '16, 00:40 showing 5 of 6 show 1 more comments |
One Answer:
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. answered 02 Mar '16, 07:07  Pascal Quantin Do I read you right that
(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 |
Any ciphering in play? Without looking at the capture file details its hard to tell. Please share a sample capture file.
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...
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.
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 byyou 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.
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.
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.