Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Date: Sun, 24 Jul 2011 19:33:09 +0000 (UTC)
From: "Emmanuel Lecharny (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Message-ID: 
 <725434794.2354.1311535989824.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <883503278.2265.1311527414968.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DIRSERVER-1636) Obtaining Kerberos tickets via
 TCP leads to endless loop
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DIRSERVER-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070235#comment-13070235 ] 

Emmanuel Lecharny commented on DIRSERVER-1636:
----------------------------------------------

Ok, I think we overlooked the RFC 4120 :

"Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
   sent over the TCP stream is preceded by the length of the request as
   4 octets in network byte order.  The high bit of the length is
   reserved for future expansion and MUST currently be set to zero.  If
   a KDC that does not understand how to interpret a set high bit of the
   length encoding receives a request with the high order bit of the
   length set, it MUST return a KRB-ERROR message with the error
   KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream."

So we need to send those four extra bytes. Too bad :/

> Obtaining Kerberos tickets via TCP leads to endless loop
> --------------------------------------------------------
>
>                 Key: DIRSERVER-1636
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1636
>             Project: Directory ApacheDS
>          Issue Type: Bug
>            Reporter: Stefan Seelmann
>            Priority: Critical
>             Fix For: 2.0.0-M2
>
>
> When obtaining Kerberos tickets via *TCP* the server runs into an endless loop. The while loop in org.apache.directory.server.kerberos.protocol.KerberosDecoder.decode() never terminates.
> To reproduce I added a new test class "KerberosTcpITest" in kerberos-test module, just remove the @Ignore.
> Here is the stack: 
> Thread [NioProcessor-5] (Suspended (breakpoint at line 106 in KerberosDecoder))	
> 	KerberosDecoder.decode(IoSession, IoBuffer, ProtocolDecoderOutput) line: 106	
> 	ProtocolCodecFilter.messageReceived(IoFilter$NextFilter, IoSession, Object) line: 241	
> 	DefaultIoFilterChain.callNextMessageReceived(IoFilterChain$Entry, IoSession, Object) line: 434	
> 	DefaultIoFilterChain.access$1200(DefaultIoFilterChain, IoFilterChain$Entry, IoSession, Object) line: 46	
> 	DefaultIoFilterChain$EntryImpl$1.messageReceived(IoSession, Object) line: 796	
> 	DefaultIoFilterChain$HeadFilter(IoFilterAdapter).messageReceived(IoFilter$NextFilter, IoSession, Object) line: 119	
> 	DefaultIoFilterChain.callNextMessageReceived(IoFilterChain$Entry, IoSession, Object) line: 434	
> 	DefaultIoFilterChain.fireMessageReceived(Object) line: 426	
> 	NioProcessor(AbstractPollingIoProcessor<S>).read(S) line: 715	
> 	NioProcessor(AbstractPollingIoProcessor<S>).process(S) line: 668	
> 	NioProcessor(AbstractPollingIoProcessor<S>).process() line: 657	
> 	AbstractPollingIoProcessor<S>.access$600(AbstractPollingIoProcessor) line: 68	
> 	AbstractPollingIoProcessor$Processor.run() line: 1141	
> 	NamePreservingRunnable.run() line: 64	
> 	ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1110	
> 	ThreadPoolExecutor$Worker.run() line: 603	
> 	Thread.run() line: 679	

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira