client authentication with revoked cert results in server no response.
Trustin Lee
tlee at redhat.com
Sat Apr 11 02:39:05 EDT 2009
That's a great news! Please let me know it passes the further tests.
Cheers,
— Trustin Lee, http://gleamynode.net/
On Sat, Apr 11, 2009 at 5:56 AM, huican ping <pinghuican at gmail.com> wrote:
> Hello Trustin,
>
> Good news!
> It seems the lib from 1174 works well (I didn't do the further check
> yet, but seems fine).
> In the last email as I said that i got same result, it is not right,
> and I think I didn't replace the old lib with the new one since we
> have multiple places holding the jar files.
>
> Thanks
>
> On Fri, Apr 10, 2009 at 1:40 PM, Trustin Lee <tlee at redhat.com> wrote:
>> Unfortunately, it's 3 AM here and I'm going to bed. Take your time!
>>
>> If you have a chance to run a debugger, try to find out what state of
>> SSLEngine causes the infinite loop. It's open source anyway. :-)
>>
>> — Trustin Lee, http://gleamynode.net/
>>
>> On Sat, Apr 11, 2009 at 3:18 AM, Trustin Lee <tlee at redhat.com> wrote:
>>> I have made a small change to my fix so that unwrap can be called at
>>> least once. Rev # is 1174.
>>>
>>> I want to fix this problem asap, so please help me by responding asap. :-)
>>>
>>> — Trustin Lee, http://gleamynode.net/
>>>
>>>
>>>
>>> On Sat, Apr 11, 2009 at 2:37 AM, huican ping <pinghuican at gmail.com> wrote:
>>>> Hello Trustin,
>>>>
>>>> Also currently i have problem to generate a test code because lack of time.
>>>>
>>>> Try 1171.
>>>> Now CPU is low, but:
>>>> The message doesn't go down to to our http handler, e.g,
>>>> exceptionCaught() there not get called, probably no exception was
>>>> throw?. (initially, for first 4 client requests, I got ssh error
>>>> back).
>>>> Now nothing was replied to client, and the client is just stuck
>>>> waiting for reply back from server for ever.
>>>>
>>>>
>>>> Our pipeline:
>>>> =============
>>>> pipeline.addLast("SslEngine", new SslHandler(engine));
>>>> pipeline.addLast("decoder", new HttpRequestDecoder());
>>>> pipeline.addLast("encoder", new HttpResponseEncoder());
>>>> pipeline.addLast("handler", httpHandler);
>>>>
>>>>
>>>> For part of ssl dump:
>>>> =====================
>>>> ***
>>>> New I/O server worker #1-3, fatal error: 46: General SSLEngine problem
>>>> sun.security.validator.ValidatorException: PKIX path building failed:
>>>> sun.security.provider.certpath.SunCertP
>>>> xception: unable to find valid certification path to requested target
>>>> New I/O server worker #1-3, SEND TLSv1 ALERT: fatal, description =
>>>> certificate_unknown
>>>> New I/O server worker #1-3, WRITE: TLSv1 Alert, length = 2
>>>>
>>>>
>>>> I noticed the ssl handler breaks the unwrap method at this place at
>>>> its last time:
>>>> boolean inboundDone = engine.isInboundDone();
>>>> if (inboundDone) {
>>>> break;
>>>> }
>>>>
>>>>
>>>> On Fri, Apr 10, 2009 at 12:53 AM, Trustin Lee <tlee at redhat.com> wrote:
>>>>> I removed a sanity check code which might be causing this problem. Rev 1169.
>>>>>
>>>>> — Trustin Lee, http://gleamynode.net/
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 10, 2009 at 2:47 PM, Trustin Lee <tlee at redhat.com> wrote:
>>>>>> How's the CPU consumption? Is it normal now?
>>>>>>
>>>>>> It would be nice if you could provide me reproduceable code off the list.
>>>>>>
>>>>>> — Trustin Lee, http://gleamynode.net/
>>>>>>
>>>>>> On Fri, Apr 10, 2009 at 2:16 PM, huican ping <pinghuican at gmail.com> wrote:
>>>>>>> Hello Trustin,
>>>>>>>
>>>>>>> It seems not good.
>>>>>>>
>>>>>>> Now for the bad ssl handshake case, the client just stuck in waiting
>>>>>>> for the reply from server, but the server doesn't return anything
>>>>>>> after the handshake failed.
>>>>>>>
>>>>>>> For the normal case, it is still working.
>>>>>>>
>>>>>>> Not sure whether it is my setup problem here (but I don't think so).
>>>>>>>
>>>>>>> Huican
>>>>>>>
>>>>>>> On Thu, Apr 9, 2009 at 7:58 PM, Trustin Lee <tlee at redhat.com> wrote:
>>>>>>>> Hi Huican,
>>>>>>>>
>>>>>>>> Thanks for the detailed analysis. I checked in the potential fix for
>>>>>>>> this issue. Could you let me know if my fix works for you? Revision
>>>>>>>> # is 1163.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> — Trustin Lee, http://gleamynode.net/
>>>>>>>>
>>>>>>>> On Fri, Apr 10, 2009 at 9:00 AM, huican ping <pinghuican at gmail.com> wrote:
>>>>>>>>> Hello Trustin,
>>>>>>>>>
>>>>>>>>> Just steped through the code, and netty code FINALLY stuck in a loop
>>>>>>>>> in unwrap() with condition inNetBuf.hasRemaining()=true.
>>>>>>>>>
>>>>>>>>> private ChannelBuffer unwrap(
>>>>>>>>> // inside there is an infinite loop
>>>>>>>>> ...
>>>>>>>>> case NEED_UNWRAP:
>>>>>>>>> if (inNetBuf.hasRemaining()) {
>>>>>>>>> break;
>>>>>>>>> } else {
>>>>>>>>> break loop;
>>>>>>>>> }
>>>>>>>>> ....
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> More carefully, When the bad message comes in initially, it goes
>>>>>>>>> messageReceived(), some time later sshHandler.decode() goes into this
>>>>>>>>> unwrap() method. This time it goes out this inifite loop without
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> Because of handshake problem, after throwing SSLHandlshakeException, I
>>>>>>>>> close channel at exceptionCaught() in my httpHandler code. Some time
>>>>>>>>> later the netty code goes into closeOutboundAndChannel() method in
>>>>>>>>> SslHandler, it calls unwrap() method also. it did break out the
>>>>>>>>> infinite loop first time. Then evaluate engine.isInboundDone() is
>>>>>>>>> true, and it goes contenxt.sendDownstream(e).
>>>>>>>>>
>>>>>>>>> With this sendDownStream(e) call, the code goes into this unwrap()
>>>>>>>>> call again, and forever it stuck at the inNetBuf.hasRemaining() place.
>>>>>>>>>
>>>>>>>>> Hope this information is useful.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> huican
>>>>>>>>>
>>>>>>>>> On Thu, Apr 9, 2009 at 3:40 PM, huican ping <pinghuican at gmail.com> wrote:
>>>>>>>>>> This attachment is an un-collapsed yourkit stack for CPU usage.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Apr 9, 2009 at 1:38 PM, huican ping <pinghuican at gmail.com> wrote:
>>>>>>>>>>> Hey Trustin,
>>>>>>>>>>>
>>>>>>>>>>> From the exceptionCaught method, I saw it is a SSLHandshakeException
>>>>>>>>>>> for the failed input messages, I then close() the channel, such as:
>>>>>>>>>>> @Override
>>>>>>>>>>> public void exceptionCaught(ChannelHandlerContext ctx,
>>>>>>>>>>> ExceptionEvent e) throws Exception
>>>>>>>>>>> {
>>>>>>>>>>> // blabbla
>>>>>>>>>>> ctx.getChannel().close();
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> These several failed messages caused CPU 100% usage. (Sorry, I was
>>>>>>>>>>> wrong in my original statement, which I said it was low).
>>>>>>>>>>>
>>>>>>>>>>> The yourkit showed me that CPU used at
>>>>>>>>>>> org.jboxx.netty.channel.AbstraceChannel.close().
>>>>>>>>>>> The new threadDump is attached also. This threadDump matches to the 3.1.0.BETA.
>>>>>>>>>>>
>>>>>>>>>>> Thanks a lot.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Apr 9, 2009 at 11:44 AM, huican ping <pinghuican at gmail.com> wrote:
>>>>>>>>>>>> Hello Trustin,
>>>>>>>>>>>>
>>>>>>>>>>>> I am really Sorry, my bad.
>>>>>>>>>>>> Just checked, and Actually the CPU usage is very high after I sent in
>>>>>>>>>>>> 4 input messages. So it must stuck at some loop.
>>>>>>>>>>>> After several failed messages (actually, 1st failed one cause CPU jump
>>>>>>>>>>>> to 40%, 2nd failed CPU to 80%, 3rd CPU 90%), it always keeps at 90%
>>>>>>>>>>>> level even there is no more messages in, FYI, the system has no other
>>>>>>>>>>>> heavy CPU consuming process running.
>>>>>>>>>>>>
>>>>>>>>>>>> I tried your revision 1160, and it is same as before. So please
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> netty-users mailing list
>>>>>>>>> netty-users at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> netty-users mailing list
>>>>>>>> netty-users at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netty-users mailing list
>>>>>>> netty-users at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netty-users mailing list
>>>>> netty-users at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>>
>>>>
>>>> _______________________________________________
>>>> netty-users mailing list
>>>> netty-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>
>>>
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
More information about the netty-users
mailing list