Re: Wireshark or protocol bug? (HTTP MIME multipart)

[Jaap Keuter <jaap.keuter () xs4all nl>]

On 10/25/2010 11:55 PM, Kaul wrote:
> On Mon, Oct 25, 2010 at 3:30 PM, Jaap Keuter <jaap.keuter () xs4all nl
> <mailto:jaap.keuter () xs4all nl>> 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 () gmail com
>     <mailto:mykaul () gmail 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).
> >
> >     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 <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe