Hi All I am building a dissector that is my own. After dissecting my past of the packet (which is successfully done) i would now also like to dissect the payload that it carries It carries LTE MAC payload. How should i start this. Is there any tutorial to do these kind of nested packet dissection. Please suggest asked 10 Apr '12, 00:27  Nagu edited 10 Apr '12, 07:21  grahamb ♦ |
One Answer:
I'd suggest you look at the existing places that call the MAC-LTE dissector (as described in http://wiki.wireshark.org/MAC-LTE ). So, epan/dissectors/packet-mac-lte-framed.c and epan dissectors/packet-catapult-dct2000.c. In epan/dissectors/pac-mac-lte.c itself, see the functions set_mac_lte_proto_data(), get_mac_lte_proto_data() and dissect_mac_lte_context_fields(). Probably you'll want to call set_mac_lte_proto_data() and get_mac_lte_proto_data(), and if you don't use dissect_mac_lte_context_fields() I expect you'll have something similar that fills in the mac_lte_info struct. answered 10 Apr '12, 04:31  MartinM edited 20 Apr '12, 15:23 showing 5 of 17 show 12 more comments |
Hi Martin
Thanks for the useful suggestion
I just had a look at the file packet-catapult-dct2000.c
Now my question is is it mandatory that the pinfo needs to be populated with the mac_lte_info structure .
The reason I am asking it here is that until I dissect some of the bytes inside the packet I will not be able to fill the mac_lte_info structure with right value
Is there any reason for having it there
Regards nagu
Yes, filling in the mac_lte_info structure is mandatory. Some of the information is really needed, e.g. - the type of RNTI and direction are needed to know what format the data is - the length is used to how much padding might follow and to report better stats. Know this length also helps in marking frames as malformed if they are. - the UEId isn't really needed, but is handy for status and following the same UE across temporary RNTIs, etc - the PHY attributes are for information only, you can mark them as not present, but I find them very useful
Usually, I'd assume that you read the context information that you use to fill in the mac_lte_info from some header that you've stored in your overall frame before the PDU. But if you were inferring some of the context information by looking at the PDU itself (is this what you mean?), you could still scan ahead, fill in the context, then build a tvb starting from the beginning of the PDU proper before calling the mac-lte dissector.
Hi Martin
After filling the context information , i am able to call MAC-LTE for dissection of Packets (MAC PDUs)
But will MAC-LTE call Other dissectors like RLC PDCP etc by default ?
Is There anything that I am supposed to do to get this achieved
By the way I was not able to get the sample code that was posted above by you.
One more observation that I observed was That I was not getting the MAC subheaders dissected and listed in the UI
Any reason for this ?
Thanks and regards, Nagu
You need to configure MAC to call RLC, and RLC to call PDCP (and PDCP to call RRC for signalling-plane and IP for user-plane) using the preferences. So you'll need to make sure LCID 1&2 are treated as SRB1&2. And for DRBs, to add the appropriate entries to the table. Then tell RLC to call PDCP for signalling and bearer channels (12-bit SN for DRBs for AM channels).
The link in the earlier message included a trailing ')' character. Oops!
The MAC subheaders should have been dissected. What did you see? Martin
Hi Martin,
Did you mean to set preferrences programatically or through the UI.
I could see in files packet-mac-lte.c the preferrences were automatically set to TRUE for the dissection via lte-rlc etc by using the functions like prefs_register_bool_preferrence.
What are heuristic dissectors.? Any tutorials that explain in details.
I changed my code such that now I start my Buffer with a string for mac-lte and then append the same with TAGs.
Can I call heuristic mac-lte dissector for this.
Unfortunately, I am not able to access the sample program in your MAC-LTE page.
Regards, Nagu
I meant to set preferences through the UI. In packet-mac-lte.c you will see the default values for the various preferences, but you can set them to what you need and they will persist when you next start wireshark.
A heuristic dissector means that it isn't tied to a particular UDP port, but that for UDP payloads that don't match anything else, the various heuristic dissectors will get called to see if the payload matches that protocol. When you turn on the heuristic dissector for MAC-LTE using the preference setting, it will look at 'unclaimed' UDP payloads and 'claim' them if they begin with that pattern.
So no, you would not call the heuristic dissector. You would either use it by sending frames over UDP in the format it understands, OR use your own dissector (as you say above), fill in the mac_lte_info structure and call the mac-lte dissector yourself (in which case you wouldn't need to include the string used by the heuristic dissector).
I can't access the sample programs from the MAC-LTE page either at the moment, although the files are in my folder there. It sounds as though you have your own framing format, and don't need the sample programs, but if you send me an email I could send them to you.
If you are still interested, the sample programs are now again accessible.
Thanks Martin I have two other question
Upon Logging with the root user, wireshark UI does not show the plugin that I have written
What is the procedure to make this visible even at root
I have run ./configure and made a clean build
I tried setting the DISPLAY=:0.0 and DISPLAY=0.0
Did not work either
Any solution for this
--Nagu
Maybe you need to run 'make install' again?
Hi Martin
Shouldnt MAC update the info column upon calling the mac-lte Dissector
Similarly if an RLC dissector gets called will it not get update automatically onto the info column
I still see that the Info column is having what I intended it to be there and not what MAC is expected to put
Is this the expected Behaviour
Please suggest
Regards, Nagu
Nagu,
The MAC dissector clears the info column if it finds the mac_lte_info struct is set. This should work unless you have set the column not to be writable in your own dissector.
Note that there is a dissector preference to control which layer (PHY | MAC | RLC) that gets shown in the info column. Most of the time 'RLC' is the most appropriate. There is also a setting in PDCP to control whether the info column should show RLC | PDCP | Traffic, which I tend to change around depending upon which layer I am interested in.
Hi Nagu,
Can you please let me know which procedure you have followed to call the mac dissector.
Regards, Ashish
Hi Martin/Nagu,
Can i call dissect_mac_lte from plugin directly ?
Regards, Ashish
You don't call it directly, you look up the handle for the dissector and call it using call_dissector_only() with that handle and the subset of data that is the MAC PDU. See packet-mac-lte-framed.c or packet-catapult-dct2000.c.
You will also want to call get_mac_lte_proto_data() and set_mac_lte_proto_data() (see packet-mac-lte.h) - these are available from a plugin.
Martin, packet-mac-lte-framed.c i dont see in wireshark 1.6.7,is it available in some other wireshark version ?
It is available in 1.6.5 . Which I had used
You can otherwise refer to packet_catapult. If you cant ind it still . Let me know if you want me to paste the code for that