hub-feedback icon indicating copy to clipboard operation
hub-feedback copied to clipboard

Published 20 hours ago • verified publisher icon docker

`docker pull` fails on an IPv4-only network

Open cletusw opened this issue 2 years ago • 20 comments

Problem description

I'm following the install steps (https://docs.docker.com/engine/install/raspberry-pi-os/#install-using-the-repository), and docker run (also just docker pull) fails on an IPv4-only network on Raspberry Pi OS 32-bit:

$ sudo docker pull hello-world
Using default tag: latest
Error response from daemon: Get "https://registry-1.docker.io/v2/library/hello-world/manifests/sha256:4f53e2564790c8e7856ec08e384732aa38dc43c52f02952483e3f003afbf23db": dial tcp [2600:1f18:2148:bc02:cfd8:db68:ea1f:277c]:443: connect: network is unreachable

Presumably this is related to https://www.docker.com/blog/docker-hub-registry-ipv6-support-now-generally-available/ . I'm on a network I don't control that apparently has IPv6 disabled:

$ curl -X POST https://auth.ipv6.docker.com
curl: (7) Couldn't connect to server

$ curl -6 https://google.com
curl: (7) Couldn't connect to server

$ curl -X POST https://auth.ipv4.docker.com
404 page not found

$ curl -4 https://google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>

Is IPv4 no longer supported? If so, that's unfortunate, since this is a pretty bog-standard residential ISP in Utah.

Related

  • https://forums.docker.com/t/unable-to-pull-docker-image-due-to-ipv6-since-2023-08-23-around-6pm-cest/137378
    • I tried export DOCKER_BUILDKIT=0 && sudo docker pull hello-world. Didn't help.
  • https://github.com/docker/hub-feedback/issues/2165#issuecomment-965605835
    • I tried specifying registry.ipv4.docker.com. Didn't help:
$ sudo docker pull registry.ipv4.docker.com/library/hello-world
Using default tag: latest
Error response from daemon: Get "https://registry.ipv4.docker.com/v2/library/hello-world/manifests/sha256:4f53e2564790c8e7856ec08e384732aa38dc43c52f02952483e3f003afbf23db": dial tcp: lookup registry.ipv4.docker.com on 192.168.1.1:53: no such host

docker info output

Docker Info:

Client: Docker Engine - Community
 Version:    24.0.6
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.11.2
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.21.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 24.0.6
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 61f9fd88f79f081d64d6fa3bb1a0dc71ec870523
 runc version: v1.1.9-0-gccaecfc
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.1.21-v7+
 Operating System: Raspbian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: armv7l
 CPUs: 4
 Total Memory: 922MiB
 Name: unifi
 ID: 70d62ede-9487-4d17-a129-2407b0ef6d8f
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No memory limit support
WARNING: No swap limit support

Debug Information

Timetamp or time range: 2023-10-05 Public IP: 204.8.230.209

I also tried switching from stable to test. docker-ce-rootless-extras got upgraded, but still didn't help.

containerd.io is already the newest version (1.6.24-1).
docker-buildx-plugin is already the newest version (0.11.2-1~raspbian.11~bullseye).
docker-ce-cli is already the newest version (5:24.0.6-1~raspbian.11~bullseye).
docker-ce is already the newest version (5:24.0.6-1~raspbian.11~bullseye).
docker-compose-plugin is already the newest version (2.21.0-1~raspbian.11~bullseye).

$ sudo docker buildx ls
NAME/NODE DRIVER/ENDPOINT STATUS  BUILDKIT             PLATFORMS
default * docker                                       
  default default         running v0.11.6+616c3f613b54 linux/arm/v7

$ route -A inet6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
localhost/128                  [::]                       U    256 1     0 lo
fe80::/64                      [::]                       U    256 1     0 wlan0
[::]/0                         [::]                       !n   -1  1     0 lo
localhost/128                  [::]                       Un   0   4     0 lo
fe80::20fc:67f0:a124:f8d9/128  [::]                       Un   0   2     0 wlan0
ff00::/8                       [::]                       U    256 6     0 wlan0
[::]/0                         [::]                       !n   -1  1     0 lo

Task List

  • [X] This is NOT a security issue
  • [X] I do NOT have a Docker subscription
  • [X] I have looked through other issues and they do NOT apply to me

cletusw avatar Oct 07 '23 03:10 cletusw

Also FWIW I can't use a 64-bit OS because my Pi 3B+ only has 1 GB of RAM which isn't enough for the 64-bit version of the UniFi controller I need to run (https://github.com/ryansch/docker-unifi-rpi/issues/100 )

cletusw avatar Oct 07 '23 03:10 cletusw

IPv4 still works and is supported by Docker Hub Registry.

The main endpoints your client will be operating against are auth.docker.com, registry-1.docker.io and production.cloudflare.docker.com. All of these endpoints are dualstack. You can see this by doing dig registry-1.docker.io A, dig auth.docker.io A, and dig production.cloudflare.docker.com A.

Are you using any sort of docker-in-docker setup? These are where you embed a Docker server or client inside of a running container. If so, the problem might be coming from a mismatch between what the host and the container supports, networking wise. If this is the case, enabling IPv6 for the container might be your solution.

Let us know if that solves the issue or not!

ingshtrom avatar Oct 16 '23 18:10 ingshtrom

I'm only at the location occasionally, so I can't currently test curl-ing those endpoints directly, but I'll try to remember to next time I'm there.

And no, I was definitely not doing docker-in-docker. Just a fresh Raspberry Pi OS setup running the exact steps listed in https://docs.docker.com/engine/install/raspberry-pi-os/#install-using-the-repository .

cletusw avatar Oct 16 '23 22:10 cletusw

I have the same issue as well. My setup is as follows:

  • I have Windows 11 machine with VirtualBox installed
  • I have single Debian VM that is being created by Vagrant that has only IPv4 support configured (see bellow)
  • Inside the Debian I am not able to pull docker images as it constantly tries to use IPv6
Vagrantfile 
Vagrant.configure("2") do |config|
  config.vm.define "default" do |node|
    node.vm.box = "debian/bullseye64"
    node.vm.network "private_network", ip: "192.168.60.130"
  end
end
ip addr from VM 
vagrant@debian:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:8d:c0:4d brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0
       valid_lft 86341sec preferred_lft 86341sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:e4:01:69 brd ff:ff:ff:ff:ff:ff
    altname enp0s8
    inet 192.168.60.130/24 brd 192.168.60.255 scope global eth1
       valid_lft forever preferred_lft forever
4: br-3b9d87ee11da: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:d2:fa:6b:ee brd ff:ff:ff:ff:ff:ff
    inet 172.20.0.1/16 brd 172.20.255.255 scope global br-3b9d87ee11da
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:ae:4b:43:99 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

vagrant@debian:~$ docker pull mariadb:10.11.5-jammy
Error response from daemon: Head "https://registry-1.docker.io/v2/library/mariadb/manifests/10.11.5-jammy": dial tcp [2600:1f18:2148:bc01:a3b0:6734:c617:7c5c]:443: connect: cannot assign requested address

I don't know how Docker evaluates it is supposed to use IPv6. Other tools does not have this issue when communicating with dual-stack servers.

vagrant@debian:~$ curl https://registry-1.docker.io/v2/library/mariadb/manifests/10.11.5-jammy
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"library/mariadb","Action":"pull"}]}]}

Disabling IPv6 on adapters of the host machine (Win 11) did not help.

pavelhoral avatar Oct 28 '23 15:10 pavelhoral

~~There is a workaround by directly setting IP address in /etc/hosts:~~

52.1.184.176 registry-1.docker.io
34.194.164.123 auth.docker.io

UPDATE: it does not work - it starts pulling layers and then it probably uses a different endpoint that is resolved to IPv6

$ docker pull mariadb:10.11.3-jammy
10.11.3-jammy: Pulling from library/mariadb
d1669123f281: Pull complete
7942299fe584: Pull complete
ca116927bbe1: Pull complete
9c0f0b5293ed: Downloading
d45a2cae5b8e: Downloading
818ec8e8ed03: Downloading
63656f4d882b: Downloading
dd430f2c8014: Downloading
dial tcp [2606:4700::6810:65cf]:443: connect: cannot assign requested address

pavelhoral avatar Oct 28 '23 15:10 pavelhoral

Confirmed that curl-ing auth.docker.com, registry-1.docker.io and production.cloudflare.docker.com works fine (due to their dual stack nature), but docker pull still tries unsuccessfully to use IPv6 — maybe it should fall back to explicit IPv4 in cases like this?

cletusw avatar Oct 28 '23 18:10 cletusw

Confirmed that curl-ing auth.docker.com, registry-1.docker.io and production.cloudflare.docker.com works fine (due to their dual stack nature), but docker pull still tries unsuccessfully to use IPv6 — maybe it should fall back to explicit IPv4 in cases like this?

Ah... production.cloudflare.docker.com is what I was missing in /etc/hosts as a workaround (adjust based on your region):

52.1.184.176 registry-1.docker.io
34.194.164.123 auth.docker.io
104.16.102.207 production.cloudflare.docker.com

pavelhoral avatar Oct 28 '23 19:10 pavelhoral

Docker Engine uses Go's built-in HTTP client, which implements Happy Eyeballs (RFC 6555, https://datatracker.ietf.org/doc/html/rfc6555). With this mechanism, IPv6 should be tried first and discarded shortly after (~300ms later) if it doesn't work. Go picks IPv6 if the connection was successfully established.

In your case, either this algorithm fail to pick IPv4 or the error message reports an issue with IPv6 whereas the issue is really about both IPv4 and IPv6 connection failing to be established (that's weird but somewhat expected).

@cletusw Could you try to tcpdump while you pull an image and see what happens for both IPv4 and IPv6 packets? Would be even better if you can upload a pcap file so that I can take a look at it myself.

akerouanton avatar Oct 31 '23 16:10 akerouanton

Okay I'll give that a try next time I'm on location.

cletusw avatar Oct 31 '23 16:10 cletusw

Docker Engine uses Go's built-in HTTP client, which implements Happy Eyeballs (RFC 6555, https://datatracker.ietf.org/doc/html/rfc6555). With this mechanism, IPv6 should be tried first and discarded shortly after (~300ms later) if it doesn't work. Go picks IPv6 if the connection was successfully established.

In your case, either this algorithm fail to pick IPv4 or the error message reports an issue with IPv6 whereas the issue is really about both IPv4 and IPv6 connection failing to be established (that's weird but somewhat expected).

This does not sound right. I am not familiar with Go but this gives the following output (so the client works I guess):

Test with simple request from Go 
package main

import (
  "io/ioutil"
  "log"
  "net/http"
)

func main() {
  resp, err := http.Get("https://registry-1.docker.io/v2/")
  if err != nil {
    log.Fatalln(err)
  }
  body, err := ioutil.ReadAll(resp.Body)
  if err != nil {
    log.Fatalln(err)
  }
  sb := string(body)
  log.Printf(sb)
}

vagrant@babylon:~/test$ go run .
2023/10/31 05:15:05 {"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

While docker pull ends with the following error:

Running docker pull 
vagrant@babylon:~/test$ docker pull hello-world
Using default tag: latest
Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp [2600:1f18:2148:bc02:cfd8:db68:ea1f:277c]:443: connect: cannot assign requested address

vagrant@babylon:~/test$ docker --version
Docker version 24.0.7, build afdd53b

Also curl works as expected:

Testing requests with curl 
vagrant@babylon:~/test$ curl -4 https://registry-1.docker.io/v2/
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

vagrant@babylon:~/test$ curl -6 https://registry-1.docker.io/v2/
curl: (7) Couldn't connect to server

pavelhoral avatar Oct 31 '23 16:10 pavelhoral

Ah... I see why mine comment should probably be a separate issue. The original post is connect: network is unreachable while mine error is cannot assign requested address. Ok... I will try to investigate a bit more and create a new issue. Apologies for the spam.

pavelhoral avatar Oct 31 '23 16:10 pavelhoral

I am experiencing the same problem as @cletusw. Are there any new insights what might be the problem?

Also here is a tcpdump from the attempt to pull the image.

  18:28:46.892681 IP registry-1.docker.io.https > 192.168.0.107.60346: Flags [R], seq 2400902721, win 0, length 0
  18:28:46.915340 IP auth.docker.io.https > 192.168.0.107.33762: Flags [S.], seq 1588323395, ack 2037620195, win 26847, options [mss 1460,sackOK,TS val 1908251961 ecr 3041932551,nop,wscale 12], length 0
  18:28:46.915396 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [.], ack 1, win 502, options [nop,nop,TS val 3041932654 ecr 1908251961], length 0
  18:28:46.916788 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [P.], seq 1:251, ack 1, win 502, options [nop,nop,TS val 3041932655 ecr 1908251961], length 250
  18:28:47.017807 IP auth.docker.io.https > 192.168.0.107.33762: Flags [.], ack 251, win 7, options [nop,nop,TS val 1908252063 ecr 3041932655], length 0
  18:28:47.017887 IP auth.docker.io.https > 192.168.0.107.33762: Flags [P.], seq 1:128, ack 251, win 7, options [nop,nop,TS val 1908252063 ecr 3041932655], length 127
  18:28:47.017933 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [.], ack 128, win 502, options [nop,nop,TS val 3041932756 ecr 1908252063], length 0
  18:28:47.018076 IP auth.docker.io.https > 192.168.0.107.33762: Flags [.], seq 166:1614, ack 251, win 7, options [nop,nop,TS val 1908252064 ecr 3041932655], length 1448
  18:28:47.018115 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [.], ack 128, win 502, options [nop,nop,TS val 3041932756 ecr 1908252063,nop,nop,sack 1 {166:1614}], length 0
  18:28:47.018126 IP auth.docker.io.https > 192.168.0.107.33762: Flags [P.], seq 128:134, ack 251, win 7, options [nop,nop,TS val 1908252064 ecr 3041932655], length 6
  18:28:47.018154 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [.], ack 134, win 502, options [nop,nop,TS val 3041932756 ecr 1908252064,nop,nop,sack 1 {166:1614}], length 0
  18:28:47.018160 IP auth.docker.io.https > 192.168.0.107.33762: Flags [P.], seq 134:166, ack 251, win 7, options [nop,nop,TS val 1908252064 ecr 3041932655], length 32
  18:28:47.018187 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [.], ack 1614, win 491, options [nop,nop,TS val 3041932756 ecr 1908252064], length 0
  18:28:47.018228 IP auth.docker.io.https > 192.168.0.107.33762: Flags [P.], seq 1614:5292, ack 251, win 7, options [nop,nop,TS val 1908252064 ecr 3041932655], length 3678
  18:28:47.018257 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [.], ack 5292, win 463, options [nop,nop,TS val 3041932756 ecr 1908252064], length 0
  18:28:47.018818 IP auth.docker.io.https > 192.168.0.107.33762: Flags [P.], seq 5292:5578, ack 251, win 7, options [nop,nop,TS val 1908252064 ecr 3041932655], length 286
  18:28:47.018851 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [.], ack 5578, win 461, options [nop,nop,TS val 3041932757 ecr 1908252064], length 0
  18:28:47.018875 IP auth.docker.io.https > 192.168.0.107.33762: Flags [P.], seq 5578:5636, ack 251, win 7, options [nop,nop,TS val 1908252065 ecr 3041932655], length 58
  18:28:47.018904 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [.], ack 5636, win 461, options [nop,nop,TS val 3041932757 ecr 1908252065], length 0
  18:28:47.034412 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [P.], seq 251:315, ack 5636, win 501, options [nop,nop,TS val 3041932773 ecr 1908252065], length 64
  18:28:47.034822 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [P.], seq 315:649, ack 5636, win 501, options [nop,nop,TS val 3041932773 ecr 1908252065], length 334
  18:28:47.136908 IP auth.docker.io.https > 192.168.0.107.33762: Flags [.], ack 649, win 8, options [nop,nop,TS val 1908252182 ecr 3041932773], length 0
  18:28:47.142821 IP auth.docker.io.https > 192.168.0.107.33762: Flags [.], seq 5636:7084, ack 649, win 8, options [nop,nop,TS val 1908252188 ecr 3041932773], length 1448
  18:28:47.142892 IP auth.docker.io.https > 192.168.0.107.33762: Flags [P.], seq 7084:11274, ack 649, win 8, options [nop,nop,TS val 1908252188 ecr 3041932773], length 4190
  18:28:47.142985 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [.], ack 11274, win 501, options [nop,nop,TS val 3041932881 ecr 1908252188], length 0
  18:28:47.143777 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [P.], seq 649:673, ack 11274, win 501, options [nop,nop,TS val 3041932882 ecr 1908252188], length 24
  18:28:47.143858 IP 192.168.0.107.33762 > auth.docker.io.https: Flags [F.], seq 673, ack 11274, win 501, options [nop,nop,TS val 3041932882 ecr 1908252188], length 0

dannthi avatar Feb 20 '24 17:02 dannthi

I am having this same issue on raspberry pi 3b+ that is running on raspbian 32bit. I am in a ipv4 only environment and have tried all of the things mentioned here in the thread, in addition to that I have added the "ipv6":false flag to daemon.json. So far I haven't had the ability to make this work.

TheRiotJoker avatar Feb 28 '24 22:02 TheRiotJoker

I am getting a similar, if not the same, error when trying to pull a docker image. It's not specific to IPv4 and I have IPv6 enabled on my Ubuntu server.

When I try to run: docker pull node:20-bullseye-slim

This is the error I am getting: Error response from daemon: received unexpected HTTP status: 500 Server Error

Trying to curl -v https://auth.docker.com I get the following:

* processing: https://auth.docker.com
*   Trying [2600:1f18:2148:bc00:8d61:9b62:40aa:8bb8]:443...
* Connected to auth.docker.com (2600:1f18:2148:bc00:8d61:9b62:40aa:8bb8) port 443
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=*.docker.com
*  start date: Oct  2 00:00:00 2023 GMT
*  expire date: Oct 31 23:59:59 2024 GMT
*  subjectAltName: host "auth.docker.com" matched cert's "*.docker.com"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
*  SSL certificate verify ok.
* using HTTP/1.x
> GET / HTTP/1.1
> Host: auth.docker.com
> User-Agent: curl/8.2.1
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 500 Server Error
< cache-control: no-cache
< content-type: text/html
<
<html><body><h1>500 Server Error</h1>
An internal server error occured.
</body></html>

* TLSv1.3 (IN), TLS alert, close notify (256):
* Closing connection
* TLSv1.3 (OUT), TLS alert, close notify (256):

Trying to curl registry-1.docker.io I also get:

* processing: https://registry-1.docker.io
*   Trying [2600:1f18:2148:bc02:445d:9ace:d20b:c303]:443...
* Connected to registry-1.docker.io (2600:1f18:2148:bc02:445d:9ace:d20b:c303) port 443
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=*.docker.com
*  start date: Oct  2 00:00:00 2023 GMT
*  expire date: Oct 31 23:59:59 2024 GMT
*  subjectAltName: host "registry-1.docker.io" matched cert's "*.docker.io"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
*  SSL certificate verify ok.
* using HTTP/1.x
> GET / HTTP/1.1
> Host: registry-1.docker.io
> User-Agent: curl/8.2.1
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 500 Server Error
< cache-control: no-cache
< content-type: text/html
<
<html><body><h1>500 Server Error</h1>
An internal server error occured.
</body></html>

* TLSv1.3 (IN), TLS alert, close notify (256):
* Closing connection
* TLSv1.3 (OUT), TLS alert, close notify (256):

Trying to curl -v https://production.cloudflare.docker.com I get:

* processing: https://production.cloudflare.docker.com/
*   Trying [2606:4700::6810:64cf]:443...
* Connected to production.cloudflare.docker.com (2606:4700::6810:64cf) port 443
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=sni.cloudflaressl.com
*  start date: May 12 00:00:00 2023 GMT
*  expire date: May 11 23:59:59 2024 GMT
*  subjectAltName: host "production.cloudflare.docker.com" matched cert's "production.cloudflare.docker.com"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  SSL certificate verify ok.
* using HTTP/2
* h2 [:method: GET]
* h2 [:scheme: https]
* h2 [:authority: production.cloudflare.docker.com]
* h2 [:path: /]
* h2 [user-agent: curl/8.2.1]
* h2 [accept: */*]
* Using Stream ID: 1
> GET / HTTP/2
> Host: production.cloudflare.docker.com
> User-Agent: curl/8.2.1
> Accept: */*
>
< HTTP/2 403
< date: Mon, 18 Mar 2024 18:25:29 GMT
< content-type: application/json
< content-length: 55
< server: cloudflare
< cf-ray: 866743fe3a84225e-ORD
<
* Connection #0 to host production.cloudflare.docker.com left intact

Any help would be greatly appreciated in resolving this. If I should open a new issues, please let me know. Thanks in advance.

BDAthans avatar Mar 18 '24 18:03 BDAthans

Got the issue too. Windows 11, WSL, Ubuntu

naxim92 avatar Jul 10 '24 18:07 naxim92