mailing list archives
Re: PIM dissector
From: Jaap Keuter <jaap.keuter () xs4all nl>
Date: Sat, 06 Apr 2013 16:17:22 +0200
On 04/05/2013 05:04 PM, mmann78 () netscape net wrote:
I was looking at making the PIM dissector more filterable and noticed that it
has been labelled a "tunnelling protocol" (per revision 827), so that subsequent
layers (ie IPv4/IPv6) are branched from within the PIM dissector and not on the
"main" tree. Is this (still) standard practice? Taking the sample capture from
the wiki, it just looks "visually off" to have the IP and subsequent layers come
off of the "PIM options tree". Perhaps at least a new tree under the PIM
dissector should be used instead of "options"? I personally don't see anything
wrong with just putting the IP and subsequent layers on the main tree (and that
code has remained but been #if 0ed out since revision 827).
Talking about a blast from the past...
It seems they were going back and forth about this, settling in r901. I've
attached a patch that allows you to play with either configuration.
As this part of the PIM message isn't intended for the PIM entities themselves,
but uses the PIM protocol to carry the message across, the carried payload (IPv4
or IPv6 in this case) will be put onto a section of the destination network.
Therefore this is an independent part of the PIM message. IMHO, it should go in
the main tree.
As an example of such a payload which should not be on the main tree look at
ICMP. There the header is part of the message and not destined other than the
receiving ICMP entity.
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
- PIM dissector mmann78 (Apr 05)
- Re: PIM dissector Jaap Keuter (Apr 06)