connect: connection refused when running in WSL2

[cpswan]

I've installed the dependabot cli in Ubuntu 20.04.6 running on WSL2, and whenever I run dependabot update ... there seems to be a connection problem with the proxy:

 proxy | 2023/05/09 09:46:49 [479] POST http://host.docker.internal:34279/update_jobs/cli/record_update_job_error
 proxy | 2023/05/09 09:46:49 [479] No response from server
updater | 2023/05/09 09:46:49 ERROR dial tcp 192.168.65.2:34279: connect: connection refused

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal

docker version

Client:
 Version: 20.10.21
 API version: 1.41
 Go version: go1.18.1
 Git commit: 20.10.21-0ubuntu1~20.04.2
 Built: Thu Apr 27 05:56:19 2023
 OS/Arch: linux/amd64
 Context: default
 Experimental: true

Server: Docker Desktop
 Engine:
 Version: 20.10.24
 API version: 1.41 (minimum version 1.12)
 Go version: go1.19.7
 Git commit: 5d6db84
 Built: Tue Apr 4 18:18:42 2023
 OS/Arch: linux/amd64
 Experimental: false
 containerd:
 Version: 1.6.18
 GitCommit: 2456e983eb9e37e47538f59ea18f2043c9a73640
 runc:
 Version: 1.1.4
 GitCommit: v1.1.4-0-g5fd4c4d
 docker-init:
 Version: 0.19.0
 GitCommit: de40ad0

docker network ls

NETWORK ID NAME DRIVER SCOPE
82ed92ae2b3e bridge bridge local
290c4fb24a0d host host local
a4a6a0f0e11e none null local

[jakecoffman]

I can reproduce this, it seems to not be able to contact the server running on the host in WSL via host.docker.internal. It seems like this might be related: docker/for-win#12673

I'll have to dig into this more sometime and see if there's a way around the issue.

[sblatnick]

I suspect my issue may be related, but not on WSL. My case is running the dependabot client within a docker container.

I'm able to run this directly on a linux box (debian), no Windows, no vm involved works as expected:

dependabot update maven local/scan --local . -o dependabot.yaml
...
updater | 2023/06/15 14:32:25 INFO Starting job processing
 proxy | 2023/06/15 14:32:25 [001] POST http://host.docker.internal:33593/update_jobs/cli/update_dependency_list
{"data":{"dependencies":...
 proxy | 2023/06/15 14:32:25 [001] 200 http://host.docker.internal:33593/update_jobs/cli/update_dependency_list
 proxy | 2023/06/15 14:32:25 [002] POST http://host.docker.internal:33593/update_jobs/cli/increment_metric

But when I effectively run the same command within a docker container, the proxy fails to reach the API:

updater | 2023/06/14 20:24:33 INFO Starting job processing
 proxy | 2023/06/14 20:24:33 [001] POST http://host.docker.internal:33549/update_jobs/cli/update_dependency_list
 proxy | 2023/06/14 20:24:33 [001] No response from server
updater | 2023/06/14 20:24:33 ERROR dial tcp 172.17.0.1:33549: connect: connection refused
updater | 
updater | 2023/06/14 20:24:33 ERROR /home/dependabot/dependabot-updater/lib/dependabot/api_client.rb:113:in `update_dependency_list'
updater | 2023/06/14 20:24:33 ERROR /home/dependabot/dependabot-updater/lib/dependabot/service.rb:61:in `update_dependency_list'
updater | 2023/06/14 20:24:33 ERROR /home/dependabot/dependabot-updater/lib/dependabot/update_files_command.rb:28:in `perform_job'
updater | 2023/06/14 20:24:33 ERROR /home/dependabot/dependabot-updater/lib/dependabot/base_command.rb:52:in `run'
updater | 2023/06/14 20:24:33 ERROR bin/update_files.rb:23:in `<main>'

I'm not sure what I might be doing wrong. I am passing /var/run/docker.sock to my container, as well as --add-host host.docker.internal:host-gateway

[jakecoffman]

Hmm yeah this might be related to the WSL issue.

Just so we're on the same page, the current network setup is this:

flowchart LR
 proxy --> internet
 proxy-- host.docker.internal -->api
subgraph host
 api
 subgraph internal
 updater --> proxy
 end
end

Loading

By mounting the host's Docker socket, we end up with this:

flowchart LR
 proxy --> internet
 proxy-- host.docker.internal --> nothing
subgraph host
 nothing
subgraph internal1
 api
 subgraph internal2
 updater --> proxy
 end
end
end

Loading

The API isn't going to be routable from the layer below unless we set the port explicitly, and then bind the same port to the host.

I just tested that out and it seems to work. I can put up a PR to allow setting the API's PORT with an environment variable. Then you'll need to pass Docker options like -p 8088:8088 -e "FAKE_API_PORT=8088".

[sblatnick]

This would be wonderful! Thanks for the fast response!

[sblatnick]

I would like to confirm that this fix does address the issue. I built the client in my docker container and ran it with the new port specified, and it ran flawlessly.

Thank you again!

[jakecoffman]

@cpswan I was able to get it working under WSL2 using export FAKE_API_HOST="127.0.0.1" which overrides the default Linux setting here:

cli/internal/server/api.go

Lines 44 to 46 in 940adb3

	if runtime.GOOS == "linux" {
	fakeAPIHost = "0.0.0.0"
	}

I typically default serving to 127.0.0.1 since it's more secure, but for Linux the calls get connection refused coming from a Docker container unless it's serving on 0.0.0.0. That's why I added that condition for Linux.

Strangely though in WSL2 0.0.0.0 doesn't seem to work, but setting it back to 127.0.0.1 does work!

It would be nice if this all would just work without messing with environment variables. So someone figures out how to get 127.0.0.1 working on Linux or 0.0.0.0 working on WSL, let me know or put up a PR 😄.

[jakecoffman]

I'm going to close this out since we have a method for making it work. As I said above, if there are any ideas on making this work without messing with environment variables let me know and PRs welcome!