Wireshark-dev: Re: [Wireshark-dev] Wireshark or protocol bug? (HTTP MIME multipart)
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Wed, 27 Oct 2010 08:56:22 +0200
On 10/25/2010 11:55 PM, Kaul wrote:



On Mon, Oct 25, 2010 at 3:30 PM, Jaap Keuter <jaap.keuter@xxxxxxxxx
<mailto:jaap.keuter@xxxxxxxxx>> 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 <mykaul@xxxxxxxxx
    <mailto:mykaul@xxxxxxxxx>> 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