javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

Smack Smack Dev
1

Hello,

I’‘m still having problems with the subj. I’'ve seen threads

http://www.jivesoftware.org/community/thread.jspa?threadID=19581

and

http://www.jivesoftware.org/community/thread.jspa?threadID=21354

and it looks like the problem isn’'t fixed yet.

Is there Jira issue regarding this?

My configuration:

Linux kir-pc 2.6.15-26-386 #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 i686 GNU/Linux

Wildfire 3.0.1

Smack-Dev (current SVN snapshot)

java “1.5.0_07”

Test Script:

=======================

private static void testManyAccounts() throws Exception {

for(int i = 0; i < 20; i ++) {

XMPPConnection connection = new XMPPConnection("kir-pc", 5222, "localhost");

final String username = "user" + i;

final String password = "pwd";

try {

connection.getAccountManager().createAccount(username, password);

connection.login(username, password);

connection.getAccountManager().deleteAccount();

} catch (Exception e) {

System.out.println("i = " + i);

throw e;

}

finally {

connection.close();

}

}

}

===============================

Script execution results:

javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

at com.sun.net.ssl.internal.ssl.InputRecord.handleUnknownRecord(InputRecord.java:525)

at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:355)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1041)

at org.jivesoftware.smack.XMPPConnection.proceedTLSReceived(XMPPConnection.java:1119)

at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:316)

at org.jivesoftware.smack.PacketReader.access$000(PacketReader.java:43)

at org.jivesoftware.smack.PacketReader$1.run(PacketReader.java:65)

No response from server.:

at org.jivesoftware.smack.AccountManager.getRegistrationInfo(AccountManager.java:325)

at org.jivesoftware.smack.AccountManager.getAccountAttributes(AccountManager.java:129)

at org.jivesoftware.smack.AccountManager.createAccount(AccountManager.java:200)

at jetbrains.communicator.jabber.test.testManyAccounts(test.java:98)

at jetbrains.communicator.jabber.test.main(test.java:88)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)

i = 0

Exception in thread "main" java.lang.IllegalStateException: Not connected to server.

at org.jivesoftware.smack.XMPPConnection.sendPacket(XMPPConnection.java:688)

at org.jivesoftware.smack.AccountManager.createAccount(AccountManager.java:232)

at org.jivesoftware.smack.AccountManager.createAccount(AccountManager.java:203)

at jetbrains.communicator.jabber.test.testManyAccounts(test.java:98)

at jetbrains.communicator.jabber.test.main(test.java:88)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)

Process finished with exit code 1

2

See http://www.jivesoftware.org/community/thread.jspa?threadID=19926&tstart=0

I made some patches to packetreader.java. They still have not been incorporated into the nightly build and the current packet reader.java is different so you may need to merge changes into latest copy.

I looked at the latest copy and the changes made will probably not fix the proble you are seeing.

Its a timing issue. I had a test case which proved the fix but longer have it. I saw your post earlier and was going to try and reassemble a test but have not had time.

I’'d also have to remember what I did. I vaguely remember inserting a delay somewhere in XMPPConnection, I believe, to make the problem appear every time regardless of system load.

Then applied “my fix” and could not get the problem to reoccur.

3

Thanks for the reply. Could you please test my script with your fix?

I tried to apply it to the latest sources, but I probably made something wrong, because my test script still fail.

Thanks,

KIR

4

20 isn’'t much of a test. I modified slightly (200!). A compileable example.

There were no exceptions. Code tested follows:

import org.jivesoftware.smack.XMPPConnection;

public class test

{

private static void testManyAccounts() throws Exception

{

for(int i = 0; i < 200; i ++)

{

XMPPConnection connection = new XMPPConnection(“sdooley”, 5322, “localhost”);

final String username = “user” + i;

final String password = “pwd”;

try

{

connection.getAccountManager().createAccount(username, password);

connection.login(username, password);

connection.getAccountManager().deleteAccount();

}

catch (Exception e)

{

System.out.println("i = " + i);

throw e;

}

finally

{

connection.close();

}

}

}

public static void main (String[] args)

{

try

{

test.testManyAccounts ();

}

catch (Exception e)

{

e.printStackTrace ();

}

}

}

5

Thanks!

Looks like I didn’'t get your changes exactly. Will have to examine them more carefully.

KIR

6

It all has to do with test environment also. There were actually at least 3 problems that would give you these symptons.

I reran the test with smack 2.21 release and teh smack 2.2.1 nightly build.

No exceptions.

My test env is Wildfire 3.0.1 and the test app running on the same machine (P4 2.4 Ghz)

Now I move the test app over to a (PII 400 Mhz), 10 Mbs LAN

Server is still on 2.4 GHz machine. I lower the priority of the server to Low. I run a virus scan on the same machine as the server.

Results:

Smack 2.2.1 almost immediate failure

Smack 2.2.1 nightly build 28 August - ditto

My modified smack which is 2.2 with an altered PacketReader and PacketWriter. The PacketWriter bug was fixed in 2.2.1 I believe. It had to do with the keep alive injecting a space into the TLS negotiation and mucking it up.

Worked 100 % of 3 tests

As much trouble as it is to reassemble my original test, which introduced a delay somewhere in XMPPConnection to prove the PacketReader problem, I suppose if I want an official release of Smack with a fixed PacketReader I will have to bite the bullet and merge my changes into Smack 2.2.1 nightly (some night) and repost.

But I’'ll have to find some extra time somewhere to do this so it may be a while.

skip

7

My trouble is that I use latest smack-dev branch (3.0 ?).

And it fails 100%

Today I’'ll try to find out the source of the problem.

Thanks for your comments!

8

I’'ve fixed the problem in smack-dev trunk. The diff file can be downloaded at http://www.idetalk.com/PacketReader.ssl.fix.diff

Message was edited by: maxkir

9

I was under the impression that your fix would end up in a nightlt build so I could test it. I guess not. The only way to duplicate it is to apply the diff you have a link too?

skip

10

Surely I don’'t have permissions to apply changes to smack-dev.

You can either apply patch via ‘‘patch’’ command or apply changes manually - they are pretty simple and resemble your fix in 2.2.

KIR

P.S. I told Matt about the fix but he hasn’'t answered yet.

11

Which nightly build did you apply to?

skip

12

I used not nightly build but sources from subversion trunk (yesterday ones).

KIR

null

13

Update on this issue?

14

I applied “maxkir” fix PacketReader.ssl.fix to the 9/11 nightly build this morning and reran the earlier test case.

200 users

Using 2 machines w/Wildfire 3.0.1 on one and test case on the other

Also ran the test on the same machine.

Test worked 100% of the time.

I confirm maxkir’'s fix as a viable way to correct the PacketReader problem.

A Smack developer needs to incorporate this fix (please) into a version of Smack and get it released.

This problem has been around for a long time (and similar problems (now fixed) with the same symptons).

This one needs to be officially put to rest. (Do I hear an amen?)

Thanks,

skip

15

Hey guys,

KIR’'s fix has been officially included. You can find it in the nightly build version.

Thanks,

– Gato

16

Thanks, will test

Amen!

17

Hmmmm, at first test wouldn’'t even compile!

Surprise! we’'re changing the API (Smack 3) so all your legacy XMPP code will no longer compile or run without modification.

At least in the simple test case it wasn’'t a big deal, hopefully in my application its not either.

Ran test 3 times after code modifications succeeded 100% of time.

So if you want this fix you will have to eventually upgrade your code to be Smack 3 compatible I suppose.

XMPPConnection close method disappears, without as much as

“close has been deprecated” in the documentation which is the reasonable thing to do with java libraries.

Granted the docs are probably auto generated.

Oh yeah and XMPPConnection no longer does the connection to the server you must call a connect method.

Probably some other stuff lurking in Smack 3 also.

skip

18

Hey Skip,

Sorry about that. Yesterday we checked in a lot of changes and refactoring work. As you noticed people will need to implement these 3 changes:

  1. Send the #connect() message before logging in. So after you have created a new connection you will manually need to connect it.

  2. XMPPConnection#close() was renamed to #disconnect(). It is now possible to reuse the same connection across reconnections.

  3. The ConnectionListener interface has 3 new events. Implementers of that interface will need to implement the 3 new events.

FYI, we are still discussing if #connect() / #disconnect() are going to be the final names. We may go back to #close instead of #disconnect() but in that case we would need to rename #connect to #open? Still thinking and discussing.

Regards,

– Gato

19

Any chance you can merge this fix into a 2.2.2 bugfix?

Ray

20

Hey Ray,

Smack 3.0 will require Java 1.5 or later version and the fix is using new concurrency classes provided in Java 1.5. Since previous versions of Smack may run with older versions of Java we are not planning to migrate the fix.

However, you may want to use a backport library that provides the same class that works with older versions of Java. You will need to include a new jar in your classpath and port the fix that only modifies a few lines of code. Let me know if you are planning to backport the fix and need more specific information.

Regards,

– Gato