On Fri, Oct 15, 1999 at 08:31:17AM -0500, itojun@xxxxxxxxxx wrote:
>
>
>
> > Oops, I found a bad sideeffect of having inner IPv6 header to
> > the top level; topmost window would show that the packet is
> > UDP packet, not the PIM packet. I would like to backout your
> > change and put IPv6 header under PIM tree.
>
> The symptom will not appear when the capture file is loaded.
> To experience this, use some filter expression to filter the
> packets
> (like "ipv6.dst[0:2] == 3f:fe").
> One more bad sideeffects is that "ipv6.dst" would match the latter
> (tunneled) IPv6 header, not the first one.
>
> itojun
Actually, the display filter is supposed to work on tunnelled protocols; it's
supposed to look in both of the ipv6 headers for the ipv6.dst that you
specify. I tried to make it work, but since I never had a tunnelled protocol
on which to test, it turned out that my code didn't work.
How _should_ we handle tunnelled protocols?
With this frame:
0: Frame
1: Null/Loopback
2: IPv6
3: PIM
4: IPv6
5: UDP
6 Data
0-3 are the tunnel itself. 4-6 are the tunnel payload.
Some times you'll want the info from ipv6(2) in your columnar display, and
other times you'll want the info from ipv6(4). That is, sometimes you're
studying the tunnel itself, while other times you're studying the contents
of the tunnel.
And this affects not only the display, but the display filter. I could fix
the bug and make the dfilter match ipv6.dst from either ipv6 header (#2 and #4),
or we could try to make it match either, depending on whatever mechanism
we put in place to display ipv6 info from #2 or #6 (tunnel or tunnel-payload).
More discussion is necessary.
--gilbert
