I’m running the Netty 3.3.1 Secure Chat example out of the box and it is erroring out. It appears to be the Client that is having the problem–an error that reads “Client/Server mode not yet set.”
I read the documentation on SSLHandler that says, “If isIssueHandshake is false (default) you will need to take care of calling handshake by your own. In most situations were SslHandler is used in ‘client mode’ you want to issue a handshake once the connection was established. if setIssueHandshake is set to true you don’t need to worry about this as the SslHandler will take care of it. ”
I tried setting setIssueHandshake to true in the client before the sslHandler.handshake method was called, but that did not change/fix the error.
Any guesses?
Thank you for any assistance for this netty newbie!
This is the client output:
Mar 2, 2012 10:25:27 AM securechat.SecureChatClientHandler handleUpstream
INFO: [id: 0x00c2a132] OPEN
Mar 2, 2012 10:25:27 AM securechat.SecureChatClientHandler handleUpstream
INFO: [id: 0x00c2a132, /127.0.0.1:3082 => localhost/127.0.0.1:8443] BOUND: /127.0.0.1:3082
Mar 2, 2012 10:25:27 AM securechat.SecureChatClientHandler handleUpstream
INFO: [id: 0x00c2a132, /127.0.0.1:3082 => localhost/127.0.0.1:8443] CONNECTED: localhost/127.0.0.1:8443
Mar 2, 2012 10:25:27 AM securechat.SecureChatClientHandler exceptionCaught
WARNING: Unexpected exception from downstream.
java.lang.IllegalStateException: Client/Server mode not yet set.
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:609)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:667)
at org.jboss.netty.handler.ssl.SslHandler.handshake(SslHandler.java:358)
at securechat.SecureChatClientHandler.channelConnected(SecureChatClientHandler.java:54)
at securechat.SecureChatClientHandler.handleUpstream(SecureChatClientHandler.java:43)
at org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:61)
at org.jboss.netty.handler.ssl.SslHandler.channelConnected(SslHandler.java:1202)
at org.jboss.netty.channel.Channels.fireChannelConnected(Channels.java:227)
at org.jboss.netty.channel.socket.nio.NioWorker$RegisterTask.run(NioWorker.java:786)
at org.jboss.netty.channel.socket.nio.NioWorker.processRegisterTaskQueue(NioWorker.java:250)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:192)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
This is the server output:
INFO: [id: 0x01893efe, /127.0.0.1:3082 => /127.0.0.1:8443] OPEN
Mar 2, 2012 10:25:27 AM securechat.SecureChatServerHandler handleUpstream
INFO: [id: 0x01893efe, /127.0.0.1:3082 => /127.0.0.1:8443] BOUND: /127.0.0.1:8443
Mar 2, 2012 10:25:27 AM securechat.SecureChatServerHandler handleUpstream
INFO: [id: 0x01893efe, /127.0.0.1:3082 => /127.0.0.1:8443] CONNECTED: /127.0.0.1:3082
It’s a known bug in the example. If you take a look into
SecureChatClientPipelineFactory.java, you’ll see that the line that callsSSLEngine.setUseClientMode(true)has been commented out by mistake. Please uncomment it and then it will work. This issue has been fixed in 3.4.0.Alpha1.