On 10/25/2010 11:55 PM, Kaul wrote: > > > On Mon, Oct 25, 2010 at 3:30 PM, Jaap Keuter <[email protected] > <mailto:[email protected]>> wrote: > > Hi, > > I see no problem here. It loads fine in Wireshark 1.4.1. > > What I do see, and which is a bug in Wireshark, is that it doesn't > treat it as multipart/mixed, as stated in RFC 2046, Section 5.1.3: > > Any"multipart" subtypes that an implementation does not recognize > must be treated as being of subtype"mixed". > > > Indeed (and I'll see if I can fix that), but I've actually also > specifically added multipart/encrypted to packet-multipart (and > registered gssapi in multipart_media_type table and in media_type table > so it'll recognize it specifically) - bu I still get the exception > (because of the missing CR-LF-CR-LF expected?). RFC 1847, section 2.2 > seems to show an example - with double CRLF. > > TIA, > Y. > > Thanks, > Jaap > > On Sun, 24 Oct 2010 12:08:18 +0200, Kaul <[email protected] > <mailto:[email protected]>> wrote: > >> I'm trying to add dissection of Kerberos encrypted HTTP sessions. >> Mostly, it's OK (got the headers parsed correctly, would file a BZ >> for this patch soon). >> However, when I'm trying to work with the body, which is a MIME >> multipart, it fails with exception. >> The reason seems to be that it does not have the double CRLF which >> is expected between headers and body of a MIME (?): >> imf_find_field_end() seems to fail to find additional CRLF - >> before the binary data (which is actually a Kerberos blob) appears. >> >> Attached please find a small capture showing the problem - not >> sure who's fault it is - or if it's fixable somehow in Wireshark. >> See packet 8 (dissect as HTTP please). >> >> Regards, >> Y.
Hi, I've committed the changes to handle unknown multipart subtypes as multipart/mixed in revision 34657. Unfortunately the protocol dissector itself has to be modified to make us of this feature. The HTTP dissector makes use of it as from revision 34658 and the SIP dissector from revision 34659. Others may have to follow. With these changes your issue becomes apparent when loading your capture. Now all we have to do is figure out what's wrong. Should be easy... Thanks, Jaap ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
