Wireshark-dev: Re: [Wireshark-dev] Different wireshark behaviour on Linux as on Windows
On Wed, Mar 9, 2011 at 7:04 PM, Guy Harris <guy@xxxxxxxxxxxx> 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
