Re: Dissecting http2 traffic

[Anders Broman via Wireshark-dev <wireshark-dev () wireshark org>]

Hi,
Yes it's related to that bug. And if memory serves the trace would illustrate the problem.
I don't see how the compression/decompression could recover as in showing the missing header element. I'm not sure I 
understand what your objection is. Is it in how to present the non decodable element? Alternative solutions welcome.  I 
have pushed the suggested code upstream but no feedback yet. I think it would be of service to the telco community to 
have an interim solution in Wireshark until we get something from upstream. If that's not acceptable I will use my own 
branch.
Best regards
Anders

Skickat från Outlook Mobile<https://aka.ms/blhgte>

________________________________
From: Peter Wu <peter () lekensteyn nl>
Sent: Friday, May 15, 2020 10:40:03 PM
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Cc: Anders Broman <anders.broman () ericsson com>
Subject: Re: [Wireshark-dev] Dissecting http2 traffic

On Fri, May 15, 2020 at 06:50:18AM +0000, Anders Broman via Wireshark-dev wrote:
> Hi,
>
> I think there is a demand to dissect http2 traffic where all packets in a
> session is not captured. This is currently not possible.
>
> As the http2 protocol creates dynamic data for compression/decompression and
> if the packet adding a new index to the index table is not
>
> Present then that header element can not be decoded in the packet(s) where
> it occurs. Also the nghttp2 library stops processing the
>
> Header and is left in an error state(I think).
>
>
>
> I have modified the nghttp2 code to handle unknown indexes
> https://protect2.fireeye.com/v1/url?k=d2592c57-8cf9ccc9-d2596ccc-86ee86bd5107-f102bcce985b9905&q=1&e=3d077b47-0100-4f28-aa79-f193cfe770be&u=https%3A%2F%2Fgithub.com%2Fnghttp2%2Fnghttp2%2Fpull%2F1467
>  and modified Wireshark to use
> it
>
> https://code.wireshark.org/review/#/c/37203/ as this pull request is not yet
> accepted and of course no nghttp2 release including it exists, there is
>
> a problem to get this functionality. Could we roll our own windows version
> of nghttp2 as a start? I have built a modified library for my tests.

I'd suggest to work with upstream nghttp2 to get the patches reviewed
first. The suggested approach of generating a dummy ":Failed deflate"
header seems wrong to me.

Depending on the lost data, it might not be possible to completely
recover. What kind of errors would you like to recover from? Do you have
an example trace? Is it related to
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16496?

Kind regards,
Peter

> Suggestions on how to proceed? For 5G who is a heavy user of http2 I think
> the ability to decode payloads are essential and this is a first step to fix
> that.
>
> Regards
>
> Anders
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe