Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Dissecting http2 traffic

From: Anders Broman <anders.broman@xxxxxxxxxxxx>
Date: Fri, 15 May 2020 22:24:13 +0000
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


From: Peter Wu <peter@xxxxxxxxxxxxx>
Sent: Friday, May 15, 2020 10:40:03 PM
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Cc: Anders Broman <anders.broman@xxxxxxxxxxxx>
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