Wireshark-dev: [Wireshark-dev] Refactoring use of a global variable in epan/packet.c?

From: "Babikyan, Armen - 0663 - MITLL" <armenb@xxxxxxxxxx>
Date: Fri, 30 Mar 2012 12:12:32 -0400
 Hello,

About a year and a half ago (Nov 2010), I mailed wireshark-{users,dev} about Sharktools, a library we created that provides the ability to access Wireshark's packet dissection features from within Python and Matlab. The respective tools are called "pyshark" in Python and "matshark" in Matlab. The post is here:

https://www.wireshark.org/lists/wireshark-users/201011/msg00028.html

The code is here:

http://github.com/armenb/sharktools

Since then, I've done some work trying to make the implementation more efficient and usable on gigantic packet capture files. Lately, I have been adding Python iterator support for pyshark, and am running into an issue with global variables in libwireshark. Specifically, I'd like to be able to support multiple independent packet capture parsing operations simultaneously. This feature is important in network analytics. For the most part, this functionality works fine (i.e. managing multiple cfile objects simultaneously just seems to work out-of-the-box).

However, I see an issue when it comes to applying a "decode as" string. Since dissector_tables is global (defined in epan/packet.c), and using dissector_change*() and dissector_reset*() modifies this data structure, I can't guarantee that my simultaneous packet parsing operations are independent. Actually, I ran a test, and they are not.

Question is this: if I patch epan/packet.c and all functions dissector_tables-related to pass around a pointer instead of using a global variable, does my patch have a snowball's chance of being accepted into Wireshark mainline? Of course, the simplest thing for me to do right now is detect a decode-as string mismatch between my Python iterator objects and throw a Python exception, but I'd rather go for clean functionality if I don't have to worry about maintainability of my own Wireshark source tree (this is definitely not the direction I want to go in, anyway).

I'd be interested in hearing your thoughts.  Thanks!

Armen

--
Armen Babikyan
Wideband Tactical Networking Group
MIT Lincoln Laboratory
armenb@xxxxxxxxxx . 781-981-1796


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature