directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Created: (DIREVE-87) PDU sizes above 255 make JNDI clients hang
Date Fri, 26 Nov 2004 17:36:18 GMT
PDU sizes above 255 make JNDI clients hang

         Key: DIREVE-87
     Project: Directory Eve
        Type: Bug
  Components: protocol  
    Reporter: Alex Karasulu
 Assigned to: Alex Karasulu 
    Priority: Blocker

Oh I've been wrestling with this bug for some time now and thought it might be a good idea
to get a JIRA out on it.  This bug is basically in my way preventing me from really rapidly
finishing off the rest of the protocol provider that plugs into SEDA.  Here's a characterization
of the bug and how to reproduce it:

When the top level TLV tuple of an LDAP response message is 255 or smaller there is no problem
at all with transmission.  However when it is 256 bytes then transmission occurs without reciept
of attributes by SUN JNDI LDAP clients but nothing blocks.  At 257 bytes the transimission
is excellent with complete reciept of all attributes and no blocking.  At 258 bytes and above
all clients fail on receipt of the transmission and hang.  Here's a synopsis:

--> PDU's <= 255 bytes all is well
--> PDU's == 256 bytes we loose attributes but client does not hang
--> PDU's == 257 bytes all is well
--> PDU's >= 258 bytes we get nothing back and client hangs

I basically verified that the generated PDU by the server is being delivered correctly to
the client and that the client is recieving the PDU as it was transmitted.  I confirmed all
this using debugging on Eve, the client, and using Ethereal dumps of TCP streams.  So this
leads me to one conclusion at this point:

We are not generating the correct ASN.1 BER encoding for PDU's bigger than 255 bytes.  We're
getting lucky on transmissions at 256, and 257 bytes.   Anything larger than this is interfering
with the interpretation of the following search response done PDU that comes right after the
malformed search entry result PDU.  Hence this is what is causing the client to hang thinking
the search has not completed yet.  

I guess I got to get back into the ASN.1 stuff to fix this.  Stay tuned to this bat channel
for more updates to follow ...

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message