LengthFieldBasedFrameDecoder

["이희승 (Trustin Lee)"]

Could you please post the full source code of the test so that I can
reproduce?

Thanks in advance,
Trustin

On 07/07/2010 12:50 AM, mrochon wrote:
> 
> Thanks Trustin,
> 
> I have another problem with LFBFD:
> 
> I have a simple unit test to test what happens when the client provides
> garbage data, the code is as follows:
> 
> [code]
>     @Test
>     @ExpectedException(SocketException.class)
>     public void testInvalidMessage() throws Throwable {
>         SSLSocket s = (SSLSocket)createSocket("localhost", 11225, true);
>         Assert.notNull(s);
> 
>         //write garbage until the server rejects this connection
>         while (s.isConnected()) {
>            
> s.getOutputStream().write("jkhdsbfjsahdflkabhfdskhasdklf".getBytes());
>         }
>     }
> [/code]
> 
> The error received is as follows:
> 
> pool-2-thread-19 WARN [impl.EndpointChannelHandler] - bad record MAC
> javax.net.ssl.SSLException: bad record MAC
> 	at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
> 	at
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1401)
> 	at
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1369)
> 	at
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:910)
> 	at
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:815)
> 	at
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:691)
> 	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:607)
> 	at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:757)
> 	at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:491)
> 	at
> org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:282)
> 	at
> org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216)
> 	at
> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:69)
> 	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)
> 
> Which is to be expected. The problem occurs on the next connection, the TLS
> handshake blocks indefinitely. Once I force close the client and an
> exception is raised on the server, I can connect again. The problem itself
> is intermittent and I ma having trouble accurately reproducing it, but I
> have 6 different test cases (some of which test fault tolerance and others
> test integration) and I can reproduce it on every test run.
> 
> A specific sequence of tests which always reproduces is as follows:
> 
> testInvalidMessage();
> testClientConnect();
> testClientConnectNoSSL();
> testInvalidMessage();
> testClientConnect2();
> testValidCapsMessage();
> testValidCapsInvalidAuthMessage();
> 
> (Obviously not a terribly useful sequence of tests, but I came across it
> while trying to find consistent reproduction)
> 
> Somtimes the test hangs right after the first InvalidMessage, sometimes
> right after the second, but if I remove the InvalidMessage Test it always
> makes it through. All of the tests use SSL except the one marked 'NoSSL'. As
> I am writing t his I am running it more and more, and sometimes the whole
> sequence passes as expected. I can't figure out what is going on here..
> 
> Is it possible that the LFBFD is failing on invalid data, but since the
> payload I actually sent is not the same size as was indicated int he invalid
> header, the next bytes are being interpreted as part of the SSL wrapper
> which is causing an ssl failure? At this point would the server not accept
> ssl connections until some other exception is raised?
> 
> Or do you think it is a timing issue/something wrong with my server
> implementation?

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100707/beeb43ec/attachment.bin