You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A traceroute (TCP) command would show the middle hops
root@cmp-mac-gbarcotti:/# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 172.20.0.1 (172.20.0.1) 1.062 ms 0.982 ms 0.942 ms
2 hitronhub.home (192.168.0.1) 3.584 ms 4.599 ms 4.536 ms
3 * * *
4 rc1st-be164-1.vc.shawcable.net (64.59.148.125) 22.687 ms 21.090 ms 21.022 ms
5 rc2wt-be50-1.wa.shawcable.net (66.163.70.106) 35.724 ms 36.159 ms 36.317 ms
6 72.14.242.90 (72.14.242.90) 34.276 ms 40.536 ms 40.390 ms
7 * * *
8 dns.google (8.8.8.8) 27.897 ms 24.358 ms 28.457 ms
Actual behavior
A traceroute (TCP) command shows only 2 hops (the docker bridge and the target)
root@cmp-mac-gbarcotti:/# traceroute -T -p 443 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 172.20.0.1 (172.20.0.1) 0.114 ms 0.047 ms 0.118 ms
2 dns.google (8.8.8.8) 27.705 ms 29.068 ms 29.384 ms
Information
The issue is 100% reproducible
macOS Version: Catalina 10.15.5
Root cause of the issue:
Looking at the packet capture obtained inside the container (tcpdump in the container) it is possible to see that the container traceroute application generates IPv4 TCP SYN requests with increasing TTL numbers (trace route typical approach), however, the corresponding packet capture from the host (MAC) shows that the TTL numbers for the TCP SYN messages get changed to a constant number (64) therefore the packets get a response directly from the target and not (ICMP TTL time exceeded from the middle hops). This completely breaks TCP traceroute.
Notes:
. ICMP and UDP traceroute works. in the ICMP and UDP cases, the TTL of the requests is only decremented by 1 (to account for the docker bridge hop) when they leave the host machine (MAC).
. The same result is observed for docker bridged or host networking
Diagnostic logs
No Diagnostics logs
Docker for Mac:
JLTM120:cmp-mac-gbarcotti gbarcotti$ docker version
Client: Docker Engine - Community
Version: 19.03.8
API version: 1.40
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:21:11 2020
OS/Arch: darwin/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.12)
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:29:16 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version: 0.18.0
GitCommit: fec3683
Dockerfile
FROM debian:stable
RUN apt-get update && apt-get install traceroute
Steps to reproduce the behaviour (Just run the following commands on a MAC term/shell
mkdir scratch
cat >Dockerfile <<EOF
FROM debian:stable
RUN apt-get update && apt-get install traceroute
EOF
docker image build --tag tracerouterepro:latest .
docker run -ti tracerouterepro:latest /usr/bin/traceroute -T -p 443 8.8.8.8
The text was updated successfully, but these errors were encountered:
Expected behavior
A traceroute (TCP) command would show the middle hops
root@cmp-mac-gbarcotti:/# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 172.20.0.1 (172.20.0.1) 1.062 ms 0.982 ms 0.942 ms
2 hitronhub.home (192.168.0.1) 3.584 ms 4.599 ms 4.536 ms
3 * * *
4 rc1st-be164-1.vc.shawcable.net (64.59.148.125) 22.687 ms 21.090 ms 21.022 ms
5 rc2wt-be50-1.wa.shawcable.net (66.163.70.106) 35.724 ms 36.159 ms 36.317 ms
6 72.14.242.90 (72.14.242.90) 34.276 ms 40.536 ms 40.390 ms
7 * * *
8 dns.google (8.8.8.8) 27.897 ms 24.358 ms 28.457 ms
Actual behavior
A traceroute (TCP) command shows only 2 hops (the docker bridge and the target)
root@cmp-mac-gbarcotti:/# traceroute -T -p 443 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 172.20.0.1 (172.20.0.1) 0.114 ms 0.047 ms 0.118 ms
2 dns.google (8.8.8.8) 27.705 ms 29.068 ms 29.384 ms
Information
Looking at the packet capture obtained inside the container (tcpdump in the container) it is possible to see that the container traceroute application generates IPv4 TCP SYN requests with increasing TTL numbers (trace route typical approach), however, the corresponding packet capture from the host (MAC) shows that the TTL numbers for the TCP SYN messages get changed to a constant number (64) therefore the packets get a response directly from the target and not (ICMP TTL time exceeded from the middle hops). This completely breaks TCP traceroute.
Notes:
. ICMP and UDP traceroute works. in the ICMP and UDP cases, the TTL of the requests is only decremented by 1 (to account for the docker bridge hop) when they leave the host machine (MAC).
. The same result is observed for docker bridged or host networking
Diagnostic logs
No Diagnostics logs
Dockerfile
Steps to reproduce the behaviour (Just run the following commands on a MAC term/shell
The text was updated successfully, but these errors were encountered: