Closed Bug 108108 Opened 23 years ago Closed 21 years ago

if IPv6 connection fails, IPv4 should be tried.

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: artur, Assigned: mscott)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

I have a server with IPv4 and IPv6 addresses and imapd runs on it using IPv4.
When using Mozilla mail, I get connection refused when connecting to that
server. However, when I use a different name for that server that resolves only
to IPv4, the connection will succeed.

Mozilla should try using IPv4 if IPv6 fails.

*** This bug has been marked as a duplicate of 86917 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Reopening this bug in order to track this problem for IMAP mail.
Adding 86917 for this bug dependance.
Status: RESOLVED → UNCONFIRMED
Depends on: 86917
Resolution: DUPLICATE → ---
This really should be a duplicate of 86917 and not dependent on it.  But I will
confirm because of huangs comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
This bug still is a problem for HTTP connections
with build 2002071312 on Solaris/SPARC.
Reproduction:
1. set ipv4 and ipv6 address to a host in 
      /etc/ipnodes
      /etc/hosts
2. set /etc/nsswitch.conf as:
      ipnode    files
      host      files
3. bind an apache server on this host to both v4 and v6 ip address
4. use mozilla to visit the apache server and monitor the access_log file - it
works.
5. unbind apache to the v6 ip address and restart the server
6. restart mozilla (important)
7. try step 4 again - can't connect. the bug appears.

hi, Darin,
can you reproduce this bug? how to test on windows?
Darin, can't use "files" instead of "dns" to make the test, is it?
calvin: can you collect a socket transport log and attach it to this bug please?

setenv NSPR_LOG_MODULES nsSocketTransport:5
setenv NSPR_LOG_FILE socket.log

thx!!!
Reassigning QA to Ben.
Ben , can you check whether this bug is dup of bug 86917?
QA Contact: huang → benc
We have some bugs (search "networking" for "IPV6:" in the summary). IPv6 is not
supported by Netscape, so I have not given this area a lot of attention.

I'm in the process of trying to get a contributor that understands this
technology to look at the bugs and clarify what is going on.
Attached file NSPR log
Definitely there is a v4 ip address but mozilla didn't use it. It only tried v6
ip address.
Benjamin, there are a lot of people from mozilla community told me that mozilla
support ipv6 and i tried to use mozilla in a v6 environment. I think it works --
although still has some problems.
Calvin, the code does, b/c of NSPR, but alot of the higher level stuff (lets say
transport-political layers of the *eight* layer OSI networking model) have not
caught up.

Most IPv6 people are not end-users, they conciously got themselves into IPv6,
and thus far, they seem to have gotten them out of the problem w/o myself having
to learn alot of IPv6.
Calvin: mozilla's IPv6 support is mainly the result of contributions from folks
on the net (i.e., it is not a feature explicitly supported by netscape).  we try
to do our best to fix the bugs that crop up from now and then, but as far as
testing is concerned, that is completely community driven at this point.
Calvin: all IP addresses returned from PR_GetIPNodeByName would be listed here:

5[144928]: nsSocketTransport::OnFound [hockey2:80 743070] lookup succeeded
[FQDN=hockey2]
5[144928]:   => fe80::203:baff:fe0d:bbcf
5[144928]: nsSocketTransport: OnStopLookup(...) [hockey2:80 743070].  Status = 0
Host is hockey2

as you can see, mozilla is only seeing the IPv6 address.  so either there is
something wrong with your DNS configuration or there is something wrong with the
implementation of PR_GetIPNodeByName, which lives in NSPR.
I also wondered why mozilla only detect 1 IPv6 address. When I use "ping -a
hockey2", it returns 2 IP addresses, the first is v6 and the second is v4. Seems
different DNS query implementation between mozilla and ping.
Calvin: you should take a look at the implementation of PR_GetIPNodeByName in
NSPR...

http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/misc/prnetdb.c#694

maybe there is a bug causing problems on solaris.
Blocks: IPv6
qa to karen

This is really a mail bug that depends on bug 86917. That bug is fixed, so it
would be good to get the reporter to see if the problem is fixed in mail as well.

Just so you know, I have no immediate plans to verify the IPv6 aspects of that
bug, I am going to focus on testing multiple IPv4 address support.

Netscape QA does not actively do IPv6 testing, so if someone can set-up or find
DNS and server combinations, I would be glad to break out the IPv6 behavior into
separate bugs for interested contributors.

I've placed myself on the cc list so I can continue to monitor the dicussion.
QA Contact: benc → huang
QA Contact: huang → gchan
*** Bug 198239 has been marked as a duplicate of this bug. ***
the MailNews client is really broken in that case.
SMTP, IMAP and NNTP (I don't know POP3) have all this problem.
AFAIK all newer Linux distributions using glibc 2.3 and higher, will run in this
error because it seems that the new glibc does resolv always for AAAA (IPv6)
records.
I think this is really a blocker for all future mozilla versions.
Flags: blocking1.4a+
Please don't set flags if you don't know what they mean.
Flags: blocking1.4a+
If your router doesn't support IPv6 but your system does, going to the
site http://www.rfc-editor.org/ will reproduce the bug.  It has both an
IPv4 and IPv6 address.

Inspired by that, I've created a test site http://108108.bespin.org/
which has an invalid IPv6 address and a valid IPv4 address.  So this
should allow reproduction of the bug even on networks with a working
IPv6 router.
*** Bug 207213 has been marked as a duplicate of this bug. ***
I've just tried the http://108108.bespin.org/ and http://www.rfc-editor.org/
sites with 1.4rc1 and they seem to work. I don't know though with regards to the
orignal  problem with Mozilla mail.

Maybe this bug can be closed??



I use an IMAP server which supports both IPv6 and IPv4.

If I take down the route to the IMAP server, Mozilla correctly falls back to
IPv4. If I put the route back and then go offline and then online, Mozilla
starts using IPv6 again.

So it seems that this bug is fixed. WORKSFORME.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago21 years ago
Resolution: --- → WORKSFORME
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: