Closed mterron closed 8 years ago
Thanks for the report. On my machine it doesn't seem to reproduce:
$ docker run -it --rm busybox:musl ping github.com
PING github.com (192.30.253.113): 56 data bytes
64 bytes from 192.30.253.113: seq=0 ttl=37 time=0.135 ms
64 bytes from 192.30.253.113: seq=1 ttl=37 time=0.481 ms
Unfortunately I can't examine the diagnostic upload from my current location, but could there be a problem with choosing the wrong DNS server? Do you have a VPN (or other DNS interceptor) set up which could offer a bad address? A known problem with the DNS logic on Docker for Mac is that we don't currently respect the "zone" information visible from scutil --dns
, which is used by VPN/DNS software to (for example) forward requests for *.intranet
to an internal server while leaving *.com
alone.
If it doesn't sound VPN/DNS interceptor related, could you try capturing some packets from the VM? There's built-in capture support which is enabled like this:
cd ~/Library/Containers/com.docker.docker/Data/database/
git reset --hard
echo /tmp/dns.pcap > com.docker.driver.amd64-linux/slirp/capture
git add com.docker.driver.amd64-linux/slirp/capture
git commit -m "enable capturing"
-- now the first 16MiB of traffic send and received by the VM will be written to /tmp/dns.pcap
. On VM restart the file is truncated. After a few pings I have:
$ ls -l /tmp/dns.pcap
-rw-r--r-- 1 djs wheel 2234 11 Sep 09:38 /tmp/dns.pcap
To disable it again:
cd ~/Library/Containers/com.docker.docker/Data/database/
git reset --hard
git rm com.docker.driver.amd64-linux/slirp/capture
git commit -m "disable capturing"
(at some point we should automate this with a docker run
)
capture.zip This is a recently installed mac, no VPN or interception software. It is running the latest El Capitan. I captured the container traffic and it shows that the DNS server 192.168.65.3 (default config) responds with the 198.18 address.
I figured this one out. It turns out that my stupid ISP was doing some weird stuff with DNS. As soon as I changed the (default) DNS to 8.8.8.8 everything started working as expected.
Thanks :)
I'm glad it's working for you!
Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.
If you have found a problem that seems similar to this, please open a new issue.
Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle locked
There is a conflict between busybox:musl and Docker for mac. It resolves any URL to an IP at the 198.18.x.x block. Using normal uclibc busybox works as expected.
Expected behavior
docker run -it --rm busybox:musl ping github.com PING github.com (192.30.253.113): 56 data bytes 64 bytes from 192.30.253.113: seq=0 ttl=37 time=0.783 ms 64 bytes from 192.30.253.113: seq=1 ttl=37 time=0.640 ms
Actual behavior
docker run -it --rm busybox:musl ping github.com PING github.com (198.18.1.206): 56 data bytes 64 bytes from 198.18.1.206: seq=0 ttl=37 time=1.372 ms 64 bytes from 198.18.1.206: seq=1 ttl=37 time=0.595 ms
Information
Any URL resolves to the reserved 198.18 block; this only happen in Docker for Mac and not on linux when using the busybox:musl image. As per IANA, that block is reserved: Addresses starting with "198.18." or "198.19." are set aside for use in isolated laboratory networks used for benchmarking and performance testing. They should never appear on the Internet and if you see Internet traffic using these addresses, they are being used without permission.
Diagnostic ID: DA9E8347-1675-43AD-B9F4-0525946FF2CB Docker for Mac: 1.12.0-a (Build 11213) macOS: Version 10.11.6 (Build 15G1004) [OK] docker-cli [OK] app [OK] moby-syslog [OK] disk [OK] virtualization [OK] system [OK] menubar [OK] osxfs [OK] db [OK] slirp [OK] moby-console [OK] logs [OK] vmnetd [OK] env [OK] moby [OK] driver.amd64-linux
Steps to reproduce