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

[Anders Broman <a.broman () telia com>]

Kaul skrev 2010-10-25 23:55:
> 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.
Taking a brief look at your trace it seems like double CRLF may be 
missing in some places, compare
with this trace which I think is correct.
See also RFC 2046 5.1.1. I think I used RFC 2045 - 2049 helping to 
implement this.

> 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.
>
>     ___________________________________________________________________________
>     Sent via:    Wireshark-dev mailing list
>     <wireshark-dev () wireshark org <mailto: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
>     <mailto:wireshark-dev-request () wireshark org>?subject=unsubscribe
>
>
>
> ___________________________________________________________________________
> 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

Attachment: Multipart.pcap
Description:

___________________________________________________________________________
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