Yeap, that is exactly the case with for instance openSAFETY. Usually a list would be eth:epl:opensafety|opensafety|opensafety (using | to better define the parrallel behavior).
Same goes for nearly all industrial ethernet protocols, who implement bus coppler devices, where by definition multiple protocols can be seen on the overlying fieldbus in a single packet. cheers On Fri, Oct 6, 2017 at 8:55 AM, Guy Harris <[email protected]> wrote: > On Oct 5, 2017, at 11:23 PM, Roland Knall <[email protected]> wrote: > > > Personally I think moving to a set would reduce functionality for some > applications. Industrial ethernet applications for instance heavily rely on > multiple protocols being transported in single frames multiple times (one > UDP packet contains a lot of openSAFETY frames, which themselve could > contain data dissectors). > > So there are cases where, for example, for code that examines the protocol > list, that code would need to see, for example, eth:ip:tcp:x11:x11:x11 for > a TCP segment containing three X11 requests or replies, rather than just > seeing eth:ip:tcp:x11? > > (BTW, the protocol list is a linearization of a structure that's not > linear - x11:x11:x11 doesn't mean X11 inside X11 inside X11, it means 3 > X11's inside TCP. Hopefully no software naively assumes that the protocol > list is a tower of protocols, rather than just a representation of what you > see if you move forward through the packet and any reassembled chunks.) > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
