LengthFieldBasedFrameDecoder

[Marc-André Laverdière]

I had a similar problem because I wasn't using a PipelineFactory, so
the state was messed up.
Are you giving a custom PipelineFactory?

Marc-André LAVERDIÈRE
"Perseverance must finish its work so that you may be mature and
complete, not lacking anything." -James 1:4
mlaverd.theunixplace.com/blog

 /"\
 \ /    ASCII Ribbon Campaign
  X      against HTML e-mail
 / \



2010/7/6 mrochon <mattrochon at gmail.com>:
>
> 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.
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>