On 09/15/2015 07:38 PM, Pascal Quantin wrote:
Hi Jo�o,
Le 15 sept. 2015 4:41 PM, "Jo�o Valverde"
<joao.valverde@xxxxxxxxxxxxxxxxxx
<mailto:joao.valverde@xxxxxxxxxxxxxxxxxx>> a �crit :
>
> Hi,
>
> I'm trying to understand and troubleshoot some "Decode As" issues. To
give an example consider the packet:
>
> IPv6 | IPv6 | UDP
>
> Wouldn't the second IPv6 layer overwrite the Decode As protocol
number for the first layer, giving:
>
> IPv6 (Decode IP protocol 17 As:) | IPv6 (Decode IP protocol 17 As:)
| UDP
>
> Instead of the correct:
>
> IPv6 (Decode IP protocol 41 As:) | IPv6 (Decode IP protocol 17 As:) | UDP
Did you try it? In that case what result did you get? Can you share a pcap?
>
> Is this a bug, a known limitation of the current code, or just my
misunderstanding?
My understanding of the 'Decode As' functionality is that it will allow
you to override the default protocol id / next header value <-> sub
dissector mapping with another sub dissector call.
It means that in your example (if I understood it correctly) if you
change the sub dissector called for next header 17 it should not impact
another next header value (value 41 in first IPv6 header).
Note that I do not have access to the code right now to verify the
behavior, but that's what I would expect (it works like this for
Ethertype for example).
Regards,
Pascal.
Hi Pascal,
Looking at the code to handle this:
static void ipv6_prompt(packet_info *pinfo, gchar* result)
{
g_snprintf(result, MAX_DECODE_AS_PROMPT_LEN, "IP protocol %u as",
GPOINTER_TO_UINT(p_get_proto_data(pinfo->pool, pinfo,
proto_ipv6, IPV6_PROTO_VALUE)));
}
(...)
p_add_proto_data(wmem_packet_scope(), pinfo, proto_ipv6,
IPV6_PROTO_VALUE, GUINT_TO_POINTER((guint)nxt));
(...)
If you call p_add_proto_data() twice, first for the outer header with
nxt == 41 (IPv6 Encapsulation) and after that for the inner header with
nxt == 17 (UDP), only the UDP value will survive.
Both network layers will show a "Decode IP protocol 17 As" (UDP), that
seems incorrect. This first (outer) network layer should show "Decode IP
protocol 41 As" (IPv6 Encapsulation)...
It's not just a display issue. Selecting "Decode As" for the outer IPv6
header, decode as TCP for example, I'd expect the inner IPv6 header to
be decoded as TCP (and throw some errors for a malformed TCP header).
That's my understanding of how the feature should work, "decode next
layer as...". But instead the UDP (transport) layer is decoded as TCP,
ignoring the inner (network) header. So it seems to me that the code
doesn't handle a different layering other than:
<Network>
<Transport>
When you have:
<Network>
<Network>
<Transport>
as in this example, it breaks. The solution doesn't seem trivial... my
first impression is that p_add_proto_data() needs to store multiple
"nxt" values somehow for 'proto_ipv6', then using some field in *pinfo
to return the correct network layer value in ipv6_prompt(), and maybe
improving the layer decoding logic to handle the second case correctly?
Hope that makes sense.
Thanks,
Jo�o V.
>
> I don't think it is specific to IPv6, it's just an example. If it is
a limitation it seems the Decode As proto_value() interface needs to be
extended somehow, feedback very welcome.
>
> Thanks,
>
> Jo�o V.
>
___________________________________________________________________________
> 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
