[João Valverde <joao.valverde@xxxxxxxxxxxxxxxxxx>]

On 08/22/2015 02:58 PM, Jo�o Valverde wrote:
> On 08/22/2015 02:28 PM, Jo�o Valverde wrote:
> > On 08/22/2015 09:29 AM, Alexis La Goutte wrote:
> > > On Sat, Aug 22, 2015 at 8:10 AM, Jo�o Valverde
> > > <joao.valverde@xxxxxxxxxxxxxxxxxx
> > > <mailto:joao.valverde@xxxxxxxxxxxxxxxxxx>> wrote:
> > >
> > >     I'm not so sure now that I've done some tests with short and long
> > >     header chains, I think I'll drop it.
> > >
> > > Can you push your proto ? or add some screenshot to see the different ?
> >
> >
> > For now all I did was:
> >
> > diff --git a/epan/dissectors/packet-ipv6.c
> > b/epan/dissectors/packet-ipv6.c
> > index 1c07776..76e5285 100644
> > --- a/epan/dissectors/packet-ipv6.c
> > +++ b/epan/dissectors/packet-ipv6.c
> > @@ -2225,7 +2225,7 @@ dissect_ipv6(tvbuff_t *tvb, packet_info *pinfo,
> > proto_tree *tree)
> >
> >       if (nxt == IP_PROTO_HOPOPTS) {
> >           options_tvb = tvb_new_subset_remaining(tvb, offset);
> > -        advance = dissect_hopopts(options_tvb, pinfo, ipv6_tree, &iph);
> > +        advance = dissect_hopopts(options_tvb, pinfo, tree, &iph);
> >           if (advance > 0) {
> >               nxt = tvb_get_guint8(tvb, offset);
> >               offset += advance;
> > @@ -2274,7 +2274,7 @@ again:
> >       nxt_handle =
> > dissector_get_uint_handle(ipv6_next_header_dissector_table, nxt);
> >
> >       if ((nxt_handle) &&
> > -        ((advance = call_dissector_with_data(nxt_handle, options_tvb,
> > pinfo, ipv6_tree, &iph)) > 0)) {
> > +        ((advance = call_dissector_with_data(nxt_handle, options_tvb,
> > pinfo, tree, &iph)) > 0)) {
> >           nxt = tvb_get_guint8(tvb, offset);
> >           offset += advance;
> >           plen -= advance;
> >
> >
> > I had meant to change the ipv6.nxt dissectors to ip.proto but didn't get
> > that far.
>
> For most practical cases I still feel it would be a net benefit visually
> and functionally, although you can get into some pretty pathological
> cases with ridiculously long extension header chains and IP over IP.
>
> The one header that gets to me the most being hidden is AH, although it
> is consistent with the current policy (MobileIPv6 is not IMO).

Another thing I personally find inconvenient sometimes is that the 
extension header is a true IP protocol header but it's not very 
immediate to visually distinguish the header from just a regular IPv6 
header field.

Just a small usability issue IMHO.


> > >     Regards,
> > >
> > >     Jo�o V.
> > >
> > >
> > >     On 08/21/2015 06:04 PM, Jo�o Valverde wrote:
> > >
> > >         I forgot to include:
> > >
> > >         f) it would fix this[1] bug too.
> > >
> > >         [1]https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9996
> > >
> > >         On 08/21/2015 05:45 PM, Jo�o Valverde wrote:
> > >
> > >             Hi,
> > >
> > >             I would like to propose a patch to remove IPv6 extension
> > >             headers from
> > >             the IPv6 subtree and display them as normal IP protocols in
> > >             the UI.
> > >
> > >             Arguments for:
> > >
> > >             a) The current behaviour really, really, (really) hurts
> > >             legibility
> > >             b) It would be consistent among all extension headers (see
> > >             for example
> > >             MobileIPv6 vs AH - why the difference?)[1]
> > >             c) Extension headers aren't special in this regard, the IP
> > >             protocol
> > >             space is shared
> > >             d) IPv6 extension headers over IPv4 would be dissected, as
> > >             they should.
> > >             An expert info error can then be displayed where
> > > appropriate.
> > >             e) It would do away with the hack (?) used for the AH
> > >             dissector (I
> > >             think, I haven't looked very closely yet here).
> > >
> > >             Arguments against:
> > >             ?)
> > >
> > >             Would anyone object to this proposal?
> > >
> > >             Thanks!
> > >
> > >             Jo�o V.
> > >
> > >             [1]https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10705
> > >
> > >
> > > ___________________________________________________________________________
> > >
> > >
> > >     Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx
> > >     <mailto:wireshark-dev@xxxxxxxxxxxxx>>
> > >     Archives: https://www.wireshark.org/lists/wireshark-dev
> > >     Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> > >                  mailto:wireshark-dev-request@xxxxxxxxxxxxx
> > >     <mailto:wireshark-dev-request@xxxxxxxxxxxxx>?subject=unsubscribe
> > >
> > >
> > >
> > >
> > > ___________________________________________________________________________
> > >
> > >
> > > Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> > > Archives:    https://www.wireshark.org/lists/wireshark-dev
> > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> > >
> > > mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe