|Main Archive Page > Month Archives > wireshark-dev archives|
On 10/25/2010 11:55 PM, Kaul wrote:
> On Mon, Oct 25, 2010 at 3:30 PM, Jaap Keuter <firstname.lastname@example.org
> <mailto:email@example.com>> wrote:
> 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.
> On Sun, 24 Oct 2010 12:08:18 +0200, Kaul <firstname.lastname@example.org
> <mailto:email@example.com>> 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).
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...
Sent via: Wireshark-dev mailing list <firstname.lastname@example.org>