wireshark-dev October 2010 archive
Main Archive Page > Month Archives  > wireshark-dev archives
wireshark-dev: Re: [Wireshark-dev] Wireshark or protocol bug? (H

Re: [Wireshark-dev] Wireshark or protocol bug? (HTTP MIME multipart)

From: Kaul <mykaul_at_nospam>
Date: Tue Oct 26 2010 - 20:50:16 GMT
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>

On Tue, Oct 26, 2010 at 5:59 PM, Anders Broman <a.broman@telia.com> wrote:

> Kaul skrev 2010-10-25 23:55:
>
>
>
> On Mon, Oct 25, 2010 at 3:30 PM, Jaap Keuter <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.
>

Strange indeed. The capture is from a (successful) remote Powershell
connection between Windows systems, utilizing Kerberos authentication.
MS bug...?
Y.

>
>
> TIA,
> Y.
>
> Thanks,
>> Jaap
>>
>> On Sun, 24 Oct 2010 12:08:18 +0200, Kaul <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>
>> Archives: http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-request@wireshark.org
>> ?subject=unsubscribe
>>
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> <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 <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
>

___________________________________________________________________________
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