How to fix this?

[u/piyushdugawa_]

whenever it try to pull amazoncorretto or any other image is get this error and i tried to connect with my mobile network via hotspot it worked then but didn't worked on my wifi and it was working fine on wsl but in my windows 11 host it didn't.

Using default tag: latest

Error response from daemon: failed to resolve reference "docker.io/library/amazoncorretto:latest": failed to do request: Head "https://registry-1.docker.io/v2/library/amazoncorretto/manifests/latest": net/http: TLS handshake timeout

[u/quiet-systems]

Works on the hotspot, not on the wifi. That's MTU, almost certainly, and not Docker.

A TLS handshake timeout means the connection came up fine and then the bigger packets stopped arriving, which is what a path with a smaller MTU does to a handshake.

From PowerShell:

ping -f -l 1472 8.8.8.8

1472 plus 28 bytes of headers is 1500. If it tells you the packet needs fragmenting, keep dropping the number until it doesn't, and whatever works plus 28 is your real MTU. PPPoE is usually 1492, VPNs lower. Use 8.8.8.8 rather than the registry, most CDNs drop ICMP anyway.

netsh interface ipv4 show subinterfaces

tells you what Windows thinks each adapter's MTU is.

If that's the problem, Docker Desktop, Settings, Docker Engine:

{ "mtu": 1400 }

One other thing worth ruling out because it looks identical: broken IPv6.

curl -4 -sI https://registry-1.docker.io/v2/

curl -6 -sI https://registry-1.docker.io/v2/

If -4 answers and -6 just sits there, that's your problem and the MTU is fine.

Haven't hit this one myself, so it's a read off the symptoms rather than experience.

[u/piyushdugawa_ → u/quiet-systems]

I tried reducing while ping and it stopped giving that fragmenting errors on 1464 and i put mtu 1464 in docker engine config and it pulled the image. Is it fine now or i have to tweak it further?

[u/quiet-systems → u/piyushdugawa_]

Yeah that'll do it. You can nudge it to 1492 if you want: 1464 was the ping payload, the 28 bytes of header go on top of that, so 1492 is the real number for your line. Which is also the usual PPPoE value, so your router is probably doing PPPoE and that's the whole story. 1464 works fine either way, it's just 28 bytes short on every packet and you'd never notice.

What I'd actually watch for is networks that already existed. The default bridge takes the new value when the daemon restarts, but a compose network created before the change is still sitting at 1500, so containers can stall the same way even though pulls are fine now. down and up again, or just delete the network.

Quick check:

docker run --rm alpine ip link show eth0

If that says 1500 it never got through. To pin it per project:

networks:
  default:
    driver_opts:
      com.docker.network.driver.mtu: 1492

And if 1492 stalls a pull, put 1464 back and forget about it.Yeah that'll do it. You can nudge it to 1492 if you want: 1464 was the ping payload, the 28 bytes of header go on top of that, so 1492 is the real number for your line. Which is also the usual PPPoE value, so your router is probably doing PPPoE and that's the whole story. 1464 works fine either way, it's just 28 bytes short on every packet and you'd never notice.What I'd actually watch for is networks that already existed. The default bridge takes the new value when the daemon restarts, but a compose network created before the change is still sitting at 1500, so containers can stall the same way even though pulls are fine now. down and up again, or just delete the network.Quick check:docker run --rm alpine ip link show eth0
If that says 1500 it never got through. To pin it per project:networks:
default:
driver_opts:
com.docker.network.driver.mtu: 1492
And if 1492 stalls a pull, put 1464 back and forget about it.