RLC-LTE support for DCCH

Question

This question is probably directed at Mr MartinM, hopefully you're reading :)

I have occasion to need to decode UL and DL DCCH messages, that arrive in a binary format with a custom indication of whether it is DL-DCCH or UL-DCCH. For example, I receive a binary message containing '20100500064f6e018060' with an indication that this is a DL-DCCH-MSG (rrcConnectionReconfiguration measConfig in this case).

For the other message types (DL/UL-CCCH, PCCH) that I receive, the rlc-lte decoder is doing its thing nicely in TM mode without any drama after packing the UDP header on it etc.

After having a look at the code, there seems to be no explicit handling of DCCH as its own type which would allow dissect_rlc_lte_tm to setup protocol_handle = find_dissector("lte_rrc.ul_dcch") (or dl_dcch).

This is easy enough to patch with a new CHANNEL_TYPE_DCCH defined and it works fine and decodes my DCCH packets after doing so.

My question is whether there was a reason this isn't currently implemented (or could not be implemented) - and if not, I am happy to submit a fix and/or send you a diff (so that I don't need to patch my colleagues Wiresharks to decode just these DCCH packets).

thanks for your work to date on the decoder,

regards, -jeff

Answer 1

0

You will not find a call to UL/DL LTE RRC dissector in RLC dissector because in between you have PDCP dissector (for the 1 byte header and 4 bytes footer).

What you are dumping is not a RLC message, but you are using the fact that CCCH messages are sent in transparent mode while DCCH messages are not. So a patch adding this would be rejected. If you absolutely want to use the RLC framing protocol, prepend a 1 byte header for the PDCP SN and 4 bytes header for the MAC and configure RLC dissector to call PDCP dissector. PDCP dissector can then be configured to call RRC dissector.

answered 22 Jan '17, 23:07

Pascal Quantin
5.5k●10●60
accept rate: 30%

hi Pascal,

Thanks for your comments, I am mostly vague on the finer details of the LTE MAC layer, so I do appreciate the clarifications. For the problem of DCCH, I think your comments have given me the missing link. Any attempt to shove this DCCH payload into the rlc-lte dissector needs to be handled via AM not TM, with a RLC channel type of SRB. I see afterlooking through the dissect_rlc_lte_am code path that this should find its way to the pdcp dissector in show_PDU_in_tree.

regards jeff

(23 Jan '17, 02:20) JeffG

Yes DCCH channels are always using RLC AM mode. Which means that you must also add a fake RLC header (which I forgot to add in my first message) but hopefully this is not complex. With all this plumbing, you will be able to use the RLC UDP framing protocol. You could also use directly the PDCP UDP framing protocol, or even better call directly the RRC dissector using whatever is convenient for you (Lua simple UDP dissector, etc...)

(23 Jan '17, 02:43) Pascal Quantin

hi Pascal, Thanks - got it working with a fake RLC and PDCP headers, together with some seq num per rnti to keep the expert happy.

A followup question for you if I may. The next issue I have hit is that the following code in the pdcp dissector is causing all DCCH packets post securityModeCommand to be presumed encrypted and thus not passed to the rrc dissector - but my payload is intercepted pre/post-encryption, hence I would like to get past the && section of this if:

        /* RRC data is all but last 4 bytes.
           Call lte-rrc dissector (according to direction and channel type) if we have valid data */
        if ((global_pdcp_dissect_signalling_plane_as_rrc) &&
            ((pdu_security == NULL) || (pdu_security->ciphering == eea0) || payload_deciphered || !pdu_security->seen_next_ul_pdu)) {
            /* Get appropriate dissector handle */
            dissector_handle_t rrc_handle = lookup_rrc_dissector_handle(p_pdcp_info);

In my case, pdu_security is non NULL and is (correctly) showing EEA2/EIA2. This seems unable to be skipped via any preference, do you have any suggestion on how to skip this (other than a new preference or Lua decoder)? The only thing I can think of is to fake out the securityMode packet and overwrite it with EEA0/EIA0.

Whilst I appreciate my situation is unique (I don't have to deal with data packets, only signalling, and nothing is encrypted), I am trying to avoid resorting to anything custom so that the result is portable where ever wireshark/tshark is installed.

thanks -jeff

(24 Jan '17, 00:03) JeffG

You are right it cannot be skipped. The best would be to avoid the RLC/PDCP encapsulation anyway.

Do you need to have a real time display of the RRC messages, or is it some offline post decoding? On my side, I'm using the Exported PDU format https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/exported_pdu.h;h=8a3beb57c8f62ce26b801a7c6b987914bfab4508;hb=HEAD with a data linktype set to 252 in the pcap/pcapng header. But it might not fit your needs.

(24 Jan '17, 02:26) Pascal Quantin

thanks for the pointer, I was not aware of exported_pdu, let me see if I can make do what I need. This is all offline post decoding for now, but it could become realtime in the future.

(24 Jan '17, 19:17) JeffG