LengthFieldBasedFrameDecoder

[mrochon]

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?
-- 
View this message in context: http://netty-forums-and-mailing-lists.685743.n2.nabble.com/LengthFieldBasedFrameDecoder-tp5213848p5261046.html
Sent from the Netty User Group mailing list archive at Nabble.com.