On Jan 7, 2017, at 1:15 PM, Francesco Fondelli <[email protected]>
wrote:
> the pw_eth_heuristic is too strong, it does not take into
> consideration locally-assigned MAC addresses and multicast (as noted
> in some bugs by Guy Harris and Michael Mann). Patches are welcome :-)
The heuristic used in the pw_eth_heuristic dissector is both too strong *and*
too weak:
it's too strong because it only recognizes globally-assigned MAC
addresses;
it's too weak because it only checks the MAC address - it doesn't check
whether, if the type/length field is a type field, the type is one we know or,
if it's a length field, whether the headers following the MAC header are
something we'll dissect.
Bugs for *both* of those problems have been filed.
> That said, I think the current situation is a good trade-off.
The *current heuristics* are clearly *not* a good trade-off, given the bugs
that have been filed. They need to be improved, in both directions.
> The not edulcorated version reads "Ethernet PW without control word is
> a pain in the ass, do not use it".
That may be the case, but apparently people *do* use it, and if we can make
life less painful for them without making life more painful for the people
"doing the right thing", we should do so.
> an other improvement could be to add logic to signalling dissectors
> (e.g. LDP, BGP) in order to add explicit label-to-dissector bindings.
> This would be useful only in case signalling and data plane are
> captured together. Therefore, I guess this is not common and it isn't
> worth it.
We *already* do that for some other control and data plane protocols; for
example, RTSP and SDP dissectors can set up UDP traffic to be dissected as RTP
(there are other examples as well), so I don't consider that a sufficiently
good reason not to do it.
___________________________________________________________________________
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
