On Mar 9, 2011, at 10:34 AM, Roland Knall wrote:
> I agree, but the current situation, where the selection seems to
> happen purely by chance is also not ideal.
The *ideal* situation would be one wherein registering more than one dissector for a given type value would be an error, and other, better mechanisms are provided to handle the cases where one might immediately think that's the right way to handle it.
> 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.
In Ethernet, every frame has the same header - 6-octet destination address, 6-octet source address, and 2-octet type/length field - and those fields are interpreted in the same fashion.
Which of that is not true for "Industrial Ethernet protocols"? According to
http://www.sercos.de/Communication-Protocol.159.0.html
SERCOS III "uses IEEE 802.3 compliant Ethertype 0x88CD"; does that mean that it sends out frames with the two addresses in question, followed by a type/length field value with the type 0x88CD?
>
> 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,
Is the SERCOS III cyclic traffic the traffic they mention in the page I cited, carried in standard Ethernet frames with an Ethernet type of 0x88CD?
> the second is the UDP traffic provided by the same network protocols.
Those can easily be distinguished from SERCOS III-over-Ethernet frames, as the UDP frames will have an Ethernet type of 0x0800 (if it's UDP-over-IPv4) or 0x86DD (if it's UDP-over-IPv6).
> Also, the position of the openSAFETY (my protocol) packages within
> those layers of transportation is implementation dependant.
According to
http://www.open-safety.com/
it appears that openSAFETY runs on top of SERCOS III, which presumably means that, at the layer above Ethernet, the frames are standard SERCOS III frames, which should be handled by the standard SERCOS III dissector. Is that not the case? Is the problem that openSAFETY is *not* carried in standard SERCOS III frames, or is it that they *are* carried in standard SERCOS III frames but the *current* mechanism in the SERCOS III dissector to hand off to subdissectors is inadequate for openSAFETY, in which case the fix is presumably to enhance that mechanism?
> And by
> that I do not mean the implementation of SercosIII in a given software
> stack, but also the configuration of the network itself.
The configuration of the network itself should be irrelevant to Wireshark; is that not the case?
> Therefore it is not possible to hand-off the payload of any message to
> the openSAFETY dissector.
Why not? Could you give an example of this? Could you give, for example, a link to the working draft for openSAFETY over SERCOS III, so we can see how this works?