[Karunkaran Kumar <skam4kumar@xxxxxxxxx>]

Hi Pascal,

Thank you very much for the reply. :) I am trying to learn how to write plugin dissectors from the developers guide.

I (atleast conceptually, i think) understood the first and the last point.

However, could you kindly elaborate on the second point. I am new to wireshark-dev and i just started learning about its internal workings. Thus, the pointer you had given is probably too concise. I just wanted to know what did you mean.

Regarding the third point: I tried the following and it worked well:

Manually created a pcap file like so: [file header, with DLT=147] [packet timestamps, length] [RRC bytes directly]

setup a USER_DLT in the GUI with settings: protocol: lte-rrc.bcch.dl.sch, header length: 0, header protocol: "", trailer length: 0, trailer protocol: ""

Similarly, the following also worked:
Manually created another pcap file like so: [file header, with DLT=148] [packet timestamps, length] [ethertype:ip:udp:RRC bytes]

setup a USER_DLT in the GUI with settings: protocol: lte-rrc.bcch.dl.sch, header length: 44, header protocol: ethertype, trailer length: 0, trailer protocol: ""

However, my doubt is suppose we have a packet with the following headers: ethertype:ip:udp then RRC packet on the payload of UDP, can we setup a USER_DLT at the UDP protocol (for a specific port)? Is this what you meant in your second point?

Thanks and regards,

k. kumar

On Sun, Jan 3, 2016 at 2:10 AM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:

Le 2 janv. 2016 9:22 PM, "Karunkaran Kumar" <skam4kumar@xxxxxxxxx> a écrit :
>
> Hi all,
>
> I recently learned about the LTE support on wireshark -- mac-lte, rlc-lte, pdcp-lte and rrc-lte.
> The heuristic dissection (i.e., using UDP framing) of the lower layers (i.e., mac,rlc,pdcp) fits my needs exactly.
> However, the rrc-lte apparently does not have have such an analogous UDP framing format and heuristic dissection. (Kindly correct me if I am wrong).
>
> I am actually in need of such a functionality. I however do not want to add pseudo mac/rlc headers and use the existing UDP framing. So is it a good idea to try and write a heuristic dissector for this?
>
> As far as my understanding goes, I would require one TAG field perpended to the RRC packet, which would identify the type of the RRC packet -- i.e., BCCH.BCH, BCCH.DL.SCH, DL.CCCH, PCCH, etc...
> The reason I think so, is because the 3GPP message decoder (http://3gppdecoder.free.fr/?q=node/1) given in the RRC-LTE web page (https://wiki.wireshark.org/LTE%20RRC) takes a byte stream and a combo-box with these options (BCCH.BCH, BCCH.DL.SCH, DL.CCCH, PCCH, etc...) alone for decoding the packet.
>
> Could anyone kindly advise me on this. Is this correct and whether or not it is a good idea to do this... I saw that few others have also wanted such a similar heuristic decoder for rrc, however they were suggested workarounds as mentioned above (using pseudo mac/rlc layer).
>
> Looking forward to a reply,
> with regards,
> k kumar
>
> PS: I am a HUGE fan of Wireshark. :)
>

Hi Kumar,

I'm not sure adding another UDP based heuristic dissector in the official source code base for LTE RRC would be really useful (as the only thing needed is to identify the PDU type which corresponds to a specific dissector already registered by name, contrary to MAC/RLC/PDCP dissectors that usually request more meta data).
You have several ways to handle this yourself though:
- write your own UDP based plugin or embedded dissector that would do the framing you are suggesting (it is very easy to do)
- use Wireshark Upper PDUs DLT format (see https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/exported_pdu.h;h=087c91ec8ac4a396fa89e667bf07f12b804c2547;hb=HEAD for more details). I'm using it myself for some tools and it perfectly fit your need
- assign a user DLT to each PDU type and configure Wireshark to call the corresponding dissector

Best regards,
Pascal.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe