[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17305224#comment-17305224
]
Holger Rehn commented on DERBY-7107:
------------------------------------
[~bpendleton]
I already thought about that: It would be easy to modify the patch to 1st try
to connect INADDR_ANY and only use the proposed modification if that fails. But
I'm not sure if that would really be a good idea: The problem is, that this
approach (as well as the other way round - first trying to connect localhost
and falling back to INADDR_ANY) impacts runtime behaviour. If a client
application somehow depends on the connect timeout it could break. And -
repeating myself - INADDR_ANY is not a avlid target address when establishing a
connection. The current code works - accitentally - in many cases, but
nevertheless should be considered flawed.
Your suggestion to explicitly make a workaround enable-able simply doesn't
sound "right" to me. If the current behaviour is flawed - and I'm absolutely
convinced it is - a fix shouldn't be optional and require manual intervention.
Maybe fixing it and allowing the current behaviour to be enabled explicitly by
setting some 'compatibilty' flag would be the better approach...
> 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)
