[Ulf Lamping <ulf.lamping@xxxxxxxxxxxxxx>]

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?!?