Closed Bug 228439 Opened 21 years ago Closed 17 years ago

LDAP broken if IPv6-Stack is installed

Categories

(MailNews Core :: LDAP Integration, defect)

Product:
MailNews Core
Component:
LDAP Integration
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: regression, Whiteboard: see comment 20 for status)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 CE++ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 This bug was introduced between Mozilla 1.5 release and 1.6 alpha. LDAP-Adressbooks can't be accessed anymore if IPv6-Stack is installed. Tested on 2 different systems, both Windows XP Professional. The problem is that Mozilla tries to reach the LDAP server via IPv6-in-v4-tunneling ::ffff:10.1.2.3 for example. This happens both if you enter a FQDN or a IPv4-Adress in the LDAP hostname. Workaround: Uninstall IPv6 support in Win XP, than it works again. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Confirmed ... I reported this earlier as an "LDAP Broken" bug and found that the IPv6 removal is a nice workaround ... sure would be nice if it worked though !!!
Flags: blocking1.6?
this is likely related to the DNS rewrite that has us now calling getaddrinfo on WinXP. the result of that is converted to a string and given to the LDAP C-SDK. i'm not sure why exactly we are generating mapped addresses like this though. perhaps this has something to do with PR_NetAddrToString. i don't have a way to test this, but perhaps a review of the code will indicate the problem.
1.6- maybe we can get this working in 1.7...
Flags: blocking1.6? → blocking1.6-
At present Windows doesn't support using an IPv4-mapped IPv6 address with an AF_INET6 socket. So to reach an IPv4 host you must create an AF_INET socket and use its IPv4 address.
By the way, ::ffff:10.1.2.3 is not IPv6-in-v4 tunneling. An address for IPv6-in-v4 tunneling is called an IPv4-compatible (as opposed to IPv4-mapped) address and would look like ::10.1.2.3.
Status: UNCONFIRMED → NEW
Ever confirmed: true
In IPv4 and IPv6 dual enabled environment, Same bug confirmed in Mozilla 1.7.2 and 1.7.3. Also confirmed is the solution to uninstall IPv6 and restart the PC again with native IPv4. Ethereal logs reveals that 1. Mozilla queries by AAAA to the local IPv6 enabled LDAP server and get the global IPv6 address of LDAP server correctly. 2. But somehow, instead of using the correct global IPv6 address, Mozilla tries to reach the LDAP server via IPv4 mapped IPv6 address ::ffff:10.1.2.3. (Note: 10.1.2.3 is of the IPv4 address of the LDAP server, and it is said that IPv4 mapped IPv6 address ::ffff:10.1.2.3 is deprecated.) By the way, in my case, Mozilla hangs-up for 2-3 minutes before getting a LDAP error message. I hope this report will be of some help.
Same problem shows up with Thunderbird version 0.8 (20040913) on XP SP1, I have regressed back to 0.5 and the problem seems to be the same. A tcpdump show the problem 10.10.11.34.3866 > 10.10.128.1.53: 22+ AAAA? directory.moria.org. (37) 10.10.128.1.53 > 10.10.11.34.3866: 22 0/1/0 (103) 10.10.11.34.3866 > 10.10.128.1.53: 23+ AAAA? directory.moria.org.ict.ru.ac.za. (50) 10.10.128.1.53 > 10.10.11.34.3866: 23 NXDomain* 0/1/0 (103) 10.10.11.34.3866 > 10.10.128.1.53: 24+ AAAA? directory.moria.org.mydomain.com. (46) 146.231.128.1.53 > 10.10.11.34.3866: 24 NXDomain* 0/1/0 (99) 10.10.11.34.3866 > 10.10.128.1.53: 25+ A? directory.moria.org. (37) 10.10.128.1.53 > 10.10.11.34.3866: 25 1/3/3 A 10.10.10.10 (186) Only a V4 address is returned 10.10.10.10, but now we go off and do a connect to a v6 version of the address 2001:548:1010:fff0:dc92:4f60:266d:b74a.1068 > ::ffff:10.10.10.10.389: S 1897039014:1897039014(0) win 16384 <mss 1440> 2001:548:1010:fff0:dc92:4f60:266d:b74a.1068 > ::ffff:10.10.10.10.389: S 1897039014:1897039014(0) win 16384 <mss 1440> 2001:548:1010:fff0:dc92:4f60:266d:b74a.1068 > ::ffff:10.10.10.10.389: S 1897039014:1897039014(0) win 16384 <mss 1440> On XP system at the saame patch level, without v6 enabled the connection works fine. Problem persists even if DNS name of LDAP server is replaces with an IP address - again the v6 ified address is used.
Product: MailNews → Core
Keywords: regression
*** Bug 220795 has been marked as a duplicate of this bug. ***
Can someone please change the priority to P2 as IPv6 is required in our company (Netzwert AG, http://www.netzwert.ag) and we also need access to our LDAP directory from within Thunderbird...
I did a LXR search for PR_GetIPNodeByName in the SeaMonkey source tree (http://lxr.mozilla.org/seamonkey/ident?i=PR_GetIPNodeByName). It shows that LDAP C SDK (mozilla/directory/c-sdk) is using that function with PR_AF_INET6 sockets and addresses exclusively. The code I saw in ldappr-io.c, and the knowledge that Windows XP IPv6 does not support IPv4-mapped IPv6 addresses, explain what was reported in comment 6 and comment 7. (Someone familiar with the code should confirm my findings.) There are two ways to fix this: 1. Modify mozilla/directory/c-sdk to use PR_GetAddrInfoByName. We've already done this work in Necko. This is the preferred solution because PR_GetIPNodeByName and the use of IPv6 sockets for communicating with both IPv4 hosts (with IPv4-mapped IPv6 addresses) and IPv6 hosts (with regular IPv6 addresses) is deprecated. 2. Modify NSPR to be smarter on Windows and automatically change a (IPv6 socket, IPv4-mapped IPv6 address) pair to (IPv4 socket, IPv4 address). Either one will do. Since we should do #1 anyway, I think we should not waste time doing #2 to fix a bug in deprecated code.
Assignee: sspitzer → nobody
*** Bug 292906 has been marked as a duplicate of this bug. ***
Rich, any interest in implementing solution #1 in the ldap c-sdk proposed by wtc in comment 10?
Flags: blocking-thunderbird2?
Yes. We need to make sure our LDAP C SDK code is IPv6 clean. This is also related to https://bugzilla.mozilla.org/show_bug.cgi?id=328791
QA Contact: grylchan → ldap-integration
Bug reproduced in a Windows 2003 Server with Citrix Presentation Server 4.0 environment. Uninstalling the IPV6 layer (and a reboot...) makes LDAP queries work again.
*** Bug 346221 has been marked as a duplicate of this bug. ***
Note that IPv6 is installed by default on Windows Vista (see bug 346221 comment 10) so this will mean that LDAP won't work on a default installation of Windows Vista.
Also note that on Vista you cannot uninstall the IPv6 stack. You can unbind it from a LAN interface, but it cannot be disabled on the loopback interface. Simply disabling the stack does not fix the LDAP lookup problem on Vista. This is going to be a significant problem in our environment. We have a lot of Thunderbird users, and LDAP lookup is a very commonly used feature. More details below: -------------------------------------------- Microsoft describes how to disable IPv6 here: http://www.microsoft.com/technet/itsolutions/network/ipv6/ipv6faq.mspx We are advised to add the following DWORD: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents With the value "0xFF". After doing this and performing a reboot, LDAP lookups still do not function.
This bug has been confirmed to also exists on a Windows 2000 box using Microsofts IPv6 technology preview patched to install onto Service Pack 4. I have not tried uninstalling it on this machine, but an identical machine running Windows 2000 SP4 without the stack without any problems. Using a DNS names with both an A and AAAA record causes Mozilla Thunderbird 1.5.0.5 to do an AAAA record look followed by an A record, however, only a connection to the IPv6 mapped IPv4 address is attempted. Using an AAAA-only DNS name causes aname lookup with no attempts at communication, and a straight IPv6 address causes a parsing error as it tries to read it as an IPv4 address followed by a port number. IPv4 addresses and A-only dns names also attempt communication using an IPv6 mapped IPv4 address. Disabling IPv6 on this machine would severely hinder other applications that we are using including accessing the IMAP and SMTP servers for E-mail communication.
As suggested by Wan-Teh in Comment #10 (1), using PR_GetAddrInfoByName in LDAP C SDK fixes the problem. Tested on Windows 2003 and Windows 2000 + IPv6 technology preview. Making this bug depend on 328791...
Depends on: 328791
Depends on: 359716
(In reply to comment #19) > Making this bug depend on 328791... Bug 328791 has been fixed on branch (in time for SeaMonkey 1.1 beta and Thunderbird 2.0 beta). To fix on trunk we'll need to fix bug 359716 which is upgrading us to the latest c-sdk version.
Whiteboard: see comment 20 for status
given comment 20, sounds like the remaning work is not a blocker on the branch.
Flags: blocking-thunderbird2? → blocking-thunderbird2-
Bug 359716 has now been fixed, so this bug should be fixed on trunk as well (by bug 328791 and bug 359716).
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.