Hi
On Tue, Jun 21, 2011 at 1:55 AM, Ulf Lamping <ulf.lamping@xxxxxxxxxxxxxx> wrote:
> Am 21.06.2011 00:27, schrieb Roland Knall:
>> There is nothing technically wrong with dissectors being developed as
>> plugins. There might be some technical questions that arise from that
>> fact, if another dissector is using them, but for now, those issues
>> seemed to be dealt with correctly (for reference see the whole
>> openSAFETY vs. SercosIII mix-up)
>
> Could you give me a link - as noted I'm not involved in recent stuff.
If you google it, there is a great number of messages on this list,
stating this very fact from guys like Guy or Jaakob, stating that
motivation.
> If another dissector is using it, there might be problems arising. This
> sounds like a reasonable thing to think about.
To clarify what I want to achieve here. The openSAFETY protocol can be
implemented using various fieldbus protocols. For instance, we have
implementations for Powerlink, SercosIII and Modbus/TCP. Part of the
nature of a fieldbus protocol is the fact, that the message is hidden
using a specific configuration for the underlying network. So I do not
know, which part of data contains openSAFETY messages and which does
not.
The openSAFETY dissector parses the whole package provided for
dissection to the EPL or SercosIII dissectors, and determines the
start position of each individual openSAFETY frame. To be able to do
this, without the deeper knowledge for a defined object dictionary, I
have to parse the data before(!!) the actual fieldbus dissector is
able to do his work. The heuristic dissector for SercosIII as well as
for EPL allows exactly that. And that kind of dissector would be added
to the Profinet.
Now, the problems I had with the SercosIII plugin came from the fact,
that it was a plugin, and therefore its proto_register method was
called after(!) the proto_register method for the built-in dissectors.
This lead to some confusion, where the dissector was not registered
correctly. It was an issue on my part, and got fixed, by putting the
registration code in the correct function (proto_reg_handoff), and
providing a fallback, if the dissector could not be loaded (dissection
by simply adding on to the SercosIII ethertype), or did not contain
the correct heuristic dissector. The same method will be applied by
myself for the Profinet code. The only difference on my part for
Profinet being builtin would be, that I would not need the fallback.
> AFAIK, this means you have locally installed your personal plugin. Causing
> for trouble - I'll already had personally.
Sure, never blamed wireshark here. But one of your arguments was the
easy method of distributing a new version for the plugin. We all know,
that Windows can sometimes be very tricky when it comes to loading
DLL's, therefore the same mix-up can happen here.
>> For all it's worth, I don't care anymore if the Profinet dissector
>> stays where it is, or not. I will send in a plug-in in the near
>> future, adding a heuristic dissection table, similair to SercosIII,
>> but besides that, I just thought of it as a good practice exercise for
>> myself moving the whole thing.
>>
>> One more thing though, Ulf. Modbus/TCP was added with Rev. 3376, EIP
>> with 7851. Both are fieldbus protocols. Credits were credits due.
>
> Sounds a bit like a missunderstanding here. The thing I've mentioned was:
> with full support of the "PROFIBUS Nutzerorganisation e.V. Deutschland"
My argument was more on the line of being the path-layer for other
fieldbus protocols. Wireshark being open source, I think it really
does not matter that much, if the protocol get's the official support,
or not. I don't think, that any user organization would mind, having
one more debugging tool.
kind regards,
Roland