Hi João,
Le 15 sept. 2015 4:41 PM, "João Valverde" <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.
>
> 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>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe