On Tue, Oct 26, 2010 at 5:59 PM, Anders Broman <[email protected]> wrote:
> Kaul skrev 2010-10-25 23:55: > > > > On Mon, Oct 25, 2010 at 3:30 PM, Jaap Keuter <[email protected]>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 <[email protected]> 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 <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected] >> ?subject=unsubscribe >> > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > <[email protected]?subject=unsubscribe> > > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
