Bug 1149612 - User is able to use any-ipv6-address interface on IPv4 environment
Summary: User is able to use any-ipv6-address interface on IPv4 environment
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management, IPv6 support
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: DR6
: EAP 6.4.0
Assignee: Brian Stansberry
QA Contact: Petr Kremensky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-06 08:47 UTC by Petr Kremensky
Modified: 2019-08-19 12:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
In previous versions of JBoss EAP 6, the logic for checking for, and rejecting, the combination of an `any-ipv6-address` configuration for an interface and the `java.net.preferIPv4Stack=true` system property was done when installing the network interface service rather than waiting until the service was starting. As a result, the check could run on host controller processes that did not need the interface service, resulting in spurious failures if the server process that would actually use the interface configuration did not have `java.net.preferIPv4Stack=true` set. In this release, the consistency check is been deferred until the interface service is started, ensuring it only occurs if the service is actually in use on that process. Now a server that does not have `java.net.preferIPv4Stack=true` set can use `any-ipv6-address` in the configuration of one of its interfaces even if the domain controller or its own host controller does have `java.net.preferIPv4Stack=true` set.
Clone Of:
Environment:
Last Closed: 2019-08-19 12:42:22 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat One Jira Issue Tracker WFCORE-156 Major Resolved Defer the WFLY-184 validation until service start 2018-03-20 05:18:53 UTC

Description Petr Kremensky 2014-10-06 08:47:35 UTC
Description of problem:
BZ900315 tighten up the interface creation procedure. User cannot create any new interface with any-ipv6-address=true if java.net.preferIPv4Stack is set to true now, but he is still able to configure existing interfaces with this property. 

We also found a few use cases where this fix is too strict. We should allow user to create this interface, but fail the operations which tries to make it actually do some work.

Version-Release number of selected component (if applicable):
 EAP 6.4.0.DR3

How reproducible:
 Always

Steps to Reproduce:
 1. start OOB standalone and connect to CLI

Actual results:
CASE1:
 /interface=myIPv6:add(any-ipv6-address=true) 
 "outcome" => "failed"
 /socket-binding-group=standard-sockets:write-attribute(name=default-interface, value=myIPv6)
 ... we don't make this far
CASE2:
 /interface=public:undefine-attribute(name=inet-address)
 "outcome" => "success"
 /interface=public:write-attribute(name=any-ipv6-address, value=true)
 "outcome" => "success"

 after reload we get the same bunch of errors as in BZ900315

Expected results:
CASE1:
 /interface=myIPv6:add(any-ipv6-address=true) 
 "outcome" => "success"
 /socket-binding-group=standard-sockets:write-attribute(name=default-interface, value=myIPv6)
 "outcome" => "failed"
CASE2:
 /interface=public:undefine-attribute(name=inet-address)
 "outcome" => "success"
 /interface=public:write-attribute(name=any-ipv6-address, value=true)
 "outcome" => "failed"

Comment 1 Brian Stansberry 2014-10-06 14:08:44 UTC
(In reply to Petr Kremensky from comment #0)

> 
> We also found a few use cases where this fix is too strict.

Please provide details.

Comment 2 Jakub Cechacek 2014-10-09 08:56:21 UTC
Use case I can think of is following:

User on dual stack machine wants to pre-configure an IPv6 interface before restarting the server and removing the java.net.preferIPv4Stack property.


However after investigating a bit further I believe that the fix introduced for BZ900315 is in fact not valid (and thus we don't even need to think about some use case) because:

1) it prevents user to set up *new and unused* interface with any-ipv6-address. Such setting is harmless -- thus there is no reason to prevent it. Additionally this can be set-up directly in XML config and server will start just fine. 

2) it still allows user to change the setting of *existing interface* (including the any-ipv6-address). This setting can lead to invalid configuration after server reload (e.g. setting any-ipv6-address for public interface).

To verify the second point execute this in CLI:

/interface=public:write-attribute(name=inet-address, value=undefined)
/interface=public:write-attribute(name=any-ipv6-address, value=true)
:reload

Now check the server log.

Comment 4 Petr Kremensky 2014-11-14 10:59:21 UTC
Verified on EAP 6.4.0.DR9


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