On Thu, Apr 12, 2007 at 10:09:41PM +0200, Sake Blok wrote: > > Transmission Control Protocol, Src Port: 3128 (3128), Dst Port: 1136 > > (1136), Seq: 9184, Ack: 1341, Len: 1260 > > Hypertext Transfer Protocol > > Secure Socket Layer > > TLSv1 Record Layer: Application Data Protocol: http > > Content Type: Application Data (23) > > Version: TLS 1.0 (0x0301) > > Length: 1048 > > Encrypted Application Data: > > 986EF11CE4141826D529372C664768C27C0E749FFC4BB768... > > [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. > Could you file this as a bug on bugzilla with a sample trace > (with the whole tcp-session if possible)? Only if it is not a reassembly issue of course :) Cheers, Sake _______________________________________________ Wireshark-users mailing list [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-users
