[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

Hi,

2016-01-04 0:18 GMT+01:00 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?

No, using a user specific DLT the way I suggested or the Wireshark Upper PDU DLT means that you will not have a IP/UDP encapsulation. If this is required for your environment, you should go with a simple dissector (plugin or not) + a 1 byte header indicating the PDU type.

My second alternative consists in building a PDU following the TLV encoding specified in the header file I indicated. For your use case, it would be the following array followed by the PDU dump:
{0x00, 0x0c, 0x00, 0x14, 'l', 't', 'e', '_', 'r', 'r', 'c', '.', 'b', 'c', 'c', 'h', '_', 'd', 'l', '_' ,'s', 'c', 'h', '\0', 0x00, 0x00, 0x00, 0x00}

Where 0x000C corresponds to EXP_PDU_TAG_PROTO_NAME option, 0x0014 to the option length, then the dissector name "lte_rrc.bcch_dl_sch", followed by a padding (as the option must be a multiple of words), then the EXP_PDU_TAG_END_OF_OPT option (0x0000) and a null length for this option (0x0000).

The advantage of this format is that you do not need to preconfigure Wireshark with the user DLT mapping. FYI 3GPP message decoder uses the User DLT approach as far as I know.

Regards,

Pascal.

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

___________________________________________________________________________
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