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:[EMAIL PROTECTED] 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 _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
