(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #114587 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=114587 Imported into Bugzilla on 01/28/99 16:42) Linux/RedHat 5.0, 4.05: AddressBook Click on look-up-address icon Select 411 directory type in "mcafee" or other email Fails with this message: Unknown LDAP error (0xFFFFFFFF) Also fails with BigFoot, user reports it doesn't work with Digital Unix either.

I added Chuck to the cc list for this bug. Someone on the Communicator team should find out what LDAP SDK call (if any) is failing and what LDAP error code is generated. 0xFFFFFFFF (-1?) is not one we generate (unless that is a bug too).

One way I've seen Communicator generate -1 is to call ldap_result after the search has completed. As I said in email, I'm still interested in the rest of the error message. The dialog box says "Failed to <op> with LDAP error 'Unknown Error' (0xffffffff)", and the bug report leaves out the <op> part of the message.

Here you go: "Failed to bind to 'Four11 DIrectory' due to LDAP error 'Unknown error' (0xFFFFFFFF)". -Tao

According to Dora, this is a regression bug and can be fixed in ns/netsite/ldap/libraries/libldap. Just look for special treatment for Linux and make sure patches apply to both Linux 1_2 & 2_0. I am reassigning this bug to cboatwri. Let Dora or me know if you need any help. Thanks, Tao

Adding to cc: list. This is still being reported on 4.5. I get this error about 25% of the time with my RH5.0 build, Sept. 17.

This bug still exists in 4.5 98280 But now things are worse than ever because LDAP is used so much more: This KILLS Roaming Profiles via LDAP. This KILLS all our cool LDAP addressing stuff in Messenger This KILLS most of the usefulness of the Address Book This bug has existed in its same incarnation since 4.0 Preview Release 1 back in Q1 1997. Is there anything that can be done? Don't make me beg!

clear old 4.05 tfv and add leger to cc: list.

On my laptop (RH5.0 with patches), I recently went from a 9/something build of 4.5 to the 10/9 build, and started seeing this problem for the first time. It fails 2-3 times in a row on the first recipient I type for a message, then succeeds for that recipient and subsequent recipients on the same message.

I don't know how this came back to me, Tao is Mr. AddressBook on Unix if it's not a backend issue.

Sorry, I made a mistake and re-assigned this. Giving back to original owner.

Folks, I am not at all familiar with the source code of Communicator, but let me say this: The problem is not confined to nor does it revolve around Address Book. It is a problem with everything LDAP on Linux. ldap:// URL's fail in exactly the same manner (when the don't crash Comm. altogether). And LDAP roaming produces the same errors and dies there as well. I can only speculate that there is some deeply fundamental LDAP code that is unreliable when compiled on Linux. Hope this helps. Thank you!

Moving to TFV 5.0 Would not fix for a maintenance release.

Correcting summary to be more general per jwm3's comments. Changing from: "AddressBook: LDAP search fails sporadically on Linux" to "ldap:// URL's fail sporadically on Linux"

I need to know if this bug needs to be transferred to bugzilla (open source database) since this bug is currently assigned to cboatwri who works in the server group (per Phonebook). Any opinions?

I think it is okay to transfer this to bugzilla. Chuck (cboatwri) is the mozilla.org owner for LDAP SDK. I am sure he knows about bugzilla. What happens to this bug if it is not transferred? Certainly we should fix this bug for SeaMonkey.

mcs - we want to get all 5.0 bugs into mozilla. One database to deal with. Especially helpful for queries, bug management.

mcs - we want to get all 5.0 bugs into mozilla. One database to deal with. Especially helpful for queries, bug management.

Make it so then! The LDAP SDK team (mainly Chuck right now, but also sometimes me and a few other people from server land) will use bugzilla. Chuck might already be using it for other publically reported LDAP SDK bugs; I am not sure (Chuck is on vacation right now).

Setting all current Open/Normal to M4.

Clearing "M" field since Directory product is not used for 5.0 specific project bug metrics and will mess up our queries on milestones.

Putting on the M6 radar.

If the LDAP SDK folks can fix this in the SDK for M6, that's cool, but it will probably be a couple more milestones before Seamonkey is integrated with the LDAP SDK. I seem to remember a similar bug being recently fixed for 4.6, so Chuck just has to move that code into mozilla/directory.

Putting on [PP] radar.

Chuck, are you able to work on this. seamonkey M6 is this week. if not lets move it out to the appropriate milestone.

I don't know why this is on the M6 list. LDAP in seamonkey is not imminent. Moving to M8.

m12

LDAP is not a B1 feature. I'll see your M12 and raise you M15 :-)

reassigning to mcs, the new directory owner.

Reassigning all open Directory / LDAP C SDK bugs to Michael.

There does not seem to be much progress on this bug. Assuming there is no fix for the M15 stability checkpoint, please push this to M16 asap.

clearing target milestone

This bug has not been touched for more than nine months. In most cases, that means it has "slipped through the net". Please could the owner take a moment to add a comment to the bug with current status, and/or close it. Thank you :-) Gerv

-> mcs

I suspect this was fixed by changes in the LDAP code, or in the way Mozilla uses it. Closing.

Actually, Mozilla doesn't yet suport ldap:// URLs per se. But the code base is quite different from that used by communicator, and additionally, this bug doesn't have any useful amount of detail. So I propose we leave it closed, and let new bugs be filed against Mozilla if necessary.

See bug 114097 for a way to handle ldap:// URLs externally in Mozilla 1.6+ on Unix.