This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

“Smaller tshark” for specific protocol

0

Hi all, as we know, wireshark is a big open source project with contributions from many developers. It is able to decode many, many protocols and this number is increasing day by day. But actually in some specific tasks, we just need to use to decode very few protocol, for example in my case, i use CAMEL only. I'm using a big wireshark to build, to run for a very small objective. So, I wonder: is there any way to take the advantage of wireshark to build a new project which is smaller, and just focus on specific protocol. All I need is running tshark to decode CAMEL, no need to have GUI, no need to dissect other protocols, no more, no less. In other words, wireshark might be considered as giant Goliath while in some specific cases, young David is more useful. I think it is possible but I don't know how to start because of my poor experience. If you have any suggestion, please tell me your idea. As usual, your comment always help me a lot. Thanks.

asked 31 Oct '13, 01:02

hoangsonk49's gravatar image

hoangsonk49
81282933
accept rate: 28%


One Answer:

0

I guess this question is based on my recommendation in a comment of the following question:

http://ask.wireshark.org/questions/25794/tshark-generate-core-dump

Cite: Maybe you can just use parts of the dissector engine to build your own real time monitoring system for the protocol you want to monitor.

However: Just removing other dissectors will not necessarily solve your main problem (tshark lagging behind dumpcap), as you won't change the architecture of the dissection engine and you won't change the way how dumpcap and tshark interact.

You can already today disable the dissectors you don't need. That will improve dissection speed a bit, but probably not enough to solve your problem.

Analyze -> Enabled Protocols

But, even if you disable some dissectors and/or you don't compile them into tshark/Wireshark, the original problems remain:

  • tshark/Wireshark was not built with real-time and long-term monitoring in mind.

Thus, you will hit

  • the memory problem (sooner or later) even if you remove most of the dissectors.
  • and you will hit the problem with tshark lagging behind dumpcap, as that's a structural problem due to the way how dumpcap and tshark interact.

What I originally meant in that comment: Take the code of the CAMEL dissector and try to build your own monitoring tool, just for that protocol, based on some libpcap programming tutorials, meaning: build your own little CAMEL 'dissector' with the help of the CAMEL dissector code, but without the Wireshark dissection engine.

Please take a look at the code of tcpdump. It has also dissection capabilities for certain protocols, while it works differently than Wireshark. That might be a good starting point for your own monitoring tool.

UPDATE
Just to make this clear: Writing your own CAMEL dissector, based on the Wireshark dissector and tcpdump code, sounds easy, but it is not that easy!! You'll have to implement some other protocols as well before you get to your CAMEL data. But I guess you already knew this ;-)

BTW: It would be nice if you could close some of your other questions by either accepting one of the answers or by answering the question yourself and then choose that as the correct answer, if you have a better solution than what was suggested by others.

Regards
Kurt

answered 31 Oct '13, 03:25

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 31 Oct '13, 06:38

Agreed. You can already take the GUI out by doing ./configure --without-gtk2 --without-gtk3 and anyway that just saves you the compile time (it won't affect tshark at all).

Taking out dissectors (which you could do by careful removal in the Makefiles and maybe some minor code changes) probably also won't help the speed unless you happen to take out some heuristic dissectors which are looking at your CAMEL packets before they reach the CAMEL dissector.

Removing dissectors will reduce the memory footprint but the amount of code you'll save will be negligible compared to tshark's dynamic memory allocation. tshark will be slightly faster to load the first time you run it if you strip out all that code but it won't affect run-time speed (again, unless you find some heuristic dissectors in your way).

(31 Oct '13, 06:18) JeffMorriss ♦

Please take a look at the code of tcpdump

Thanks, that is what I want to do. I 'll check the code of tcpdump to have a basic understanding of how to start.

the memory problem (sooner or later) even if you remove most of the dissectors

Yes, I know this problem is really serious. Maybe I cannot solve it but as I see in my system, it spends about 14% of 8 GB RAM after 1 week and so, I can restart tshark twice a month. Although my service must be stopped in 1 second and some packets could be lost, but it could be acceptable by doing this at 3 or 4AM when there are only 10-14 calls/second.

and you will hit the problem with tshark lagging behind dumpcap, as that's a structural problem due to the way how dumpcap and tshark interact

and

it won't affect run-time speed

I'm doing some experiments related to this problem to find a workaround. I will answer in my other question after I finish

BTW: It would be nice if you could close some of your other questions by either accepting one of the answers or by answering the question yourself and then choose that as the correct answer, if you have a better solution than what was suggested by others

Actually, for some suggestions and ideas provided by this community, I need to analyze and verify if it is possible to work well with my system. It is more practical than talking in theory :-) .Also, I'm doing some experiments that i think it is a good way at least for my case but it has not been finished. So, some of my questions which are related to practical problem are still pending.

(31 Oct '13, 18:45) hoangsonk49