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 <[email protected]> wrote: > > Le 2 janv. 2016 9:22 PM, "Karunkaran Kumar" <[email protected]> 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
