[jboss-jira] [JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property

Richard Achmatowicz (JIRA) jira-events at lists.jboss.org
Tue Feb 14 12:23:01 EST 2012


    [ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666472#comment-12666472 ] 

Richard Achmatowicz edited comment on AS7-3607 at 2/14/12 12:21 PM:
--------------------------------------------------------------------

Rajesh's error is probably due to starting AS7 using an IPv6 stack and an IPv6 link-local address. I get the same problem and have logged a bug: https://issues.jboss.org/browse/AS7-3752

When you start the AS using an IPv6 stack and do not specify defaults for jboss.bind.address and jboss.bind.address.management, the defaults of 127.0.0.1 specified in the profile get assigned to the interfaces. Because the stack is IPv6, these get represented as the IPv6 addresses ::ffff:127.0.0.1 which are distinctly different from 127.0.0.1.

I suspect that when Http11Apr is being passed the IPv6 address ::ffff:127.0.0.1, it is somehow mistakenly treating it an IPv4 address and creating the IPv4 socket accordingly. This does not happen if we pass in the IPv6 loopback address ::1 or a standard IPv6 global address -there IPv6 sockets are created. So rather than this being an issue about a system property, I suspect it's an issue with creation of sockets in the Http11Apr for IPv6 addresses in uncommon formats.
                
      was (Author: rachmato):
    Rajesh's error is probably due to starting AS7 using an IPv6 stack and an IPv6 link-local address. I get the same problem and have logged a bug: https://issues.jboss.org/browse/AS7-3752

When you start the AS using an IPv6 stack and do not specify defaults for jboss.bind.address and jboss.bind.address.management, the defaults of 127.0.0.1 specified in the profile get assigned to the interfaces. Because the stack is IPv6, these get represented as the IPv6 addresses ::ffff:127.0.0.1 which are distinctly different from 127.0.0.1.

I suspect that when Http11Apr is being passed the IPv6 address ::ffff:127.0.0.1, it is somehow mistakenly treating it an IPv4 address and creating the socket accordingly. This does not happen if we pass in the IPv6 loopback address ::1 or a standard IPv6 global address -there IPv6 sockets are created. So rather than this being an issue about a system property, I suspect it's an issue with creation of sockets in the Http11Apr for IPv6 addresses in uncommon formats.
                  
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
>                 Key: AS7-3607
>                 URL: https://issues.jboss.org/browse/AS7-3607
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web
>    Affects Versions: 7.1.0.CR1b
>            Reporter: Pavel Janousek
>            Assignee: Jean-Frederic Clere
>              Labels: eap6_prd_req
>             Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root at fedora15-vrt1 Documents]# ifconfig 
> p2p1      Link encap:Ethernet  HWaddr 00:00:00:00:00:01  
>           inet6 addr: 1:0:0:1::10/128 Scope:Global
>           inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:0 (0.0 b)  TX bytes:766 (766.0 b)
> [root at fedora15-vrt1 Documents]# 
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root at fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp        0      0 127.0.0.1:8080              0.0.0.0:*                   LISTEN      4765/java           
> tcp        0      0 ::ffff:127.0.0.1:5445       :::*                        LISTEN      4765/java           
> tcp        0      0 ::ffff:127.0.0.1:9990       :::*                        LISTEN      4765/java           
> tcp        0      0 ::ffff:127.0.0.1:3528       :::*                        LISTEN      4765/java           
> tcp        0      0 ::ffff:127.0.0.1:9999       :::*                        LISTEN      4765/java           
> tcp        0      0 ::ffff:127.0.0.1:5455       :::*                        LISTEN      4765/java           
> tcp        0      0 ::ffff:127.0.0.1:4447       :::*                        LISTEN      4765/java           
> [root at fedora15-vrt1 jboss-as]# 
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the jboss-jira mailing list