Wireshark-dev: Re: [Wireshark-dev] plugins to builtins
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Ulf Lamping <ulf.lamping@xxxxxxxxxxxxxx>
Date: Mon, 20 Jun 2011 23:32:05 +0200
Am 20.06.2011 16:29, schrieb mmann78@xxxxxxxxxxxx:

(just added myself to the mailing list so I can include reply history to
the topic. This message touches on both Jaap's and Roland's comments)


As the (main) author of the PROFINET plugin I may add a few cents ...
Excuse me if I'm slightly wrong at some points, as I've left Wireshark and PROFINET development for some years now - so I might not be fully "up-to-date" on all topics. 


Profinet and Ethercat were the 2 protocols I was most looking at to
convert to built-ins. Being in the industrial protocol space, they are
(could be) the most useful to me. I've looked at the Profinet code, and
I don't really think it can be squeezed into a single file. There are
multiple protocols, each with drastically different dependencies(DCE/RPC
for I/O and DCOM for CBA), but also "common code" as well (packet-pn.[ch]).
While I see "grouped protocols" in the current epan\dissector directory,
I thought maybe Profinet could have its own directory off of it if
otherwise 'pollutes' the main dissector directory.
Unless something really changed in the Wireshark code internals, there's no good reason to change the profinet dissectors file structure (and e.g. put everything in a single file - sic!) for the reasons you've mentioned. 


I just see the
plugins directory as "Windows only"


That's simply wrong.


, and I don't think any protocol
should be limited if there isn't anything "Windows specific" about it.
My goal is to just increase "platform independent" code.


Then you're looking at the wrong place ;-)

Plugins run on "none Windows systems" just as well.


The part of Jaap's message that I sort of understand is the request to
keep dissectors as plugins for proprietary reasons.
Profinet/Ethercat/Modbus/CIP are all proprietary protocols (as I assume
there are many others that Wireshark dissects), but I think Modbus and
CIP have taken the attitude of having Wireshark know about the protocol
increases their use so they are more apt to let it go. Perhaps the
Profinet and Ethercat organizations don't feel the same way.
That one is making me a bit angry. I was the one who submitted the profinet dissector, AFAIK the very first fieldbus related dissector in Wireshark - in 2004 - with full support of the "PROFIBUS Nutzerorganisation e.V. Deutschland", see: 

http://anonsvn.wireshark.org/viewvc?view=revision&revision=12776
... quite a while before any of the other fieldbus protocol dissectors were committed we have nowadays. Arguing that the Profinet organization doesn't have "the right attitude" is a bit strange looking at the historical background.
You may disagree, but I see it (partially or course) as my personal achievement that we nowadays have a lot of the fieldbus protocols decoded in Wireshark.
BTW: The fieldbus related protocols you've mentioned are (all?) fully documented in IEC 61158. Arguing about one fieldbus protocol being "more open" than another one could better be done elsewhere IMHO. 


It sounds
like part of "development speed" is that plugin updates be can
distributed via the DLL much faster than Wireshark publishes releases
(doesn't everybody want their patches to be applied ASAP?).
Do you really want to have a dissector that crashes now and then? Do you really want to have a dissector that shows things quite different compared to the final version of the spec - without any devices in the field actually using that protocol version?
What you seem to be missing, is that the network protocol itself (and the Wireshark dissector along the way) is also developed, but see below. 


What also
confuses me is the GNU licensing part of it. If the code is there
anyway, what is being protected? Are they worried a novice developer
will submit a patch that messes up the dissector? Unless the core
developers have been given instructions to only accept patches from
particular people, that could still happen with the plugin.
Wow, that's the first time in my life that I'm on the other side of the conspiracy theory ;-)))
Seriously, having a plugin and not a builtin was my very own personal decision, as it's just faster to build a plugin than the whole Wireshark (for me it makes a difference during development/debugging to wait for seconds and not for minutes) and sending the plugin to the colleague sitting next to me is also easier and faster.
I'm not strictly for or against a plugin or builtin here, but if you plan to do structural changes in that dissector it would be nice to announce it a few weeks before, so potential conflicts can be kept at a minimum on all sides ... 

Regards, ULFL
P.S: Maybe I've missed it - could someone shortly explain why "everyone" nowadays wants to remove plugins - only "I don't like plugins" isn't a very good one IMHO?!?