You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Jake <jn...@yahoo.com> on 2008/04/23 00:07:41 UTC
Embedded webapp shutdown issue
Hi, I am using ApacheDS 1.0.2 with Tomcat 5.5.20 and followed your embedded webapp example. Everything works great except for the server shutdown. ApacheDS appears to shutdown correctly with the following lines:
INFO: [org.apache.directory.server.jndi.ServerContextFactory] - Unbind of an LDAP service (10389) is complete.
INFO: [org.apache.directory.server.jndi.ServerContextFactory] - Sending notice of disconnect to existing clients sessions.
However, Tomcat doesn't completely shutdown. It appears there are a few non-daemon threads that are not being shutdown by ApacheDS causing Tomcat to not shutdown completely.
"pool-3-thread-1" prio=6 tid=0x0ae50c68 nid=0x898 in Object.wait() [0x0c3cf000..0x0c3cfa68] at java.lang.Object.wait(Native Method) - waiting on <0x0327ba80> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316) - locked <0x0327ba80> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:493) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:689) at java.lang.Thread.run(Thread.java:595)
Any ideas on how to get these threads to shutdown as well?
thanks
Jake
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: [SOLVED]Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Steve <ha...@yahoo.com>.
Done
See
https://issues.apache.org/jira/browse/DIRSERVER-1168
and
https://issues.apache.org/jira/browse/DIRSERVER-1164
Regards
--- Alex Karasulu <ak...@apache.org> wrote:
> I'm deep in some auth delegation code right now but can someone file an
> issue in JIRA for the bug Steve Hammond discovered. I'll get to that next
> week.
>
> Alex
>
> On Thu, Apr 24, 2008 at 11:30 AM, Emmanuel Lecharny <el...@apache.org>
> wrote:
>
> > Harakiri wrote:
> >
> >> --- Emmanuel Lecharny <el...@apache.org> wrote:
> >>
> >>
> >>> What would be very cool is to send us a quick report
> >>> or 'howto' which can be added to our wiki. This could be very
> >>> helpfull for the few person who are using Outlook (500 hundred millions ?
> >>> ;)
> >>>
> >>>
> >>
> >> The Standard Apache 1.5.2 distribution should work out
> >> of the box with Outlook Clients for using LDAPS - the
> >> only catch is the SSL certificate which is
> >> automatically generated by apacheDS - it is neither
> >> trusted by outlook - nor does it contain a valid
> >> common name (the DNS name of the server).
> >>
> >>
> > 1.5.2 works out of the box, assuming you set you own certificate. With the
> > self-generated certificate, we will check the code to see how to set a
> > correct certificate with the server name into it.
> >
> > I haven't worked on this part of the code, so I can't guarantee that is
> > something we will do. Alex will certainly validate this approach (or
> > invalidating it).
> >
> > May I suggest you fill a JIRA in order to get this issue treated and not
> > drawn in thousands of mails ?
> >
> >
> > Thanks !
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel Lécharny
> > www.iktek.com
> > directory.apache.org
> >
> >
> >
>
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [SOLVED]Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Alex Karasulu <ak...@apache.org>.
I'm deep in some auth delegation code right now but can someone file an
issue in JIRA for the bug Steve Hammond discovered. I'll get to that next
week.
Alex
On Thu, Apr 24, 2008 at 11:30 AM, Emmanuel Lecharny <el...@apache.org>
wrote:
> Harakiri wrote:
>
>> --- Emmanuel Lecharny <el...@apache.org> wrote:
>>
>>
>>> What would be very cool is to send us a quick report
>>> or 'howto' which can be added to our wiki. This could be very
>>> helpfull for the few person who are using Outlook (500 hundred millions ?
>>> ;)
>>>
>>>
>>
>> The Standard Apache 1.5.2 distribution should work out
>> of the box with Outlook Clients for using LDAPS - the
>> only catch is the SSL certificate which is
>> automatically generated by apacheDS - it is neither
>> trusted by outlook - nor does it contain a valid
>> common name (the DNS name of the server).
>>
>>
> 1.5.2 works out of the box, assuming you set you own certificate. With the
> self-generated certificate, we will check the code to see how to set a
> correct certificate with the server name into it.
>
> I haven't worked on this part of the code, so I can't guarantee that is
> something we will do. Alex will certainly validate this approach (or
> invalidating it).
>
> May I suggest you fill a JIRA in order to get this issue treated and not
> drawn in thousands of mails ?
>
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [SOLVED]Re: ApacheDS 1.52 Bad transition from state START_STATE,
tag 0x80
Posted by Emmanuel Lecharny <el...@apache.org>.
Harakiri wrote:
> --- Emmanuel Lecharny <el...@apache.org> wrote:
>
>> What would be very cool is to send us a quick report
>> or 'howto' which
>> can be added to our wiki. This could be very
>> helpfull for the few person
>> who are using Outlook (500 hundred millions ? ;)
>>
>
> The Standard Apache 1.5.2 distribution should work out
> of the box with Outlook Clients for using LDAPS - the
> only catch is the SSL certificate which is
> automatically generated by apacheDS - it is neither
> trusted by outlook - nor does it contain a valid
> common name (the DNS name of the server).
>
1.5.2 works out of the box, assuming you set you own certificate. With
the self-generated certificate, we will check the code to see how to set
a correct certificate with the server name into it.
I haven't worked on this part of the code, so I can't guarantee that is
something we will do. Alex will certainly validate this approach (or
invalidating it).
May I suggest you fill a JIRA in order to get this issue treated and not
drawn in thousands of mails ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [SOLVED]Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Harakiri <ha...@yahoo.com>.
--- Emmanuel Lecharny <el...@apache.org> wrote:
> What would be very cool is to send us a quick report
> or 'howto' which
> can be added to our wiki. This could be very
> helpfull for the few person
> who are using Outlook (500 hundred millions ? ;)
The Standard Apache 1.5.2 distribution should work out
of the box with Outlook Clients for using LDAPS - the
only catch is the SSL certificate which is
automatically generated by apacheDS - it is neither
trusted by outlook - nor does it contain a valid
common name (the DNS name of the server).
To resolve this issue - the code i posted in the last
message is enough to get it to work - i.e.
administrators have to install a trusted ssl
certificate with a valid hostname they are connecting
to from their outlook clients -
>
> Regarding the code, I would let Alex validate it.
The code works - i have installed my own SSL
certificate that way - just wanted to know if there is
an utility method like there was in 1.5.1.
The only minor issue now still left from 1.5.1 is the
unbind exception for certain ldap clients (Outlook
again) when you do a search.
ERROR - failed to unbind session properly
org.apache.directory.shared.ldap.exception.LdapNameNotFoundException:
at
org.apache.directory.server.core.partition.DefaultPartitionNexus.getPartition(DefaultPartitionNexus.java:1153)
Its not an issue at all, just a bit ugly in the logs
=)
Thanks
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [SOLVED]Re: ApacheDS 1.52 Bad transition from state START_STATE,
tag 0x80
Posted by Emmanuel Lecharny <el...@apache.org>.
Harakiri wrote:
> --- Emmanuel Lecharny <el...@apache.org> wrote:
>
>
>> Seems to be a known problem with Outlook :
>>
>>
> http://www.openldap.org/lists/openldap-software/200204/msg00723.html
>
> Well what do you know - the second issue is also a
> quirk in Outlook (any version) - the problem was -
> that the SSL certificate has to match the hostname
> exactly - if it is empty or you do not connect using
> the DNS name - outlook will simply refuse the
> connection even if the cert itself is trusted.
> Great - so what i did for testing was just edit my
> hosts file and point the IP of the apacheDS to the
> "right" DNS name.
>
Great !
What would be very cool is to send us a quick report or 'howto' which
can be added to our wiki. This could be very helpfull for the few person
who are using Outlook (500 hundred millions ? ;)
> BTW: In the 1.5.2 API i didnt found an easy way to
> change the SSL Certificate (previously a
> setCertificateFile etc existed) - so i did the
> following - is this the intended way currently?
>
The 1.5.2 version brings a very interesting feature : the server can
self build a certificate, instead on depending on an admin to generate a
certificate, sign it, store it in a keystore... Now, the firt time you
try to connect to the server using LDAPS, if the server does not have a
certificate, it will generate one, stores it into the DIT, and use it to
establish the connexion. If needed, you can still setup your own
certificate (for instance, if you bought one)
Of course, this is not yet doccumented ;)
Regarding the code, I would let Alex validate it.
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
[SOLVED]Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Harakiri <ha...@yahoo.com>.
--- Emmanuel Lecharny <el...@apache.org> wrote:
> Seems to be a known problem with Outlook :
>
http://www.openldap.org/lists/openldap-software/200204/msg00723.html
Well what do you know - the second issue is also a
quirk in Outlook (any version) - the problem was -
that the SSL certificate has to match the hostname
exactly - if it is empty or you do not connect using
the DNS name - outlook will simply refuse the
connection even if the cert itself is trusted.
Great - so what i did for testing was just edit my
hosts file and point the IP of the apacheDS to the
"right" DNS name.
BTW: In the 1.5.2 API i didnt found an easy way to
change the SSL Certificate (previously a
setCertificateFile etc existed) - so i did the
following - is this the intended way currently?
In essence i modify the admin attribute always at
server startup :
EntryOperationContext adminEntry = new
EntryOperationContext(
directoryService.getRegistries(),
PartitionNexus.getAdminName());
KeyStore store = ...
KeyPair keyPair = ...
Attributes entry = new BasicAttributes();
PrivateKey privateKey = keyPair.getPrivate();
entry.put(TlsKeyGenerator.KEY_ALGORITHM_AT,
privateKey
.getAlgorithm());
entry.put(TlsKeyGenerator.PRIVATE_KEY_AT,
privateKey.getEncoded());
entry.put(TlsKeyGenerator.PRIVATE_KEY_FORMAT_AT,
privateKey
.getFormat());
PublicKey publicKey = keyPair.getPublic();
entry.put(TlsKeyGenerator.PUBLIC_KEY_AT,
publicKey.getEncoded());
entry.put(TlsKeyGenerator.PUBLIC_KEY_FORMAT_AT,
publicKey
.getFormat());
Certificate cert = store.getCertificate(alias);
entry.put(TlsKeyGenerator.USER_CERTIFICATE_AT,
cert.getEncoded());
List<Modification> items =
ModifyOperationContext.createModItems(
ServerEntryUtils.toServerEntry(entry,
PartitionNexus
.getAdminName(),
directoryService.getRegistries()),
ModificationOperation.REPLACE_ATTRIBUTE);
directoryService.getPartitionNexus().modify(
new ModifyOperationContext(
directoryService.getRegistries(),
PartitionNexus
.getAdminName(), items));
Thanks
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Emmanuel Lecharny <el...@apache.org>.
Harakiri wrote:
> Hi,
>
> Im not quiet sure if i have done this for StartTLS
> right :
>
> ldapServer.setEnableLdaps(false)
> ldapServer.addExtendedOperationHandler(new
> StartTlsHandler());
> ldapServer.start();
>
> this should do the trick for TLS?
>
Alex ?
> It doesnt start any SSL LDAP for me - only normal LDAP
> on port 389 - what am i missing?
>
Plain normal. StartTLS use LDAP instead of opening a SSL connection, but
then encrypt all the forthcoming communication. So you will have a safe
en encrypted communication on 10389 if this is the LDAP port you use.
> Thanks
>
>
>
>
> ____________________________________________________________________________________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Alex Karasulu <ak...@apache.org>.
Yep Steve is right here the addExtendedOperationHandler() call is not
working. Somethign we have to fix.
Alex
On Thu, Apr 24, 2008 at 12:03 PM, Hammond, Steve <st...@polycom.com>
wrote:
> That is not quite right, but I think it is due to a bug.
> This code does work to startTLS
>
> Collection<ExtendedOperationHandler> handlers =
> new ArrayList<ExtendedOperationHandler>();
> handlers.add(new StartTlsHandler());
> ldapServer.setExtendedOperationHandlers(handlers);
>
> -----Original Message-----
> From: Harakiri [mailto:harakiri_23@yahoo.com]
> Sent: Thursday, April 24, 2008 7:59 AM
> To: users@directory.apache.org; elecharny@apache.org
> Subject: Re: ApacheDS 1.52 Bad transition from state START_STATE, tag
> 0x80
>
> Hi,
>
> --- Emmanuel Lecharny <el...@apache.org> wrote:
> > Another option would be to use StartTLS instead of
> > Ldaps. It's much
> > better, as you don't have to open 2 different port
> > (389 for LDAP and 636
> > for LDAPS). Can you give it a try ?
>
> Im not quiet sure if i have done this for StartTLS
> right :
>
> ldapServer.setEnableLdaps(false)
> ldapServer.addExtendedOperationHandler(new
> StartTlsHandler());
> ldapServer.start();
>
> this should do the trick for TLS?
>
> It doesnt start any SSL LDAP for me - only normal LDAP
> on port 389 - what am i missing?
>
> Thanks
>
>
>
>
>
> ________________________________________________________________________
> ____________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now.
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
RE: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by "Hammond, Steve" <st...@Polycom.com>.
That is not quite right, but I think it is due to a bug.
This code does work to startTLS
Collection<ExtendedOperationHandler> handlers =
new ArrayList<ExtendedOperationHandler>();
handlers.add(new StartTlsHandler());
ldapServer.setExtendedOperationHandlers(handlers);
-----Original Message-----
From: Harakiri [mailto:harakiri_23@yahoo.com]
Sent: Thursday, April 24, 2008 7:59 AM
To: users@directory.apache.org; elecharny@apache.org
Subject: Re: ApacheDS 1.52 Bad transition from state START_STATE, tag
0x80
Hi,
--- Emmanuel Lecharny <el...@apache.org> wrote:
> Another option would be to use StartTLS instead of
> Ldaps. It's much
> better, as you don't have to open 2 different port
> (389 for LDAP and 636
> for LDAPS). Can you give it a try ?
Im not quiet sure if i have done this for StartTLS
right :
ldapServer.setEnableLdaps(false)
ldapServer.addExtendedOperationHandler(new
StartTlsHandler());
ldapServer.start();
this should do the trick for TLS?
It doesnt start any SSL LDAP for me - only normal LDAP
on port 389 - what am i missing?
Thanks
________________________________________________________________________
____________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Harakiri <ha...@yahoo.com>.
Hi,
--- Emmanuel Lecharny <el...@apache.org> wrote:
> Another option would be to use StartTLS instead of
> Ldaps. It's much
> better, as you don't have to open 2 different port
> (389 for LDAP and 636
> for LDAPS). Can you give it a try ?
Im not quiet sure if i have done this for StartTLS
right :
ldapServer.setEnableLdaps(false)
ldapServer.addExtendedOperationHandler(new
StartTlsHandler());
ldapServer.start();
this should do the trick for TLS?
It doesnt start any SSL LDAP for me - only normal LDAP
on port 389 - what am i missing?
Thanks
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Emmanuel Lecharny <el...@apache.org>.
Harakiri wrote:
> Hello,
>
>
>> Sorry, I don't have any W$ computer, so 'default
>> settings' for outlook
>> does not help me a lot :)
>>
>
> well my first issue has been resolved - it is a bug or
> feature in all outlook clients it seems.
>
Ahhh... Thanks, M$ ;)
> LDAP works for outlook clients and ApacheDS 1.5.2 as
> long as you do not use the port 636 for LDAP - because
> i was being lazy i always switched on/off SSL and let
> the port stay remain (636) - in outlook you can
> specify any port you want for LDAP - however even tho
> you disable SSL in outlook and start a normal LDAP
> service at port 636 - outlook will always use SSL for
> port 636 no matter if you specified SSL or not in the
> outlook configuration
>
636 is a well known port, assigned to LDAPS. It's somehow normal that
OutLook use 636 in conjonction with LDAPS.
> In essence, any other port will work for LDAP in
> outlook except 636 - i believe they hardcoded 636
> internally to always use SSL.
That's for sure.
> 637,10389,389 etc work
> fine.
>
> So the tag 0x80 resulted because outlook connected
> using SSL to the apacheds - but apacheds was only
> running LDAP.
>
You can setup Apacheds to accept LDAP on port 636. With 1.5.2, you won't
even have to create a certificate, and install it, ADS is doing it for you.
> Next to my other original problem - SSL still does not
> work for outlook clients.
>
Seems to be a known problem with Outlook :
http://www.openldap.org/lists/openldap-software/200204/msg00723.html
If Thunderbird, LdapBrowser, Directory Studio works well with ADS 1.5.2
using LDAPS, I wouls suggest that the pb is not on the server side, but
on the client side.
Another option would be to use StartTLS instead of Ldaps. It's much
better, as you don't have to open 2 different port (389 for LDAP and 636
for LDAPS). Can you give it a try ?
Thanks !
> I enabled debug - here is a dump - it just stops :
>
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] doHandshake()
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] unwrapHandshake()
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] inNetBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=0 cap=16665]
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] appBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] Unwrap res:Status =
> BUFFER_UNDERFLOW HandshakeStatus = NEED_UNWRAP
> bytesConsumed = 0 bytesProduced = 0
> DEBUG: ExecutorFilter - Launching thread for
> /192.168.0.121:1199
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] Data Read:
> org.apache.mina.filter.support.SSLHandler@b6548
> (DirectBuffer[pos=0 lim=78 cap=1024: 80 4C 01 03 01 00
> 33 00 00 00 10 00 00 04 00 00 05 00 00 0A 01 00 80 07
> 00 C0 03 00 80 00 00 09 06 00 40 00 00 64 00 00 62 00
> 00 03 00 00 06 02 00 80 04 00 80 00 00 13 00 00 12 00
> 00 63 FB 98 B9 9A E5 3D AD 4E 7E 2E 71 05 41 90 67
> 9F])
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] doHandshake()
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] unwrapHandshake()
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] inNetBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=78 cap=16665]
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] appBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] Unwrap res:Status = OK
> HandshakeStatus = NEED_TASK
> bytesConsumed = 78 bytesProduced = 0
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] handshakeStatus=NEED_TASK
> 69572 [SocketAcceptor-0] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] doHandshake()
> 69572 [SocketAcceptor-0] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
> 69572 [SocketAcceptor-0] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] unwrapHandshake()
> 69572 [SocketAcceptor-0] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] inNetBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=0 cap=16665]
> 69572 [SocketAcceptor-0] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] appBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
> 69572 [SocketAcceptor-0] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] Unwrap res:Status =
> BUFFER_UNDERFLOW HandshakeStatus = NEED_UNWRAP
> bytesConsumed = 0 bytesProduced = 0
> 69572 [SocketAcceptorIoProcessor-0.0] DEBUG
> org.apache.mina.filter.executor.ExecutorFilter -
> Launching thread for /192.168.0.121:1199
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] Data Read:
> org.apache.mina.filter.support.SSLHandler@b6548
> (DirectBuffer[pos=0 lim=78 cap=1024: 80 4C 01 03 01 00
> 33 00 00 00 10 00 00 04 00 00 05 00 00 0A 01 00 80 07
> 00 C0 03 00 80 00 00 09 06 00 40 00 00 64 00 00 62 00
> 00 03 00 00 06 02 00 80 04 00 80 00 00 13 00 00 12 00
> 00 63 FB 98 B9 9A E5 3D AD 4E 7E 2E 71 05 41 90 67
> 9F])
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] doHandshake()
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] unwrapHandshake()
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] inNetBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=78 cap=16665]
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] appBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] Unwrap res:Status = OK
> HandshakeStatus = NEED_TASK
> bytesConsumed = 78 bytesProduced = 0
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] handshakeStatus=NEED_TASK
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] doTasks()
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] doTask:
> com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask@2db19d
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] doTasks(): NEED_WRAP
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] handshakeStatus=NEED_WRAP
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] Wrap res:Status = OK
> HandshakeStatus = NEED_UNWRAP
> bytesConsumed = 0 bytesProduced = 468
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] doTasks()
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] doTask:
> com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask@2db19d
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] doTasks(): NEED_WRAP
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] handshakeStatus=NEED_WRAP
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] Wrap res:Status = OK
> HandshakeStatus = NEED_UNWRAP
> bytesConsumed = 0 bytesProduced = 468
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] write outNetBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=468 cap=16665]
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] session write:
> DirectBuffer[pos=0 lim=468 cap=512: 16 03 01 01 CF 02
> 00 00 46 03 01 48 10 72 CE A1 6F 09 78 BB FE 18 4B F1
> D8 15 32 2B 48 55 68 38 D8 56 CD 45 81 8D 4E 91 A4 D4
> 24 20 48 10 72 CE E2 E6 1A CD 05 29 B3 6E 21 FD 61 C6
> D1 B6 DF E4 E3 43 49 C3 2F A1 11 C8 0D 41 0B ED 00 04
> 00 0B 00 01 7D 00 01 7A 00 01 77 30 82 01 73 30 82 01
> 1D 02 06 01 19 7F FF 69 61 30 0D 06 09 2A 86 48 86 F7
> 0D 01 01 05 05 00 30 42 31 0B 30 09 06 03 55 04 06 13
> 02 55 53 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31
> 12 30 10 06 03 55 04 0B 13 09 44 69 72 65 63 74 6F 72
> 79 31 11 30 0F 06 03 55 04 03 13 08 41 70 61 63 68 65
> 44 53 30 1E 17 0D 30 38 30 34 32 34 31 30 33 34 31 35
> 5A 17 0D 30 38 30 35 31 31 31 31 31 34 34 34 5A 30 42
> 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0C 30 0A 06
> 03 55 04 0A 13 03 41 53 46 31 12 30 10 06 03 55 04 0B
> 13 09 44 69 72 65 63 74 6F 72 79 31 11 30 0F 06 03 55
> 04 03 13 08 41 70 61 63 68 65 44 53 30 5C 30 0D 06 09
> 2A 86 48 86 F7 0D 01 01 01 05 00 03 4B 00 30 48 02 41
> 00 8F 37 A4 19 B5 D6 93 78 08 AA D7 DA BB EC F8 FC B3
> 17 EB C2 0C 2B C7 4C 60 76 5E 6D C6 9B A1 20 18 B2 60
> 0D ED 1C 9D 73 EC 98 8D B8 77 E1 84 DC 4B 6A 47 80 C6
> 21 8F 08 40 4A 3B 3F 4E BF AB 49 02 03 01 00 01 30 0D
> 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 41 00 36 91
> E6 30 E0 5F 70 1D 32 D1 30 8D F3 27 BA 6E 14 DC C7 DB
> 29 3B 91 20 97 DE 88 23 F2 2D 13 99 5C D2 16 B4 1B 7C
> FC FF 9E 40 38 0D 96 2F FC 76 3D 5D 15 26 EE 20 54 4B
> 88 30 3A F2 52 57 CC E0 0E 00 00 00]
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] Filtered Write:
> org.apache.mina.filter.support.SSLHandler@b6548
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] already encrypted:
> DirectBuffer[pos=0 lim=468 cap=512: 16 03 01 01 CF 02
> 00 00 46 03 01 48 10 72 CE A1 6F 09 78 BB FE 18 4B F1
> D8 15 32 2B 48 55 68 38 D8 56 CD 45 81 8D 4E 91 A4 D4
> 24 20 48 10 72 CE E2 E6 1A CD 05 29 B3 6E 21 FD 61 C6
> D1 B6 DF E4 E3 43 49 C3 2F A1 11 C8 0D 41 0B ED 00 04
> 00 0B 00 01 7D 00 01 7A 00 01 77 30 82 01 73 30 82 01
> 1D 02 06 01 19 7F FF 69 61 30 0D 06 09 2A 86 48 86 F7
> 0D 01 01 05 05 00 30 42 31 0B 30 09 06 03 55 04 06 13
> 02 55 53 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31
> 12 30 10 06 03 55 04 0B 13 09 44 69 72 65 63 74 6F 72
> 79 31 11 30 0F 06 03 55 04 03 13 08 41 70 61 63 68 65
> 44 53 30 1E 17 0D 30 38 30 34 32 34 31 30 33 34 31 35
> 5A 17 0D 30 38 30 35 31 31 31 31 31 34 34 34 5A 30 42
> 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0C 30 0A 06
> 03 55 04 0A 13 03 41 53 46 31 12 30 10 06 03 55 04 0B
> 13 09 44 69 72 65 63 74 6F 72 79 31 11 30 0F 06 03 55
> 04 03 13 08 41 70 61 63 68 65 44 53 30 5C 30 0D 06 09
> 2A 86 48 86 F7 0D 01 01 01 05 00 03 4B 00 30 48 02 41
> 00 8F 37 A4 19 B5 D6 93 78 08 AA D7 DA BB EC F8 FC B3
> 17 EB C2 0C 2B C7 4C 60 76 5E 6D C6 9B A1 20 18 B2 60
> 0D ED 1C 9D 73 EC 98 8D B8 77 E1 84 DC 4B 6A 47 80 C6
> 21 8F 08 40 4A 3B 3F 4E BF AB 49 02 03 01 00 01 30 0D
> 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 41 00 36 91
> E6 30 E0 5F 70 1D 32 D1 30 8D F3 27 BA 6E 14 DC C7 DB
> 29 3B 91 20 97 DE 88 23 F2 2D 13 99 5C D2 16 B4 1B 7C
> FC FF 9E 40 38 0D 96 2F FC 76 3D 5D 15 26 EE 20 54 4B
> 88 30 3A F2 52 57 CC E0 0E 00 00 00]
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] unwrapHandshake()
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] inNetBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=0 cap=16665]
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] appBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
> DEBUG: LdapServer$LdapProtocolHandler -
> [/192.168.0.121:1199] Unwrap res:Status =
> BUFFER_UNDERFLOW HandshakeStatus = NEED_UNWRAP
> bytesConsumed = 0 bytesProduced = 0
> DEBUG: ExecutorFilter - Launching thread for
> /192.168.0.121:1199
> DEBUG: ExecutorFilter - Exiting since queue is
> empty for /192.168.0.121:1199
> DEBUG: ExecutorFilter - Exiting since queue is
> empty for /192.168.0.121:1199
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] write outNetBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=468 cap=16665]
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] session write:
> DirectBuffer[pos=0 lim=468 cap=512: 16 03 01 01 CF 02
> 00 00 46 03 01 48 10 72 CE A1 6F 09 78 BB FE 18 4B F1
> D8 15 32 2B 48 55 68 38 D8 56 CD 45 81 8D 4E 91 A4 D4
> 24 20 48 10 72 CE E2 E6 1A CD 05 29 B3 6E 21 FD 61 C6
> D1 B6 DF E4 E3 43 49 C3 2F A1 11 C8 0D 41 0B ED 00 04
> 00 0B 00 01 7D 00 01 7A 00 01 77 30 82 01 73 30 82 01
> 1D 02 06 01 19 7F FF 69 61 30 0D 06 09 2A 86 48 86 F7
> 0D 01 01 05 05 00 30 42 31 0B 30 09 06 03 55 04 06 13
> 02 55 53 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31
> 12 30 10 06 03 55 04 0B 13 09 44 69 72 65 63 74 6F 72
> 79 31 11 30 0F 06 03 55 04 03 13 08 41 70 61 63 68 65
> 44 53 30 1E 17 0D 30 38 30 34 32 34 31 30 33 34 31 35
> 5A 17 0D 30 38 30 35 31 31 31 31 31 34 34 34 5A 30 42
> 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0C 30 0A 06
> 03 55 04 0A 13 03 41 53 46 31 12 30 10 06 03 55 04 0B
> 13 09 44 69 72 65 63 74 6F 72 79 31 11 30 0F 06 03 55
> 04 03 13 08 41 70 61 63 68 65 44 53 30 5C 30 0D 06 09
> 2A 86 48 86 F7 0D 01 01 01 05 00 03 4B 00 30 48 02 41
> 00 8F 37 A4 19 B5 D6 93 78 08 AA D7 DA BB EC F8 FC B3
> 17 EB C2 0C 2B C7 4C 60 76 5E 6D C6 9B A1 20 18 B2 60
> 0D ED 1C 9D 73 EC 98 8D B8 77 E1 84 DC 4B 6A 47 80 C6
> 21 8F 08 40 4A 3B 3F 4E BF AB 49 02 03 01 00 01 30 0D
> 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 41 00 36 91
> E6 30 E0 5F 70 1D 32 D1 30 8D F3 27 BA 6E 14 DC C7 DB
> 29 3B 91 20 97 DE 88 23 F2 2D 13 99 5C D2 16 B4 1B 7C
> FC FF 9E 40 38 0D 96 2F FC 76 3D 5D 15 26 EE 20 54 4B
> 88 30 3A F2 52 57 CC E0 0E 00 00 00]
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] Filtered Write:
> org.apache.mina.filter.support.SSLHandler@b6548
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] already encrypted:
> DirectBuffer[pos=0 lim=468 cap=512: 16 03 01 01 CF 02
> 00 00 46 03 01 48 10 72 CE A1 6F 09 78 BB FE 18 4B F1
> D8 15 32 2B 48 55 68 38 D8 56 CD 45 81 8D 4E 91 A4 D4
> 24 20 48 10 72 CE E2 E6 1A CD 05 29 B3 6E 21 FD 61 C6
> D1 B6 DF E4 E3 43 49 C3 2F A1 11 C8 0D 41 0B ED 00 04
> 00 0B 00 01 7D 00 01 7A 00 01 77 30 82 01 73 30 82 01
> 1D 02 06 01 19 7F FF 69 61 30 0D 06 09 2A 86 48 86 F7
> 0D 01 01 05 05 00 30 42 31 0B 30 09 06 03 55 04 06 13
> 02 55 53 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31
> 12 30 10 06 03 55 04 0B 13 09 44 69 72 65 63 74 6F 72
> 79 31 11 30 0F 06 03 55 04 03 13 08 41 70 61 63 68 65
> 44 53 30 1E 17 0D 30 38 30 34 32 34 31 30 33 34 31 35
> 5A 17 0D 30 38 30 35 31 31 31 31 31 34 34 34 5A 30 42
> 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0C 30 0A 06
> 03 55 04 0A 13 03 41 53 46 31 12 30 10 06 03 55 04 0B
> 13 09 44 69 72 65 63 74 6F 72 79 31 11 30 0F 06 03 55
> 04 03 13 08 41 70 61 63 68 65 44 53 30 5C 30 0D 06 09
> 2A 86 48 86 F7 0D 01 01 01 05 00 03 4B 00 30 48 02 41
> 00 8F 37 A4 19 B5 D6 93 78 08 AA D7 DA BB EC F8 FC B3
> 17 EB C2 0C 2B C7 4C 60 76 5E 6D C6 9B A1 20 18 B2 60
> 0D ED 1C 9D 73 EC 98 8D B8 77 E1 84 DC 4B 6A 47 80 C6
> 21 8F 08 40 4A 3B 3F 4E BF AB 49 02 03 01 00 01 30 0D
> 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 41 00 36 91
> E6 30 E0 5F 70 1D 32 D1 30 8D F3 27 BA 6E 14 DC C7 DB
> 29 3B 91 20 97 DE 88 23 F2 2D 13 99 5C D2 16 B4 1B 7C
> FC FF 9E 40 38 0D 96 2F FC 76 3D 5D 15 26 EE 20 54 4B
> 88 30 3A F2 52 57 CC E0 0E 00 00 00]
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] unwrapHandshake()
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] inNetBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=0 cap=16665]
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] appBuffer:
> java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
> 69572 [pool-4-thread-7] DEBUG
> org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
> - [/192.168.0.121:1199] Unwrap res:Status =
> BUFFER_UNDERFLOW HandshakeStatus = NEED_UNWRAP
> bytesConsumed = 0 bytesProduced = 0
> 69572 [SocketAcceptorIoProcessor-0.0] DEBUG
> org.apache.mina.filter.executor.ExecutorFilter -
> Launching thread for /192.168.0.121:1199
> 69587 [pool-4-thread-7] DEBUG
> org.apache.mina.filter.executor.ExecutorFilter -
> Exiting since queue is empty for /192.168.0.121:1199
> 69587 [pool-4-thread-8] DEBUG
> org.apache.mina.filter.executor.ExecutorFilter -
> Exiting since queue is empty for /192.168.0.121:1199
>
> Outlook Express settings is :
> Use SSL, Search Timeout 1min, Max Results 100, No
> search base which are all default setting.
>
> The server works fine in SSL mode with Thunderbird and
> LDAPBrowser as i said.
>
> A wireshark capturing seems useless for SSL - because
> it is encryped - the handshake is done afaik.
>
> Any ideas?
>
>
> Thanks for your time
>
>
> ____________________________________________________________________________________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Harakiri <ha...@yahoo.com>.
Hello,
> Sorry, I don't have any W$ computer, so 'default
> settings' for outlook
> does not help me a lot :)
well my first issue has been resolved - it is a bug or
feature in all outlook clients it seems.
LDAP works for outlook clients and ApacheDS 1.5.2 as
long as you do not use the port 636 for LDAP - because
i was being lazy i always switched on/off SSL and let
the port stay remain (636) - in outlook you can
specify any port you want for LDAP - however even tho
you disable SSL in outlook and start a normal LDAP
service at port 636 - outlook will always use SSL for
port 636 no matter if you specified SSL or not in the
outlook configuration
In essence, any other port will work for LDAP in
outlook except 636 - i believe they hardcoded 636
internally to always use SSL. 637,10389,389 etc work
fine.
So the tag 0x80 resulted because outlook connected
using SSL to the apacheds - but apacheds was only
running LDAP.
Next to my other original problem - SSL still does not
work for outlook clients.
I enabled debug - here is a dump - it just stops :
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] doHandshake()
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] unwrapHandshake()
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] inNetBuffer:
java.nio.DirectByteBuffer[pos=0 lim=0 cap=16665]
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] appBuffer:
java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] Unwrap res:Status =
BUFFER_UNDERFLOW HandshakeStatus = NEED_UNWRAP
bytesConsumed = 0 bytesProduced = 0
DEBUG: ExecutorFilter - Launching thread for
/192.168.0.121:1199
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] Data Read:
org.apache.mina.filter.support.SSLHandler@b6548
(DirectBuffer[pos=0 lim=78 cap=1024: 80 4C 01 03 01 00
33 00 00 00 10 00 00 04 00 00 05 00 00 0A 01 00 80 07
00 C0 03 00 80 00 00 09 06 00 40 00 00 64 00 00 62 00
00 03 00 00 06 02 00 80 04 00 80 00 00 13 00 00 12 00
00 63 FB 98 B9 9A E5 3D AD 4E 7E 2E 71 05 41 90 67
9F])
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] doHandshake()
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] unwrapHandshake()
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] inNetBuffer:
java.nio.DirectByteBuffer[pos=0 lim=78 cap=16665]
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] appBuffer:
java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] Unwrap res:Status = OK
HandshakeStatus = NEED_TASK
bytesConsumed = 78 bytesProduced = 0
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] handshakeStatus=NEED_TASK
69572 [SocketAcceptor-0] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] doHandshake()
69572 [SocketAcceptor-0] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
69572 [SocketAcceptor-0] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] unwrapHandshake()
69572 [SocketAcceptor-0] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] inNetBuffer:
java.nio.DirectByteBuffer[pos=0 lim=0 cap=16665]
69572 [SocketAcceptor-0] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] appBuffer:
java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
69572 [SocketAcceptor-0] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] Unwrap res:Status =
BUFFER_UNDERFLOW HandshakeStatus = NEED_UNWRAP
bytesConsumed = 0 bytesProduced = 0
69572 [SocketAcceptorIoProcessor-0.0] DEBUG
org.apache.mina.filter.executor.ExecutorFilter -
Launching thread for /192.168.0.121:1199
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] Data Read:
org.apache.mina.filter.support.SSLHandler@b6548
(DirectBuffer[pos=0 lim=78 cap=1024: 80 4C 01 03 01 00
33 00 00 00 10 00 00 04 00 00 05 00 00 0A 01 00 80 07
00 C0 03 00 80 00 00 09 06 00 40 00 00 64 00 00 62 00
00 03 00 00 06 02 00 80 04 00 80 00 00 13 00 00 12 00
00 63 FB 98 B9 9A E5 3D AD 4E 7E 2E 71 05 41 90 67
9F])
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] doHandshake()
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] unwrapHandshake()
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] inNetBuffer:
java.nio.DirectByteBuffer[pos=0 lim=78 cap=16665]
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] appBuffer:
java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] Unwrap res:Status = OK
HandshakeStatus = NEED_TASK
bytesConsumed = 78 bytesProduced = 0
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] handshakeStatus=NEED_TASK
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] doTasks()
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] doTask:
com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask@2db19d
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] doTasks(): NEED_WRAP
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] handshakeStatus=NEED_WRAP
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] Wrap res:Status = OK
HandshakeStatus = NEED_UNWRAP
bytesConsumed = 0 bytesProduced = 468
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] doTasks()
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] doTask:
com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask@2db19d
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] doTasks(): NEED_WRAP
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] handshakeStatus=NEED_WRAP
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] Wrap res:Status = OK
HandshakeStatus = NEED_UNWRAP
bytesConsumed = 0 bytesProduced = 468
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] write outNetBuffer:
java.nio.DirectByteBuffer[pos=0 lim=468 cap=16665]
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] session write:
DirectBuffer[pos=0 lim=468 cap=512: 16 03 01 01 CF 02
00 00 46 03 01 48 10 72 CE A1 6F 09 78 BB FE 18 4B F1
D8 15 32 2B 48 55 68 38 D8 56 CD 45 81 8D 4E 91 A4 D4
24 20 48 10 72 CE E2 E6 1A CD 05 29 B3 6E 21 FD 61 C6
D1 B6 DF E4 E3 43 49 C3 2F A1 11 C8 0D 41 0B ED 00 04
00 0B 00 01 7D 00 01 7A 00 01 77 30 82 01 73 30 82 01
1D 02 06 01 19 7F FF 69 61 30 0D 06 09 2A 86 48 86 F7
0D 01 01 05 05 00 30 42 31 0B 30 09 06 03 55 04 06 13
02 55 53 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31
12 30 10 06 03 55 04 0B 13 09 44 69 72 65 63 74 6F 72
79 31 11 30 0F 06 03 55 04 03 13 08 41 70 61 63 68 65
44 53 30 1E 17 0D 30 38 30 34 32 34 31 30 33 34 31 35
5A 17 0D 30 38 30 35 31 31 31 31 31 34 34 34 5A 30 42
31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0C 30 0A 06
03 55 04 0A 13 03 41 53 46 31 12 30 10 06 03 55 04 0B
13 09 44 69 72 65 63 74 6F 72 79 31 11 30 0F 06 03 55
04 03 13 08 41 70 61 63 68 65 44 53 30 5C 30 0D 06 09
2A 86 48 86 F7 0D 01 01 01 05 00 03 4B 00 30 48 02 41
00 8F 37 A4 19 B5 D6 93 78 08 AA D7 DA BB EC F8 FC B3
17 EB C2 0C 2B C7 4C 60 76 5E 6D C6 9B A1 20 18 B2 60
0D ED 1C 9D 73 EC 98 8D B8 77 E1 84 DC 4B 6A 47 80 C6
21 8F 08 40 4A 3B 3F 4E BF AB 49 02 03 01 00 01 30 0D
06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 41 00 36 91
E6 30 E0 5F 70 1D 32 D1 30 8D F3 27 BA 6E 14 DC C7 DB
29 3B 91 20 97 DE 88 23 F2 2D 13 99 5C D2 16 B4 1B 7C
FC FF 9E 40 38 0D 96 2F FC 76 3D 5D 15 26 EE 20 54 4B
88 30 3A F2 52 57 CC E0 0E 00 00 00]
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] Filtered Write:
org.apache.mina.filter.support.SSLHandler@b6548
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] already encrypted:
DirectBuffer[pos=0 lim=468 cap=512: 16 03 01 01 CF 02
00 00 46 03 01 48 10 72 CE A1 6F 09 78 BB FE 18 4B F1
D8 15 32 2B 48 55 68 38 D8 56 CD 45 81 8D 4E 91 A4 D4
24 20 48 10 72 CE E2 E6 1A CD 05 29 B3 6E 21 FD 61 C6
D1 B6 DF E4 E3 43 49 C3 2F A1 11 C8 0D 41 0B ED 00 04
00 0B 00 01 7D 00 01 7A 00 01 77 30 82 01 73 30 82 01
1D 02 06 01 19 7F FF 69 61 30 0D 06 09 2A 86 48 86 F7
0D 01 01 05 05 00 30 42 31 0B 30 09 06 03 55 04 06 13
02 55 53 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31
12 30 10 06 03 55 04 0B 13 09 44 69 72 65 63 74 6F 72
79 31 11 30 0F 06 03 55 04 03 13 08 41 70 61 63 68 65
44 53 30 1E 17 0D 30 38 30 34 32 34 31 30 33 34 31 35
5A 17 0D 30 38 30 35 31 31 31 31 31 34 34 34 5A 30 42
31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0C 30 0A 06
03 55 04 0A 13 03 41 53 46 31 12 30 10 06 03 55 04 0B
13 09 44 69 72 65 63 74 6F 72 79 31 11 30 0F 06 03 55
04 03 13 08 41 70 61 63 68 65 44 53 30 5C 30 0D 06 09
2A 86 48 86 F7 0D 01 01 01 05 00 03 4B 00 30 48 02 41
00 8F 37 A4 19 B5 D6 93 78 08 AA D7 DA BB EC F8 FC B3
17 EB C2 0C 2B C7 4C 60 76 5E 6D C6 9B A1 20 18 B2 60
0D ED 1C 9D 73 EC 98 8D B8 77 E1 84 DC 4B 6A 47 80 C6
21 8F 08 40 4A 3B 3F 4E BF AB 49 02 03 01 00 01 30 0D
06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 41 00 36 91
E6 30 E0 5F 70 1D 32 D1 30 8D F3 27 BA 6E 14 DC C7 DB
29 3B 91 20 97 DE 88 23 F2 2D 13 99 5C D2 16 B4 1B 7C
FC FF 9E 40 38 0D 96 2F FC 76 3D 5D 15 26 EE 20 54 4B
88 30 3A F2 52 57 CC E0 0E 00 00 00]
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] unwrapHandshake()
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] inNetBuffer:
java.nio.DirectByteBuffer[pos=0 lim=0 cap=16665]
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] appBuffer:
java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
DEBUG: LdapServer$LdapProtocolHandler -
[/192.168.0.121:1199] Unwrap res:Status =
BUFFER_UNDERFLOW HandshakeStatus = NEED_UNWRAP
bytesConsumed = 0 bytesProduced = 0
DEBUG: ExecutorFilter - Launching thread for
/192.168.0.121:1199
DEBUG: ExecutorFilter - Exiting since queue is
empty for /192.168.0.121:1199
DEBUG: ExecutorFilter - Exiting since queue is
empty for /192.168.0.121:1199
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] write outNetBuffer:
java.nio.DirectByteBuffer[pos=0 lim=468 cap=16665]
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] session write:
DirectBuffer[pos=0 lim=468 cap=512: 16 03 01 01 CF 02
00 00 46 03 01 48 10 72 CE A1 6F 09 78 BB FE 18 4B F1
D8 15 32 2B 48 55 68 38 D8 56 CD 45 81 8D 4E 91 A4 D4
24 20 48 10 72 CE E2 E6 1A CD 05 29 B3 6E 21 FD 61 C6
D1 B6 DF E4 E3 43 49 C3 2F A1 11 C8 0D 41 0B ED 00 04
00 0B 00 01 7D 00 01 7A 00 01 77 30 82 01 73 30 82 01
1D 02 06 01 19 7F FF 69 61 30 0D 06 09 2A 86 48 86 F7
0D 01 01 05 05 00 30 42 31 0B 30 09 06 03 55 04 06 13
02 55 53 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31
12 30 10 06 03 55 04 0B 13 09 44 69 72 65 63 74 6F 72
79 31 11 30 0F 06 03 55 04 03 13 08 41 70 61 63 68 65
44 53 30 1E 17 0D 30 38 30 34 32 34 31 30 33 34 31 35
5A 17 0D 30 38 30 35 31 31 31 31 31 34 34 34 5A 30 42
31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0C 30 0A 06
03 55 04 0A 13 03 41 53 46 31 12 30 10 06 03 55 04 0B
13 09 44 69 72 65 63 74 6F 72 79 31 11 30 0F 06 03 55
04 03 13 08 41 70 61 63 68 65 44 53 30 5C 30 0D 06 09
2A 86 48 86 F7 0D 01 01 01 05 00 03 4B 00 30 48 02 41
00 8F 37 A4 19 B5 D6 93 78 08 AA D7 DA BB EC F8 FC B3
17 EB C2 0C 2B C7 4C 60 76 5E 6D C6 9B A1 20 18 B2 60
0D ED 1C 9D 73 EC 98 8D B8 77 E1 84 DC 4B 6A 47 80 C6
21 8F 08 40 4A 3B 3F 4E BF AB 49 02 03 01 00 01 30 0D
06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 41 00 36 91
E6 30 E0 5F 70 1D 32 D1 30 8D F3 27 BA 6E 14 DC C7 DB
29 3B 91 20 97 DE 88 23 F2 2D 13 99 5C D2 16 B4 1B 7C
FC FF 9E 40 38 0D 96 2F FC 76 3D 5D 15 26 EE 20 54 4B
88 30 3A F2 52 57 CC E0 0E 00 00 00]
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] Filtered Write:
org.apache.mina.filter.support.SSLHandler@b6548
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] already encrypted:
DirectBuffer[pos=0 lim=468 cap=512: 16 03 01 01 CF 02
00 00 46 03 01 48 10 72 CE A1 6F 09 78 BB FE 18 4B F1
D8 15 32 2B 48 55 68 38 D8 56 CD 45 81 8D 4E 91 A4 D4
24 20 48 10 72 CE E2 E6 1A CD 05 29 B3 6E 21 FD 61 C6
D1 B6 DF E4 E3 43 49 C3 2F A1 11 C8 0D 41 0B ED 00 04
00 0B 00 01 7D 00 01 7A 00 01 77 30 82 01 73 30 82 01
1D 02 06 01 19 7F FF 69 61 30 0D 06 09 2A 86 48 86 F7
0D 01 01 05 05 00 30 42 31 0B 30 09 06 03 55 04 06 13
02 55 53 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31
12 30 10 06 03 55 04 0B 13 09 44 69 72 65 63 74 6F 72
79 31 11 30 0F 06 03 55 04 03 13 08 41 70 61 63 68 65
44 53 30 1E 17 0D 30 38 30 34 32 34 31 30 33 34 31 35
5A 17 0D 30 38 30 35 31 31 31 31 31 34 34 34 5A 30 42
31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0C 30 0A 06
03 55 04 0A 13 03 41 53 46 31 12 30 10 06 03 55 04 0B
13 09 44 69 72 65 63 74 6F 72 79 31 11 30 0F 06 03 55
04 03 13 08 41 70 61 63 68 65 44 53 30 5C 30 0D 06 09
2A 86 48 86 F7 0D 01 01 01 05 00 03 4B 00 30 48 02 41
00 8F 37 A4 19 B5 D6 93 78 08 AA D7 DA BB EC F8 FC B3
17 EB C2 0C 2B C7 4C 60 76 5E 6D C6 9B A1 20 18 B2 60
0D ED 1C 9D 73 EC 98 8D B8 77 E1 84 DC 4B 6A 47 80 C6
21 8F 08 40 4A 3B 3F 4E BF AB 49 02 03 01 00 01 30 0D
06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 41 00 36 91
E6 30 E0 5F 70 1D 32 D1 30 8D F3 27 BA 6E 14 DC C7 DB
29 3B 91 20 97 DE 88 23 F2 2D 13 99 5C D2 16 B4 1B 7C
FC FF 9E 40 38 0D 96 2F FC 76 3D 5D 15 26 EE 20 54 4B
88 30 3A F2 52 57 CC E0 0E 00 00 00]
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] handshakeStatus=NEED_UNWRAP
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] unwrapHandshake()
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] inNetBuffer:
java.nio.DirectByteBuffer[pos=0 lim=0 cap=16665]
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] appBuffer:
java.nio.DirectByteBuffer[pos=0 lim=33330 cap=33330]
69572 [pool-4-thread-7] DEBUG
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler
- [/192.168.0.121:1199] Unwrap res:Status =
BUFFER_UNDERFLOW HandshakeStatus = NEED_UNWRAP
bytesConsumed = 0 bytesProduced = 0
69572 [SocketAcceptorIoProcessor-0.0] DEBUG
org.apache.mina.filter.executor.ExecutorFilter -
Launching thread for /192.168.0.121:1199
69587 [pool-4-thread-7] DEBUG
org.apache.mina.filter.executor.ExecutorFilter -
Exiting since queue is empty for /192.168.0.121:1199
69587 [pool-4-thread-8] DEBUG
org.apache.mina.filter.executor.ExecutorFilter -
Exiting since queue is empty for /192.168.0.121:1199
Outlook Express settings is :
Use SSL, Search Timeout 1min, Max Results 100, No
search base which are all default setting.
The server works fine in SSL mode with Thunderbird and
LDAPBrowser as i said.
A wireshark capturing seems useless for SSL - because
it is encryped - the handshake is done afaik.
Any ideas?
Thanks for your time
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Emmanuel Lecharny <el...@apache.org>.
>> Could you provide some more info, like the settings
>> you are using in
>> Outlook ?
>>
>
> All default settings - i didnt change anything - that
> is to say there isnt much to configure anyway except
> search depth maybe which i didnt touch ? but its
> always the defaults when you create a new directory -
> i tested with and without searchbase/dn.
>
Sorry, I don't have any W$ computer, so 'default settings' for outlook
does not help me a lot :)
Not a big deal though, see later...
> The embedded server im using is just starting the
> DefaultDirectoryService with no additional partitions
> - for my testing i only enable/disable LDAPS
>
> I have an interceptor which just prints out the search
> requests to console - and it doesnt even get there -
> the exception is thrown before any search is called.
>
> Maybe a tcpdump would help?
>
Sure !!!
If you can provide something I can read with wireshark, I will certainly
decypher what's going on on the protocol layer.
> Thanks
>
>
> ____________________________________________________________________________________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Harakiri <ha...@yahoo.com>.
Hello,
thanks for the reply -
--- Emmanuel Lecharny <el...@apache.org> wrote:
> The stack trace by itself don't tell a lot, except
> that a PDU can't be
> decoded. It would be good to have more logs (for
> instance, by setting
> the logs to DEBUG).
Im starting the server in embedded mode i.e without
spring framework - i did configure log4j to use debug
for all categories - but my console did not output
more messages - i guess i need to set some other log
framework for debug too - i try to get more messages
tomorrow
>
> A blind guess is that you are trying to use
> StartTLS, and there is a
> problem with the extended request.
No, i explicitly tested both cases - with and without
ssl active. If i have ldaps active - outlook never
receives a response from apacheds - there are also no
messages in the error console - except when i close
outlook i will see some unbind exceptions.
LDAPS also works fine for Thunderbird and
ldapbrowser..
Neither LDAP nor LDAPS work as i said in my
envirenment with Outlook clients
>
> Could you provide some more info, like the settings
> you are using in
> Outlook ?
All default settings - i didnt change anything - that
is to say there isnt much to configure anyway except
search depth maybe which i didnt touch ? but its
always the defaults when you create a new directory -
i tested with and without searchbase/dn.
The embedded server im using is just starting the
DefaultDirectoryService with no additional partitions
- for my testing i only enable/disable LDAPS
I have an interceptor which just prints out the search
requests to console - and it doesnt even get there -
the exception is thrown before any search is called.
Maybe a tcpdump would help?
Thanks
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi !
Harakiri wrote:
> With the new release 1.52, i've have been unsuccessful
> to connect any Outlook clients (express, 2000,2003) to
> the apacheds. Other clients like Thunderbird,
> LDAPBrowser or JNDI Clients work fine.
>
> Outlook Clients work fine however with the previous
> 1.51 release - i know that there has been a major
> refactoring for the new release.
>
Well, this part has not been touched, except if you consider the SSL
part of the server.
The stack trace by itself don't tell a lot, except that a PDU can't be
decoded. It would be good to have more logs (for instance, by setting
the logs to DEBUG).
A blind guess is that you are trying to use StartTLS, and there is a
problem with the extended request.
Could you provide some more info, like the settings you are using in
Outlook ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
ApacheDS 1.52 Bad transition from state START_STATE, tag 0x80
Posted by Harakiri <ha...@yahoo.com>.
With the new release 1.52, i've have been unsuccessful
to connect any Outlook clients (express, 2000,2003) to
the apacheds. Other clients like Thunderbird,
LDAPBrowser or JNDI Clients work fine.
Outlook Clients work fine however with the previous
1.51 release - i know that there has been a major
refactoring for the new release.
They cant search the server, the log always shows
23.04.2008 13:42:32
org.apache.directory.shared.asn1.ber.grammar.AbstractGrammar
executeAction
FATAL: Bad transition from state START_STATE, tag 0x80
23.04.2008 13:42:32 org.apache.mina.util.SessionLog
warn
WARN: [/127.0.0.1:1894] Unexpected exception from
exceptionCaught handler.
java.lang.NullPointerException: message
at
org.apache.mina.common.IoFilter$WriteRequest.<init>(IoFilter.java:329)
at
org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:177)
at
org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:168)
at
org.apache.directory.server.ldap.LdapServer$LdapProtocolHandler.exceptionCaught(LdapServer.java:1104)
at
org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.exceptionCaught(AbstractIoFilterChain.java:564)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextExceptionCaught(AbstractIoFilterChain.java:345)
at
org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:53)
at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.exceptionCaught(AbstractIoFilterChain.java:643)
at
org.apache.mina.common.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:75)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextExceptionCaught(AbstractIoFilterChain.java:345)
at
org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:53)
at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.exceptionCaught(AbstractIoFilterChain.java:643)
at
org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:224)
at
org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:264)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Thanks
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: Embedded webapp shutdown issue
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi,
this sounds like a bug in ADS. Not sure we already have a JIRA for it...
Do you really need to run on a 1.4 JVM ?
Jake wrote:
> Hi, I am using ApacheDS 1.0.2 with Tomcat 5.5.20 and followed your
> embedded webapp example. Everything works great except for the server
> shutdown. ApacheDS appears to shutdown correctly with the following
> lines:
>
> INFO: [org.apache.directory.server.jndi.ServerContextFactory] - Unbind
> of an LDAP service (10389) is complete.
> INFO: [org.apache.directory.server.jndi.ServerContextFactory] -
> Sending notice of disconnect to existing clients sessions.
>
> However, Tomcat doesn't completely shutdown. It appears there are a
> few non-daemon threads that are not being shutdown by ApacheDS causing
> Tomcat to not shutdown completely.
>
> "pool-3-thread-1" prio=6 tid=0x0ae50c68 nid=0x898 in Object.wait()
> [0x0c3cf000..0x0c3cfa68] at java.lang.Object.wait(Native Method) -
> waiting on <0x0327ba80> (a
> edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
> at java.lang.Object.wait(Object.java:474) at
> edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
> - locked <0x0327ba80> (a
> edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:493)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:689)
> at java.lang.Thread.run(Thread.java:595)
>
> Any ideas on how to get these threads to shutdown as well?
> thanks
> Jake
>
> ------------------------------------------------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
> it now.
> <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org