Closed Bug 195024 Opened 22 years ago Closed 21 years ago

Connection failed or takes some minutes when accessing to the site that have IPV6 and IPv4 address

Categories

(NSPR :: NSPR, defect)

Product:
NSPR
Component:
NSPR
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: t.matsuu, Assigned: wtc)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030225
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030225

This is the Bug 186745 on Linux.

When mozilla accesses to the site that have IPv6 and IPv4 address, the
connection is failed or takes some minutes.
  http://www.mew.org/
  http://www.kame.net/
  http://www.linux-ipv6.org/


I tested some cases.
1. Comment 9 of Bug 186745 is set,
  a. 2003021812_trunk
    "The document contains no data." dialog appears immediately.
  b. 2003022311_trunk
    Throbber moves for a few seconds, but web page does not shown.

2. Comment 9 of Bug 186745 is NOT set,
  a. 2003021711_trunk
    After throbber moves for some minutes, "The document contains no data."
dialog appears.
  b. 2003022311_trunk
    After throbber moves for some minutes, and connection is successful.

This bug is resolved with the comment 11 of Bug 186745.


connection failed or succeed for a  few minutes.

Reproducible: Always

Steps to Reproduce:
1. access to http://www.linux-ipv6.org/
Actual Results:  
connection failed or succeed for a  few minutes.

Expected Results:  
connection succeed imediately.
The patch in bug 186745 works fine.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I now remember why Linux is using the default implementation
of _pr_QueryNetIfs, which causes a Linux machine with an IPv6
stack to make AAAA DNS queries even if the machine has no IPv6
network interface.  Originally I only had an implementation
based on the SIOCGIFCONF ioctl, which is not documented to
support IPv6 addresses.  The preferred implementation should
be based on routing sockets, but I haven't had the time to do
that.

Ideally, we should use an implementation based on routing
sockets or the implementation based on getifaddrs().  When
was getifaddrs() added to Linux (or rather, glibc)?
Status: NEW → ASSIGNED
ChangeLog file in glibc-2.2.93 (installed in RedHat Linux 8.0):

2002-07-24  Roland McGrath  <roland@frob.com>

        Added <ifaddrs.h> interface with functions `getifaddrs', `freeifaddrs'.
        This implementation supports only IPv4.
        * inet/ifaddrs.h: New file.
        * sysdeps/generic/ifaddrs.c: New file.
        * sysdeps/gnu/ifaddrs.c: New file.
        * inet/test-ifaddrs.c: New file.
        * inet/Makefile (routines): Add ifaddrs.
        (headers): Add ifaddrs.h here.
        (tests): Add test-ifaddrs.
        * inet/Versions (GLIBC_2.3): New set, add getifaddrs and freeifaddrs.

So getifaddrs() is added between glibc-2.2.90 and 2.2.91.
Thank you for the info on getifaddrs().  This shows that
we can't use getifaddrs() on Linux becase the current
implementation does not support IPv6.

Whatever solution we choose, it must be tested on a system
with an IPv6 network interface configured.

It seems that the routing sockets on Linux do not support
NET_RT_IFLIST.
Reporter, I think this is probably fixed. Can you reproduce it with a recent
build? If so, I will resolve as WORKSFORME.
Enviromnent of my machine is now changed.
And this bug cannot be reproduced.
Marking WORKSFORME. Please reopen if you disagree.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.