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

[Kaul <mykaul@xxxxxxxxx>]

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

Kaul skrev 2010-10-25 23:55:

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

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@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.

 

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe