failed_connect to_address repo.hex.pm | Is there a way to fall back to IPV4 in the mix tool?

hello o/ I’m hopping back to learning elixir/phoenix but running into a stumbling block following the phoenix installation guide:

This happened the first time I tried running mix local.hex but the suggested github alternative command worked (mix archive.install github hexpm/hex branch latest).

But then I got the same error still on other commands

$ mix deps.get
Failed to fetch record for 'hexpm/file_system' from registry (using cache instead)
{:failed_connect, [{:to_address, {'repo.hex.pm', 443}}, {:inet, [:inet], :nxdomain}]}
Failed to fetch record for 'hexpm/phoenix_live_dashboard' from registry (using cache instead)
{:failed_connect, [{:to_address, {'repo.hex.pm', 443}}, {:inet, [:inet], :nxdomain}]}
Failed to fetch record for 'hexpm/gettext' from registry (using cache instead)
$ mix ecto.create
Could not find "rebar3", which is needed to build dependency :ranch
I can install a local copy which is just used by Mix
Shall I install rebar3? (if running non-interactively, use "mix local.rebar --force") [Yn] y
** (Mix) httpc request failed with: {:failed_connect, [{:to_address, {'repo.hex.pm', 443}}, {:inet, [:inet], :nxdomain}]}

Could not install Rebar because Mix could not download metadata at https://repo.hex.pm/installs/rebar-1.x.csv.

From searching the forum it looks like it might be related to mix using IPV6 but my ISP (one of the main 3 in the UK) doesn’t support this yet :sweat_smile: :see_no_evil:

I was considering spinning up a Digital Ocean box and working off of that instead :thinking:

Is there a way to fall back to IPV4 in the mix tool maybe? Or possibly something else that might be going on here?

Any help would be much appreciated :pray:

The :nxdomain in the error makes me believe this is a DNS resolver issue. When a DNS resolver returns NXDOMAIN, that error message means that the domain does not exist (i.e. - can’t resolve the FQDN to an IP address).

Check to see that your system can resolve repo.hex.pm using a tool like host or nslookup. ping repo.hex.pm will even work in a pinch.

3 Likes

Oh ok, interesting. I’m no good with network stuff :see_no_evil:

So these seems to resolve (AFAIK) without issue:

$ host repo.hex.pm
repo.hex.pm is an alias for dualstack.f2.shared.global.fastly.net.
dualstack.f2.shared.global.fastly.net has address 151.101.2.2
dualstack.f2.shared.global.fastly.net has address 151.101.66.2
dualstack.f2.shared.global.fastly.net has address 151.101.130.2
dualstack.f2.shared.global.fastly.net has address 151.101.194.2
dualstack.f2.shared.global.fastly.net has IPv6 address 2a04:4e42::514
dualstack.f2.shared.global.fastly.net has IPv6 address 2a04:4e42:200::514
dualstack.f2.shared.global.fastly.net has IPv6 address 2a04:4e42:400::514
dualstack.f2.shared.global.fastly.net has IPv6 address 2a04:4e42:600::514
$ nslookup repo.hex.pm
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
repo.hex.pm     canonical name = dualstack.f2.shared.global.fastly.net.
Name:   dualstack.f2.shared.global.fastly.net
Address: 151.101.2.2
Name:   dualstack.f2.shared.global.fastly.net
Address: 151.101.66.2
Name:   dualstack.f2.shared.global.fastly.net
Address: 151.101.130.2
Name:   dualstack.f2.shared.global.fastly.net
Address: 151.101.194.2
Name:   dualstack.f2.shared.global.fastly.net
Address: 2a04:4e42::514
Name:   dualstack.f2.shared.global.fastly.net
Address: 2a04:4e42:200::514
Name:   dualstack.f2.shared.global.fastly.net
Address: 2a04:4e42:400::514
Name:   dualstack.f2.shared.global.fastly.net
Address: 2a04:4e42:600::514
 ping repo.hex.pm
PING dualstack.f2.shared.global.fastly.net (151.101.2.2) 56(84) bytes of data.
64 bytes from 151.101.2.2 (151.101.2.2): icmp_seq=1 ttl=58 time=17.5 ms
64 bytes from 151.101.2.2 (151.101.2.2): icmp_seq=2 ttl=58 time=16.7 ms

Any issues with these results do you think?

Doing some more digging I came across this issue and somebody seems to be encountering the same error as me!

Same results as their comment:

iex(2)> :gen_tcp.connect 'repo.hex.pm', 80, [{:active, false}]
{:error, :nxdomain}
iex(3)> :gen_tcp.connect 'repo.hex.pm', 80, [{:active, false}, :inet6]
{:error, :nxdomain}
iex(4)> :gen_tcp.connect 'repo.hex.pm', 443, [{:active, false}]
{:error, :nxdomain}
iex(5)> :gen_tcp.connect 'repo.hex.pm', 443, [{:active, false}, :inet6]
{:error, :nxdomain}

Looks like there is an ask for a PR around it, so guess I could start investigating.

I noticed that your fallback doesn’t include :nxdomain errors

Sounds like there is a fallback somewhere, but not for my error scenario :thinking:

So I compiled elixir v1.13 from the Github repo and added it’s bin directory to my path and followed the phoenix up and running instructions and… I’m not getting the issue! :thinking:

Either it’s fixed or I’m not recreating the proper environment for it to happen… it’s great that I’ve got a setup that works but this is puzzling!

What version of Elixir are you running in your normal environment?

It was also 1.13 :thinking: but I did have some other weird issues in my shell - I was in the main ubuntu app as a subsystem of windows, and decided to install the ubuntu 20 instead (which seemed to be working much better, even though it’s probably the same version of ubuntu lol).

So as an experiment I’ll try compiling elixir in the old one after another reinstall and verifying the issue was still present.