Hi On Tue, Jun 21, 2011 at 1:55 AM, Ulf Lamping <[email protected]> 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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
