[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303588#comment-17303588
]
Richard N. Hillegas commented on DERBY-7107:
--------------------------------------------
I found the following resources useful in trying to parse this conversation:
o
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.hale001/ipv6d0141001157.htm
o
https://www.cs.cmu.edu/afs/cs/academic/class/15441-f01/www/assignments/P2/htmlsim_split/node18.html
The attached patch looks straightforward, but I don't know how to guarantee
that it won't break existing applications.
Isn't the following workaround to this problem also straightforward: start
NetworkServerControl with whatever address is the result of the computation
performed by the patch?
> NetworkServerControl fails to connect to server started on INADDR_ANY
> ---------------------------------------------------------------------
>
> Key: DERBY-7107
> URL: https://issues.apache.org/jira/browse/DERBY-7107
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.14.2.0, 10.15.2.0
> Reporter: Holger Rehn
> Priority: Critical
> Attachments: DERBY-7107.diff
>
>
> If starting a NetworkServerControl on INADDR_ANY (0.0.0.0) it also uses this
> address when connecting to the running server instance (e.g. in method
> ping(), ...).
> Strictly speaking, INADDR_ANY isn't a valid target address. However, under
> normal circumstances, this works anyway. But if you have any "security"
> software in place that blocks such connections (Firewall or VPN, e.g. Cisco
> AnyConnect), you end up with an IOException:
> {code}Could not connect to Derby Network Server on host 0.0.0.0, port 1527:
> Permission denied: connect.{code}
> One simple fix would be to explicitly check the host address 'hostAddress' in
> NetworkServerControlImpl.setUpSocket() and if this is INADDR_ANY, use
> 'localhost' instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
