TRACEROUTE (TCP) does not show middle hops as the TTL from the requests is changed to a fixed value
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- docker, macos
- Área
- networking
Línea de trabajo
Comienza reproduciendo el problema con el Dockerfile proporcionado y el comando /usr/bin/traceroute -T -p 443 8.8.8.8; después, compara las capturas de paquetes del contenedor y del host descritas en el informe. Rastrea dónde se reescriben los valores TTL de los TCP SYN en Docker for Mac y verifica que la ejecución se complete cuando aparecen saltos intermedios, mientras el comportamiento de ICMP y UDP permanece sin cambios.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- 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
- Lenguaje dominante
- OCaml
- Estrellas
- 1.2k
- Forks
- 213
- Merge medio
- 20 min
- PR fusionados (30 d)
- 1
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de moby/vpnkit
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
-
Compilation error due to "Unbound module Ethernet__Ethernet_wire"Quizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Todos los issues de moby/vpnkit
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
YunoHost-Apps/coturn_ynh#49 ·
-
net.fetch triggers unhandled promise rejection and hangs indefinitely when request body stream failsAbiertoblocked/need-info ❌ bug :beetle: platform/all
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
electron/electron#55372 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Nest RTSP (Google Device Access): Google's server ignores requests unless CSeq is the first headerAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
Los mantenedores suelen responder en 1 día
-
http3: don’t allow writing DATA on a hijacked stream before the response headerPosiblemente ocupada @marten-seemann la tomó hoy. AbiertoAPI enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día