609346 - LDAP should reconnect after connection reset - error message "LDAP server search problem", Error code 0x80070057: Unknown error

Status: NEW

(MailNews Core :: LDAP Integration, defect)

Description

[Wayne Mery (:wsmwk)]

Attachment: ldap log for "ets.."

Mozilla/5.0 (Windows NT 6.0; rv:2.0b8pre) Gecko/20101101 Thunderbird/3.3a1pre seen also in v3, and v2

LDAP server search problem with the following steps:
1. ldap set up for port 389, subtree, (objectclass=*), return max 100 entries
2. start compose
3. auto complete a couple addresses, stop after adding two To: addresses 
4. type in subject and body
5. (+0 seconds) wait several seconds, type a bit more in body
6. (+15 seconds) click in third (empty) address field, type first, second, third characters of address

results: "LDAP server search problem", with or without some already recommended addresses from ldap

testcase files for ldap3 attempted "ets3" in address field

Comment 1

[Wayne Mery (:wsmwk)]

Attachment: wireshark log for "ets..."

Comment 2

[Nikolay Shopik]

Wayne, can you attach wireshark pcap file instead of text.

Comment 4

[Wayne Mery (:wsmwk)]

Attachment: wireshark .pac trace

Nikolay, see attached.
1. ldap lookup worked on first address "gal0"
2. lookup failed on second address "luops"

I didn't do anything special to cause failure, just waited a few seconds (10-15?) between #1 and #2

Comment 5

[Nikolay Shopik]

From cap I see it doing searchRequest for "gal" then abandon it(cause you typed another symbol) and doing "gal0" request. 
And then SearchRequest for "l" symbol after that your LDAP server instantly reset  TCP connection, which is may causing TB is confused.

Comment 6

[Wayne Mery (:wsmwk)]

Dave Kahn, can you reproduce, and provide a wireshark trace .pac file. http://www.wireshark.org/download.html

(now I'm having trouble reproducing as simply as I did in comment 4, which was done in my fast win7 machine)

Nikolay, so the server is behaving correctly?

Comment 7

[Nikolay Shopik]

Not really, it LDAP server should't close connection such suddenly w/o any errors. My guess this is server side issue/configuration, and should be check LDAP logs for that. For example this maybe some type of rate-limiting after large search, your previous result is somewhat big, but I highly doubt about rate-limiting that way.

Comment 8

[Dave]

Thanks for working on this bug. It is important to me. I can reproduce it 100%
of the time. I am unfamiliar with wireshark. I can download it from the web. I
would need instruction on its use, though.

I am pretty sure it is not the LDAP server disconnecting because while my
compose window LDAP session is not working, I can go to addressbook and do the
same search, wait minutes and do more searches successfully. LDAP does not time
out in addressbook window.

Comment 9

[Nikolay Shopik]

Select menu Capture->Interfaces, after that you will see your network interface(s), if there only one just press "Options" button, otherwise make sure you are selecting your current active interface. Enter in "Capture Filter" - "tcp port 389" and press "Start". After you've done reproducing bug, select menu Capture->Stop. File->Save will save for you pcap file need.

Comment 10

[Dan Schwartz]

(In reply to comment #4)
> Created attachment 503320 [details]
> wireshark .pac trace
> 
> Nikolay, see attached.
> 1. ldap lookup worked on first address "gal0"
> 2. lookup failed on second address "luops"
> 
> I didn't do anything special to cause failure, just waited a few seconds
> (10-15?) between #1 and #2

Our slapd server (openldap) is configured to timeout an "idle" connection after 15 seconds (idletimeout 15), however if it's an active connection then it shouldn't be timed out.  Likewise, if a search is taking more than 20 seconds, it times that out as well (timelimit 20).  If the connection is dropped due to being idle, shouldn't the application create a new one?

Comment 11

[Nikolay Shopik]

Well I don't really believe there been idle connection at all, as you can see from trace it reseting connection right after user packet for search.

Comment 12

[Nikolay Shopik]

(In reply to comment #10)
> Likewise, if a search is taking more than 20 seconds,
> it times that out as well (timelimit 20).  If the connection is dropped due to
> being idle, shouldn't the application create a new one?
Well from what I see in my LDAP server, TB closes every connection if it idle more 5 seconds. But this only apply to address book search. I did try enter email in new email composion and see exact same behavior, after 5 seconds connection _still_ active and not unbind message.

I should learn to read messages more carefully before post, sorry about that :(

Comment 13

[Wayne Mery (:wsmwk)]

Dan bumped the timeout to 45 sec, and I can reproduce the issue if I wait long between adding addresses, as in #4 and #5. 

In my few attempts I haven't been able to trigger it with shorter waits. But I'm checking other reports and steps to see if there are other ways to reproduce.


error message is a primary symptom, and having it in summary helps searchability - let's keep it :)

Comment 14

[Nikolay Shopik]

Well it behaving very strange, it not closing connection even in address book if you not press "x" in search field. So let say you search word "John" and then you doubleclick on word to select it and start typing "Doe" to replace word "John" this will cause to first connection stay until you close address book window or press "x", but second and following connections will issue unbind command after few seconds.
So this is something todo with first connection only, also this sounds like separate bugs.
1. (rfe) Reconnect if server/network interface reset connection
2. Fix issues with first LDAP connection, won't unbound correctly.

Comment 15

[Dave]

Attachment: Wireshark output showing capture of LDAP failure.

Attached pcap file shows activity from LDAP search in message compose window successful on first entry. Wait 30 seconds. Then LDAP search failure on second entry.

Comment 16

[Dave]

After I posted the wireshark pcap file, I stopped seeing any activity. Is this still issue still being worked? Any update?

Comment 17

[Nikolay Shopik]

Dave, we found root of cause of this problem, but currently nobody working on patch afaik.

Comment 18

[Wayne Mery (:wsmwk)]

(In reply to comment #14)
> Well it behaving very strange, it not closing connection even in address book
> if you not press "x" in search field. So let say you search word "John" and
> then you doubleclick on word to select it and start typing "Doe" to replace
> word "John" this will cause to first connection stay until you close address
> book window or press "x", but second and following connections will issue
> unbind command after few seconds.
> So this is something todo with first connection only, also this sounds like
> separate bugs.
> 1. (rfe) Reconnect if server/network interface reset connection
> 2. Fix issues with first LDAP connection, won't unbound correctly.

Comment 19

[Wayne Mery (:wsmwk)]

clicking on the error message "LDAP server search problem" shows "Error code 0x80070057: Unknown error"

xref Bug 574777 - Better wording than "Error code 0x80070057......"

Comment 20

[tom.laredo]

Please vote for this bug if you encountered it because it is verry important for my firm to fix it! =)

Comment 21

[Anthony Milan]

(In reply to comment #20)
> Please vote for this bug if you encountered it because it is verry important
> for my firm to fix it! =)

One more.

Comment 22

[Anthony Milan]

(In reply to comment #17)
> Dave, we found root of cause of this problem, but currently nobody working on
> patch afaik.

How can we help? Can we know the cause of this problem? This bug infuriates my users :(

Comment 23

[Martin Jungowski]

I think we just ran into this as well. It's sort of disturbing that this has been going on for almost a year and there's still no fix.

Comment 24

[Jan Mostert]

(In reply to Nikolay Shopik from comment #17)
> Dave, we found root of cause of this problem, but currently nobody working
> on patch afaik.

Almost 8 months since this comment. Come on guys, we are waiting for a fix. This is the reason we still use TB2!

Comment 25

[Wayne Mery (:wsmwk)]

In addition to Jan, this has kept at least one other organization from migrating off of TB2.

Comment 26

[Jan Mostert]

Ok, we are waiting a long time now for a fix. We do not want to migrate to Outlook, so if someone can fix this issue soon, we are willing to pay €750,00 for it.

Comment 27

[yonatanhak]

Same problem at my place. 
Add my vote to this issue. Seems that any BIZ related feature gets a lower priority. So I'm willing to add another $750 to Jan Mostert offer. (Is your offer still valid Jan?).

A workaround (which goes against what LDAP is) is to go to the properties of the LDAP based address book, select the "Offline" tab and click "Download Now" to have a local copy of your own.
If you do it weekly, then you are sort of "updated".

Comment 28

[[e-mail]]

hey guys! 
I had the same error, and after messing around with the settings a bit, i found a solution that works (for me), even after restarting TB/my computer.
in the settings of the directoryserver i checked and then unchecked the ' use secure connection (ssl)' option, in advanced i changed the 'one level' option to the 'underlying levels' and back again.
and it just works... 100% of the time.. it probably is coincidence, but you could always give it a try.
(i probably made some wrong translations, my TB is set in a different language. i hope you get what i mean)

Comment 29

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 30

[Ping Chen [:rnons] (away)]

I don't quite understand this bug. Do you mean autocompletion stops working after a few times? I think each search uses a new connection. Can you still reproduce?