connect: connection refused when running in WSL2 #113

Activity

1. jakecoffman commented on May 12, 2023

   

   jakecoffman

   on May 12, 2023

   Member

   More actions

   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.
2. sblatnick commented on Jun 15, 2023

   

   sblatnick

   on Jun 15, 2023

   More actions

   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
3. jakecoffman commented on Jun 15, 2023

   

   jakecoffman

   on Jun 15, 2023

   Member

   More actions

   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".

   🎉React with 🎉1Reacted by Mario Zelger
4. sblatnick commented on Jun 15, 2023

   

   sblatnick

   on Jun 15, 2023

   More actions

   This would be wonderful! Thanks for the fast response!
5. sblatnick commented on Jun 16, 2023

   

   sblatnick

   on Jun 16, 2023

   More actions

   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!

   👍React with 👍1Reacted by Jake Coffman
6. jakecoffman commented on Jun 27, 2023

   

   jakecoffman

   on Jun 27, 2023

   Member

   More actions

   @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 😄.
7. jakecoffman commented on Jul 20, 2023

   

   jakecoffman

   on Jul 20, 2023

   Member

   More actions

   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!
8. jakecoffman

   closed this as completedon Jul 20, 2023