Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162478 - The network system has switched by default to IPV6, but Apache has not
Summary: The network system has switched by default to IPV6, but Apache has not
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-05 12:56 UTC by vigna
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-05 13:04:32 UTC

Attachments (Terms of Use)

Description vigna 2005-07-05 12:56:39 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
This problem is not so easy to describe--in fact, I don't really know if it should be classified as an httpd or java bug, or not a bug at all. But we lost a lot of time to track down what happened, so this might be useful to someone else.

The story: we run some distributed software on Fedora since a while. One of the things we do is to give to the JVM an option like -Djava.policy= to download from a web server a policy file, granting suitable permissions.

We upgraded our boxes from Fedora 1 to Fedora 4, and everything stopped working, with Java complaining about permission errors. After a lot of debugging and stracing, it turned out that the upgrade turned on IPV6 automatically. However, the *web server* (Apache) was not IPV6-enabled. As a result, Java was detecting the existence of IPV6 and trying to open the web server using IPV6, with no results. Of course we could claim this is a Java bug (they should fall back to IPV4). But it was very complicated to diagnose the problem anyway.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Try to start a JVM using an http://-based policy file, but pointing at a standard httpd installation (which does not activate IPV6). Looking at the access logs, you'll see that the file is not accessed. If your Java code does something requiring permissions that are not granted usually, it will break.

Actual Results:  The policy file is never accessed.

Expected Results:  The policy file should have been downloaded.

Additional info:

Just disable IPV6 and everything works fine again.

Comment 1 vigna 2005-07-05 12:58:12 UTC
One thing I forgot: this happens with Sun's JVM (1.4.2 and 1.5.0), but does
*not* happen with JRockit (which probably falls back to IPV4, or maybe it is not
IPV6-enabled at all).

Comment 2 Joe Orton 2005-07-05 13:04:32 UTC
You need to track down more precisely what the problem was.  This could be a
resolver issue, a network issue, a Java issue, pretty much anything.

httpd will, in the default configuration, accept connections to port 80 on any
IPv4 or IPv6 address on any configured interface.

Comment 3 vigna 2005-07-05 14:03:35 UTC
OK, this is the magic point in the strace log where java breaks:

connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6,
"::ffff:", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 24) =
-1 EINVAL (Invalid argument)

Running the same stuff without IPV6, in the corresponding strace position we get: 

connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("")}, 16) = 0

and then everything works fine.

Comment 4 Joe Orton 2005-07-05 14:16:59 UTC
If that's a strace of the JVM, then that's a JVM bug.  EINVAL means that connect
has been called incorrectly in some way, my money is on the fact that 
sizeof(sockaddr_in6) is 28 not 24 as used in the third argument to the system call.

Note You need to log in before you can comment on or make changes to this bug.