On Thu, Apr 12, 2007 at 11:24:48PM -0400, Small, James wrote:
>
> > > > [Malformed Packet: SSL]
> > > >
> > > > Is the packet really malformed, or is it possible that Wireshark
> > > > doesn't support the cipher being used? If so, is there any way to
> > > > tell if the packet is really malformed versus Wireshark just not
> > > > understanding it/the encryption scheme?
> >
> > Oh, it could also be that there are frames missing in the tcp-stream.
> > That means the ssl-dissector can't reassemble it's stream properly
> > and that creates a "malformed" packet. You can check this by
> > disabling the "Allow subdissector to reassemble TCP streams"
> > option in the tcp protocol preferences. The "malformed" message
> > will then disappear.
> >
>
> [Small, James] Sake, when I do that, these "SSL" frames no longer show
> up as malformed, instead they show up as unreassembled:
That's exactly what I was aiming at...
> I guess I'm not sure if that's an error or not. I was capturing from
> the client, but does that mean that a reply from the server might have
> gotten lost and caused this problem? But if that were the case, I
> should see a missing sequence number or retransmission in the stream
> which I don't.
Are you sure you see all packets of the tcp-session? Sometimes you
do not see a retransmission because the endpoints did get all the
data, but the capturing system did not (I have seen SPAN-ports
drop 0,1% of packets, even on expensive hardware, I'm not sure
if they still drop packets, but you always have to be aware that
you might not see all the packets that were there).
> > > Could you file this as a bug on bugzilla with a sample trace
> > > (with the whole tcp-session if possible)?
> >
>
> [Small, James] No problem if there's something wrong - at this point I'm
> not sure.
I'm not sure either, is it possible for you to filter out this one
TCP-session and send it to the list (or me)?
Cheers,
Sake
