242487 - Addressing using LDAP does not display matches

Status: RESOLVED EXPIRED

(MailNews Core :: LDAP Integration, defect)

Description

[Nick Atkins]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040503 Firefox/0.8.0+
Build Identifier: version 0.6 (20040502)

Our company uses LDAP for company email address lookups and I have Thunderbird
configured to use the LDAP server, port 389.  However, when I try to address
people in the compose window either using the drop-down type-ahead thing or
using the address book sidebar no address matches are displayed.

Reproducible: Always
Steps to Reproduce:
1. Open address book and select LDAP as source
2. Enter part of a name that exists
3. 

Actual Results:  
No matches are returned

Expected Results:  
At least one match should be returned

Using Ethereal to snoop TCP port 389 I can see the LDAP request and response
containing matching addresses so I guess it's the display code that isn't using
the results.

Comment 1

[Scott MacGregor]

LDAP inline autocomplete is working fine for me in 0.6

Known issue that it doesn't work in the contacts sidebar (has it ever?)

Comment 2

[Nick Atkins]

You're right, inline autocomplete works (I was using the "Lebreeze" skin which
doesn't show a different icon for LDAP matches).  For me, here is the list of
what works and what doesn't:

- Inline autocomplete - works fine and as expected
- Address sidebar - does not work as expected.  However, if you do a search
(nothing appears) and then switch the drop-down list to "Personal Address Book"
and then switch back to the LDAP server, the matches will be displayed.  Weird!
- Address book - works fine and as expected
- Address book advanced search - does not work (and can't make it work).  None
of the query types seem to function at all.

Comment 3

[Scott MacGregor]

(In reply to comment #2)
> - Address sidebar - does not work as expected.  However, if you do a search
> (nothing appears) and then switch the drop-down list to "Personal Address Book"
> and then switch back to the LDAP server, the matches will be displayed.  
Weird!

Known Issue I couldn't find a fix for before we shipped. Don't know why togging
the directory back and forth makes it work though.


> - Address book advanced search - does not work (and can't make it work).  None
> of the query types seem to function at all.

This works for me. I just typed in a "Any name contains John" and I got back a
bunch of results containing the name John from a public LDAP directory.

Comment 4

[Nick Atkins]

>> - Address book advanced search - does not work (and can't make it work).  None
>> of the query types seem to function at all.

> This works for me. I just typed in a "Any name contains John" and I got back a
> bunch of results containing the name John from a public LDAP directory.

Not for me on Linux.  Ethereal tells me an LDAP request is going out on the wire
but I don't see any results come back.  Something is up with the query.  I
attach two traces to illustrate the difference between "simple" and "advanced"
LDAP.  

Comment 5

[Nick Atkins]

Attachment: Simple LDAP query for "dav" - hex dump

This is an LDAP query for "dav" using the simple address book search.  It works
and returns three matches

Comment 6

[Nick Atkins]

Attachment: Advanced LDAP search for "dav"

This is an LDAP search done from the "advanced" interface using "any/contains".
 It doesn't return any results.

Comment 7

[Scott MacGregor]

these are binary files. I can't read these (I'm on windows). Do you have a text
version of the log?

Comment 8

[Nick Atkins]

You should be able to open them with any hex editor.

Comment 9

[Ben Dugdale]

I am able to duplicate the bug in the advanced window and the side-bar trick.

My LDAP addresses are not found while I type in the address field.

The normal address book window seems to work okay.

I'm running Linux on an x86 Athlon

Here's my uname -a
Linux ben 2.6.5-gentoo #4 Sat Apr 24 09:17:22 UTC 2004 i686 AMD Athlon(tm) XP
1800+ AuthenticAMD GNU/Linux


My first search in the advanced address book works:

May  4 20:51:26 ben slapd[25565]: conn=83 fd=47 ACCEPT from IP=127.0.0.1:60097
(IP=0.0.0.0:389)
May  4 20:51:26 ben slapd[25574]: conn=83 op=0 BIND dn="" method=128
May  4 20:51:26 ben slapd[25574]: conn=83 op=0 RESULT tag=97 err=0 text=
May  4 20:51:26 ben slapd[25574]: get_filter: unknown filter type=48
May  4 20:51:26 ben slapd[25574]: get_filter: unknown filter type=48
May  4 20:51:26 ben slapd[25574]: conn=83 op=1 SRCH
base="ou=personal,dc=sheepcamp,dc=com" scope=2
filter="(|(cn=*i*)(givenName=*i*)(sn=*i*)(?=undefined)(?=undefined)(?=undefined)(?=undefined))"
May  4 20:51:26 ben slapd[25574]: conn=83 op=1 SRCH attr=modifytimestamp
xmozillausehtmlmail description notes custom4 custom3 custom2 custom1 birthyear
homeurl workurl nscpaimscreenname countryname company o departmentnumber
department orgunit ou title countryname zip postalcode region st locality l
streetaddress postofficebox carphone cellphone mobile pagerphone pager
facsimiletelephonenumber fax homephone telephonenumber xmozillasecondemail mail
xmozillanickname displayname commonname cn surname sn givenname
May  4 20:51:26 ben slapd[25574]: <= bdb_substring_candidates: (cn) index_param
failed (18)
May  4 20:51:26 ben slapd[25574]: <= bdb_substring_candidates: (givenName)
index_param failed (18)
May  4 20:51:26 ben slapd[25574]: <= bdb_substring_candidates: (sn) index_param
failed (18)
May  4 20:51:27 ben slapd[25574]: conn=83 op=1 SEARCH RESULT tag=101 err=0
nentries=75 text=

But subsequent searches do not..

May  4 20:49:04 ben slapd[25565]: conn=80 fd=44 ACCEPT from IP=127.0.0.1:60088
(IP=0.0.0.0:389)
May  4 20:49:04 ben slapd[25573]: conn=80 op=0 BIND dn="" method=128
May  4 20:49:04 ben slapd[25573]: conn=80 op=0 RESULT tag=97 err=0 text=
May  4 20:49:04 ben slapd[25573]: get_filter: unknown filter type=48
May  4 20:49:04 ben slapd[25573]: get_filter: unknown filter type=48
May  4 20:49:04 ben slapd[25573]: conn=80 op=1 SRCH
base="ou=personal,dc=sheepcamp,dc=com" scope=2
filter="(|(cn=*i*)(givenName=*i*)(sn=*i*)(?=undefined)(?=undefined)(?=undefined)(?=undefined))"
May  4 20:49:04 ben slapd[25573]: conn=80 op=1 SRCH attr=modifytimestamp
xmozillausehtmlmail description notes custom4 custom3 custom2 custom1 birthyear
homeurl workurl nscpaimscreenname countryname company o departmentnumber
department orgunit ou title countryname zip postalcode region st locality l
streetaddress postofficebox carphone cellphone mobile pagerphone pager
facsimiletelephonenumber fax homephone telephonenumber xmozillasecondemail mail
xmozillanickname displayname commonname cn surname sn givenname
May  4 20:49:04 ben slapd[25573]: <= bdb_substring_candidates: (cn) index_param
failed (18)
May  4 20:49:04 ben slapd[25573]: <= bdb_substring_candidates: (givenName)
index_param failed (18)
May  4 20:49:04 ben slapd[25573]: <= bdb_substring_candidates: (sn) index_param
failed (18)
May  4 20:49:04 ben slapd[25573]: conn=80 op=1 SEARCH RESULT tag=101 err=0
nentries=75 text=

One last trick, when the advanced address book does return results (about 100)
the scroll tab on the right does not work, but I can scroll with my mouse wheel.

Comment 10

[Nick Atkins]

This is fixed for me in my latest nightly trunk build of Thunderbird on Linux
(20040602).  However, a colleague using WinXP SP2 cannot get LDAP to work.  It's
distrurbing to him that ICMPv6 packets are sent out to the LDAP server (which
may or may not be related).

Comment 11

[Doug Wright]

-> Core:MailNews:LDAP Integration

Comment 12

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 13

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.