inspector: proper WS URLs when bound to 0.0.0.0

[eugeneo]

JSON target list response will now return appropriate IP address
for instances listening on 0.0.0.0.

Ref: #11591

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

inspector: HTTP handler now checks actual connection IP address.

[bnoordhuis]

Changes themselves LGTM but can you add a regression test?

[eugeneo]

@bnoordhuis Thank you for the review. I added a test, CI pending: https://ci.nodejs.org/job/node-test-pull-request/6776/

[bnoordhuis]

LGTM. I wonder though, what happens in two tests try to start an inspector instance concurrently? It looks like one of them will lose out with a port conflict?

[gibfahn]

Rerun of CI failed on linuxone.

CI 2: https://ci.nodejs.org/job/node-test-pull-request/6777/

not ok 1329 inspector/test-inspector-ip-detection
---
duration_ms: 1.209
severity: fail
stack: |-
[err] Debugger listening on port 9229.
[err] Warning: This is an experimental feature and could change at any time.
[err] To start debugging, open the following URL in Chrome:
[err] chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=0.0.0.0:9229/13648cdd-2bf2-4982-9772-0c1a25986326
[err] Error: connect EHOSTUNREACH 148.100.110.64:9229
at Object.exports._errnoException (util.js:990:11)
at exports._exceptionWithHostPort (util.js:1013:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1105:14)
...

[eugeneo]

@gibfahn - I fixed that https://ci.nodejs.org/job/node-test-pull-request/6785/ - test will skip if the system does not allow connecting to its external IP.

LGTM was for the fixed version.

[eugeneo]

@bnoordhuis I am planning to update the code so port :0 would be supported from the command line (right now it is command line options parser that explicitly prevents it) - but that change caused some failures in the legacy debugger tests so I will have to look into it. I will update inspector tests to use :0 once it is working.

[eugeneo]

Landed as b170fb7

[italoacasas]

The test in /test/inspector/test-inspector-ip-detection is failing in v7 staging because the usage of common.skipIfInspectorDisabled which dosen't exist in v7 at the moment.

common.skipIfInspectorDisabled is not in v7 because the commit adding the functionality need backport #11631

[eugeneo]

@italoacasas Will #11631 be backported or should I change the test?

[italoacasas]

@eugeneo someone should take the lead of that backport, If you have the time available in the same PR you can backport both commits.

[joshgav]

@eugeneo I think this change breaks remote debugging by giving the remote debugger an IP address (host) which is internal to the system where Node is running. For example, if Node is running in a container the debugger might connect via the container host's name/address or via localhost over SSH (or both). The initial HTTP request for /json works, but since the debugger then uses the webSocketDebuggerUrl property from that response and that property has the internal IP address, the ensuing WebSocket connection fails.

The following Wireshark capture may help illustrate the issue. Note that after the /json response the debugger tries to use the internal IP address (and gets nowhere).

[eugeneo]

I'm afraid I am not familiar with containers...

I can do one of the following:

1. Revert the patch - /json will then report 0.0.0.0 that does not work in the remote debugging case.
2. Try to detect when 0.0.0.0 or similar is specified from the command line and only report the detected IP address only in those cases. Otherwise the IP address provided from the command line will be reported.
3. Any suggestions on how to detect the address other then by checking the TCP connection?

[joshgav]

@eugeneo will think more, it's a tricky problem. FWIW, when the address is reported as 0.0.0.0 things work in Chrome DevTools and VS Code. What is the case where 0.0.0.0 doesn't work?

BTW, I confirmed my diagnosis by changing the base image in this Dockerfile from node:latest to node:7.7.3, which made remote debugging work again.