[mmann78@xxxxxxxxxxxx]

Pardon my ignorance on a few of these points, still learning the ropes.  I don't mean to incite protocol flame wars, just trying to analyze code.   However reading README.plugin I still get the impression that

1. Plugins aren't supported on all platforms. The "Windows only" was just a BIG mistake on my part but it still doesn't sound like "all" platform could be supported (but perhaps I'm still wrong there), so builtins may be prefered.

2. Plugins are "separate but not quite equal" to builtins

3. "Simple" protocols should really be done as a builtin. (I thought mostly because the shear number of files necessary for a plugin wasn't worth it)

 

I guess I'd like to see more guidance on the decision for a plugin.  If "complexity" or LOCs are big determining factors, I think some of the current builtins should be converted to plugins from a "code organization" standpoint although I don't like the sacrifice of source control history - the same problem you have going from multiple source files (from plugin) to single builtin file.   They would serve as good examples of "when to use a plugin".  Sometimes the exception turns into the rule and dissectors end up with way too many LOCs and become somewhat unmanageable.  Can a protocol/dissector grow enough that maybe "plugin" status is warranted?  It's not really exciting work to split them up, but it allows someone (like me) to become more familiar with APIs.

I am very familar with the CIP protocol and have some cursory knowledge of the Profinet protocol and they seem similar in complexity. Profinet is a plugin and CIP is a builtin. The CIP dissector needs some cleanup/enhancement and I've been trying to learn the best way to do that (in hopes of submitting another patch to the dissector).  I work a lot better by "learning by doing", and some of the patches I've submitted were good learning exercises for me (and hopefully the Wireshark community is better for them as well) in terms of architecture/API.  Given the current discussion, does it make sense to start breaking the CIP dissector up into multiple files (like Profinet) just for the shear volume it could turn in to?  For "legacy reasons" is CIP stuck as a builtin?

 

 

-----Original Message-----
From: Ulf Lamping <ulf.lamping@xxxxxxxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>
Sent: Mon, Jun 20, 2011 5:36 pm
Subject: Re: [Wireshark-dev] plugins to builtins

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?!?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe