microsoft/ptvsd

Connection Refused 111, Internet Access and Proxies

grepusername opened this issue · 4 comments

Environment data

  • PTVSD version: 4.3.2
  • OS and version: Ubuntu 18.04 (and Windows 10, thanks to Remote SSH)
  • Python version (& distribution if applicable, e.g. Anaconda): Python 3.6.9
  • Using VS Code or Visual Studio: Yes

Actual behavior

When attempting to debug any code the connection to the debugger is refused with the following message:

/home/grep_username/venv/tufin_workflows/bin/python /home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/ptvsd_launcher.py --default --client --host localhost --port 38057 /home/grep_username/code/toys/test.py 
E00000.013: Exception escaped from start_client
            
            Traceback (most recent call last):
            File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/log.py", line 110, in g
                return f(*args, **kwargs)
            File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/pydevd_hooks.py", line 74, in start_client
                sock, start_session = daemon.start_client((host, port))
            File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/daemon.py", line 217, in start_client
                connect(client, addr)
            File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/socket.py", line 197, in connect
                sock.connect(addr)
            ConnectionRefusedError: [Errno 111] Connection refused
            

Traceback (most recent call last):
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/ptvsd_launcher.py", line 48, in <module>
    main(ptvsdArgs)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/__main__.py", line 432, in main
    run()
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/__main__.py", line 300, in run_file
    setup_connection()
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/__main__.py", line 291, in setup_connection
    daemon = ptvsd._remote.attach(addr)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/_remote.py", line 95, in attach
    patch_multiprocessing=ptvsd.options.multiprocess)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/_vendored/pydevd/pydevd.py", line 2179, in settrace
    wait_for_ready_to_run,
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/_vendored/pydevd/pydevd.py", line 2230, in _locked_settrace
    debugger.connect(host, port)  # Note: connect can raise error.
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/_vendored/pydevd/pydevd.py", line 1060, in connect
    s = start_client(host, port)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/pydevd_hooks.py", line 136, in _start_client
    return start_client(daemon, h, p)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/log.py", line 110, in g
    return f(*args, **kwargs)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/pydevd_hooks.py", line 74, in start_client
    sock, start_session = daemon.start_client((host, port))
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/daemon.py", line 217, in start_client
    connect(client, addr)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/socket.py", line 197, in connect
    sock.connect(addr)
ConnectionRefusedError: [Errno 111] Connection refused

Expected behavior

Successful debugging behaviour

Steps to reproduce:

  1. Open File (in this instance test.py contains only 'print("hello world")')
  2. Select Debugging profile such as the default:
    {
    "name": "Python: Current File",
    "type": "python",
    "request": "launch",
    "program": "${file}",
    "console": "integratedTerminal"
    }
  3. Failure occurs.

There are two factors that may be relevant here:

  1. A recent change to corporate proxies means that most internet requests return an SSO page rather than allowing access (as it was before) or returning an error or timeout (as we would prefer).
  2. a sudo apt update && sudo apt upgrade was performed within the last week

On a similar server (though running RHEL 7.7) debugging continues to connect - however, it is both able to connect to the internet/doesn't have a pernicious proxy configuration and hasn't been upgraded in months.

The connection that it's trying to make should be to 127.0.0.1 - is there anything in your firewall settings that might prevent that?

Hey int19h,

There is not:

 ~/sudo ufw status
 Status: inactive

There is nothing much listening at the moment but connecting to a few thing that are listening on relatively arbitrarily ports works fine, e.g.:

~/telnet 127.0.0.1 55443
Trying 127.0.0.1... 
Connected to localhost.
Escape character is '^]'.

Hm... I don't know if that would help, but connection handling is considerably different in the new version of the debugger - can you try the current pre-release, and see if that makes any difference?

Further testing has revealed that it isn't the proxy access that is the issue but the presence of docker or the docker host address. Further testing required on my end at least.