On Wed, Mar 9, 2011 at 7:04 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Mar 9, 2011, at 7:39 AM, Roland Knall wrote: > >> It would definitly not solve the underlying problem. but at least it >> would make the whole process predictable, which is definitly not the >> case now. > > That might or might not constitute an improvement; the file name given to a > plugin, or whether a dissector is a plugin or a built-in, probably has little > to do with whether a given dissector should or shouldn't be the one used for > a given type field value.
I agree, but the current situation, where the selection seems to happen purely by chance is also not ideal. > Of course, if the type field is, for example, an Ethernet type field, it's > not clear that there ever *SHOULD* be more than one dissector registered for > that type field value - if, for example, SercosIII was assigned the Ethernet > type value 0x88CD, no other protocol should ever use that Ethernet type, and, > thus, no other dissector should ever register with that Ethernet type value; > other protocols should get their own Ethernet type values SercosIII as well as Profinet, Ethernet Powerlink or Ethercat are so called Industrial Ethernet Protocols. For instance, they provide a network communication which is realtime-enabled, and where certain time values for message transportation are guaranteed. But her-in lies the main difference. With a protocol like Ethernet, every frame has the same meaning (transport), every frame has the same identity, and every frame has the same content. It is fairly easy, to dissect the payload of an ethernet frame and start a sub-dissector to dissect such a frameload. This is not the case with those protocols. The protocol whose dissector I am currently developing, uses two ways of receiving messages. On part is the SercossIII or Powerlink cyclic traffic, the second is the UDP traffic provided by the same network protocols. Also, the position of the openSAFETY (my protocol) packages within those layers of transportation is implementation dependant. And by that I do not mean the implementation of SercosIII in a given software stack, but also the configuration of the network itself. Therefore it is not possible to hand-off the payload of any message to the openSAFETY dissector. The dissector has to look at the whole frame itself, and determine, which parts are of interest for itself, and which aren't. In such a specific case, the registration of more than one dissector for a given ethernet type value is indeed not only possible, but useful. A way around this would be using a heuristic dissector for Ethernet, but this would mean loosing the dissector information of that specific dissector, or implementing the possibility of heuristic dissectors for SercosIII and Ethernet Powerlink. The second method is something I am actually looking into, and could solve the issue. > >> My favorite solution would be, that a dissector could register, that >> it should always get selected before all other dissectors. > > What happens if *two* dissectors make the same request? You would have the same situation as of now, but at least one dissector could get the chance to change the setup. I am not saying it is an ideal solution to this fairly unique problem, but it could be some sort of solution. kind regards, Roland ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
