Hi Pascal, Okay great! Thank you very much for your time and support! I will go with the first alternative. \o/
with regards, k kumar On Mon, Jan 4, 2016 at 11:53 AM, Pascal Quantin <[email protected]> wrote: > Hi, > > 2016-01-04 0:18 GMT+01:00 Karunkaran Kumar <[email protected]>: > >> 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 <[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 >> > > > ___________________________________________________________________________ > 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
