Ok I found the problem, in the SSL debug log I saw; association_add TCP port 1364 protocol tls handle 00000000 association_add could not find handle for protocol 'tls', try to find 'data' dissector
Checking the SSL preferences I had an entry for RSA keys list; 127.0.0.1,1364,tls,c:\ssltest.key which specified this port so it was correctly attempting to dissect this packet as SSL after all. My follow-up question would be; Is it possible to follow the SSL stream when the SSL data is embedded in another protocol? This would be a very useful feature for what I'm working on. Regards .. Martin Martin Warnes wrote the following on 12/01/2007 16:27: > Hi, > > I'm developing a dissector plugin for the Connect:Direct file transfer > protocol, the protocol itself can contain a SSL payload. Until recently > i didn't have too many problems with my dissector identifying it's own > data, adding some information to the tree and then passing the SSL > payload off to the SSL dissector for subdissection. > > I updated the source today and now all the Connect:Direct protocol > packets are being identified as SSL continuation data, this occurs with > or without my dissector plugin loaded. > > Example for the packet below: > > > 0000 00 00 03 04 00 00 00 50 ba da b4 6c 00 00 08 00 .......P...l.... > 0010 45 00 00 51 0e 48 40 00 40 06 aa be c0 a8 00 28 [EMAIL > PROTECTED]@......( > 0020 c0 a8 00 28 05 54 86 0b 35 13 e0 4d 35 3a 86 3d ...(.T..5..M5:.= > 0030 80 18 20 00 81 e4 00 00 01 01 08 0a 09 53 d3 f3 .. ..........S.. > 0040 09 53 d3 f3 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2........ > 0050 80 00 00 00 38 00 00 00 16 03 01 00 04 0e 00 00 ....8........... > 0060 00 > > The Connect:Direct protocol contains a header that starts with "TCP2" > the length of the header is offset +6 (x10), there are 4 bytes of flag > data and then the payload data starts. > > 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2........ > 0050 80 00 00 00 38 00 00 00 16 03 01 00 04 0e 00 00 ....8........... > 0060 00 . > > In this case the payload is SSL data starting x'16 x'03 x'01 > > Has something changed in the SSL dissector that may caue this behaviour? > I looked at the SVN history and can't see anything obvious, but a quick > look through the SSL dissector code and I saw some routines called > "ssl_looks_like_". This seems to suggest that the SSL code does a > heuristic attempt to determine whether the packet contains SSL data, > which this does although it is not the only protocol in the packet. > > Is there a way to prevent this? > > I can work around the problem by using "decode as..", but that's not a > desirable solution. > > Regards .. Martin > > > > ---------------------------------------------------------- > Scanned by ClamAV antivirus system - http://www.clamav.net > Virus signatures last updated: Fri Jan 12 15:33:21 2007 > _______________________________________________ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > ��������������������������������������������jy�u�����U����2�צ�m���� > �rV�j��z�b��,� ڶ�V���]jם�Z�%���^����m4 > ---------------------------------------------------------- Scanned by ClamAV antivirus system - http://www.clamav.net Virus signatures last updated: Fri Jan 12 15:33:21 2007 _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
