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] [Wireshark-commits] rev 20247:/trunk/epan/dissectors/ /trunk

From: "Kukosa, Tomas" <tomas.kukosa@xxxxxxxxxxx>
Date: Sat, 6 Jan 2007 11:18:05 +0100
Of course, it would be necessary to merge those records during desegmentation process is subdissector  requires it. Then HTTP shouls work. My proposal is not to do it automatically without request from subdissector.
 
I will look into the code again on Monady. 
 
BTW I affraid SSL dissector will not work if app data records are together with non-app data records in one frame. SSL dissector attaches with p_add_proto_data() different kind of data for app and non-app records and is not able to combine them.
 

 
________________________________

Od: Stephen Fisher [mailto:stephentfisher@xxxxxxxxx]
Odesláno: so 6.1.2007 0:39
Komu: Kukosa, Tomas
Předmět: Re: [Wireshark-dev] [Wireshark-commits] rev 20247:/trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ssl.c




On Fri, Jan 05, 2007 at 08:48:13AM +0100, Kukosa, Tomas wrote:

> I can see two possible solution how to handle it:
> 1) do not merge decrypted data from different record within one frame
> and handle them one by one
> 2) merge those data but call subdissector only from the last SSL
> record for all merged data
>
> I prefer solution 1) as it is nearer to similar solutions in
> Wireshark. But it would require more changes in desegmentation of
> application protocol across more frames.

The issue with solution 1 is that protocols such as http need the data
from each record combined to display the tree information correctly. 
The HTTP over SSL captures I have seen place the HTTP response headers
in one SSL application data and the HTML line based data in the second. 
If we called the http dissector twice, it wouldn't know on the second
pass that it was line based html data (determined by the context-type in
the headers).

Solution 2 is closer to what I was trying to acomplish.  If we figured
out a way to tell when the dissector was handling the final SSL
application data instead of the first (like my patch did) and still
combining it, would you still see problems with your tc dissector?

My patch seems to have caused more problems than it helped - shall I
roll it back until we figure out a better solution?


Steve