TCP muere en una computadora portátil Linux

17

Una vez en varios días tengo el siguiente problema. Mi computadora portátil (prueba de Debian) de repente no puede trabajar con conexiones TCP a Internet.

Las siguientes cosas siguen funcionando bien:

  • UDP (DNS), ICMP (ping): obtengo una respuesta instantánea
  • Conexiones TCP a otras máquinas en la red local (por ejemplo, puedo enviar un ssh a una computadora portátil vecina)
  • todo está bien para otras máquinas en mi LAN

Pero cuando intento conexiones TCP desde mi computadora portátil, se agota el tiempo de espera (sin respuesta a los paquetes SYN). Aquí hay una salida de rizo típica:

% curl -v google.com     
* About to connect() to google.com port 80 (#0)
*   Trying 173.194.39.105...
* Connection timed out
*   Trying 173.194.39.110...
* Connection timed out
*   Trying 173.194.39.97...
* Connection timed out
*   Trying 173.194.39.102...
* Timeout
*   Trying 173.194.39.98...
* Timeout
*   Trying 173.194.39.96...
* Timeout
*   Trying 173.194.39.103...
* Timeout
*   Trying 173.194.39.99...
* Timeout
*   Trying 173.194.39.101...
* Timeout
*   Trying 173.194.39.104...
* Timeout
*   Trying 173.194.39.100...
* Timeout
*   Trying 2a00:1450:400d:803::1009...
* Failed to connect to 2a00:1450:400d:803::1009: Network is unreachable
* Success
* couldn't connect to host
* Closing connection #0
curl: (7) Failed to connect to 2a00:1450:400d:803::1009: Network is unreachable

Reiniciar la conexión y / o volver a cargar el módulo del núcleo de la tarjeta de red no ayuda. Lo único que ayuda es reiniciar.

Claramente, algo está mal con mi sistema (todo lo demás funciona bien), pero no tengo idea de qué es exactamente.

Mi configuración es un enrutador inalámbrico que está conectado al ISP a través de PPPoE.

¿Algún consejo?

Respuestas a comentarios

¿Qué NIC es?

12:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
  Subsystem: Dell Inspiron M5010 / XPS 8300
  Flags: bus master, fast devsel, latency 0, IRQ 17
  Memory at fbb00000 (64-bit, non-prefetchable) [size=16K]
  Capabilities: [40] Power Management version 3
  Capabilities: [58] Vendor Specific Information: Len=78 <?>
  Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
  Capabilities: [d0] Express Endpoint, MSI 00
  Capabilities: [100] Advanced Error Reporting
  Capabilities: [13c] Virtual Channel
  Capabilities: [160] Device Serial Number 00-00-9d-ff-ff-aa-1c-65
  Capabilities: [16c] Power Budgeting <?>
  Kernel driver in use: brcmsmac

¿Cuál es el estado de su NIC cuando ocurre el problema?

iptables-save No imprime nada.

ip rule show:

0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default

ip route show table all:

default via 192.168.1.1 dev wlan0 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.105 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.1.0 dev wlan0  table local  proto kernel  scope link  src 192.168.1.105 
local 192.168.1.105 dev wlan0  table local  proto kernel  scope host  src 192.168.1.105 
broadcast 192.168.1.255 dev wlan0  table local  proto kernel  scope link  src 192.168.1.105 
fe80::/64 dev wlan0  proto kernel  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101 hoplimit 255
local ::1 via :: dev lo  table local  proto none  metric 0 
local fe80::1e65:9dff:feaa:b1f1 via :: dev lo  table local  proto none  metric 0 
ff00::/8 dev wlan0  table local  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101 hoplimit 255

Todo lo anterior es igual cuando la máquina funciona en modo normal.

ifconfig- Lo ejecuté, pero de alguna manera olvidé guardar antes de reiniciar. Tendrá que esperar hasta la próxima vez que ocurra el problema. Lo siento por eso.

¿Alguna QoS en su lugar?

Probablemente no, al menos no he hecho nada específicamente para habilitarlo.

¿Has intentado oler el tráfico realmente enviado en la interfaz?

Ejecuté curl y tcpdump varias veces, y había dos patrones.

El primero es solo paquetes SYN sin respuestas.

17:14:37.836917 IP (tos 0x0, ttl 64, id 4563, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42030 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0xbea8), seq 3764607647, win 13600, options [mss 1360,sackOK,TS val 33770316 ecr 0,nop,wscale 4], length 0
17:14:38.836650 IP (tos 0x0, ttl 64, id 4564, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42030 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0xbdae), seq 3764607647, win 13600, options [mss 1360,sackOK,TS val 33770566 ecr 0,nop,wscale 4], length 0
17:14:40.840649 IP (tos 0x0, ttl 64, id 4565, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42030 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0xbbb9), seq 3764607647, win 13600, options [mss 1360,sackOK,TS val 33771067 ecr 0,nop,wscale 4], length 0

El segundo es este:

17:22:56.507827 IP (tos 0x0, ttl 64, id 41583, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0x2244), seq 1564709704, win 13600, options [mss 1360,sackOK,TS val 33894944 ecr 0,nop,wscale 4], length 0
17:22:56.546763 IP (tos 0x58, ttl 54, id 65442, offset 0, flags [none], proto TCP (6), length 60)
    fra07s07-in-f102.1e100.net.http > 192.168.1.105.42036: Flags [S.], cksum 0x6b1e (correct), seq 1407776542, ack 1564709705, win 14180, options [mss 1430,sackOK,TS val 3721836586 ecr 33883552,nop,wscale 6], length 0
17:22:56.546799 IP (tos 0x58, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [R], cksum 0xf301 (correct), seq 1564709705, win 0, length 0
17:22:58.511843 IP (tos 0x0, ttl 64, id 41584, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0x204f), seq 1564709704, win 13600, options [mss 1360,sackOK,TS val 33895445 ecr 0,nop,wscale 4], length 0
17:22:58.555423 IP (tos 0x58, ttl 54, id 65443, offset 0, flags [none], proto TCP (6), length 60)
    fra07s07-in-f102.1e100.net.http > 192.168.1.105.42036: Flags [S.], cksum 0x3b03 (correct), seq 1439178112, ack 1564709705, win 14180, options [mss 1430,sackOK,TS val 3721838596 ecr 33883552,nop,wscale 6], length 0
17:22:58.555458 IP (tos 0x58, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [R], cksum 0xf301 (correct), seq 1564709705, win 0, length 0

salida de ethtool

ethtool -k wlan0:

Features for wlan0:
rx-checksumming: off [fixed]
tx-checksumming: off
  tx-checksum-ipv4: off [fixed]
  tx-checksum-unneeded: off [fixed]
  tx-checksum-ip-generic: off [fixed]
  tx-checksum-ipv6: off [fixed]
  tx-checksum-fcoe-crc: off [fixed]
  tx-checksum-sctp: off [fixed]
scatter-gather: off
  tx-scatter-gather: off [fixed]
  tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
  tx-tcp-segmentation: off [fixed]
  tx-tcp-ecn-segmentation: off [fixed]
  tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: on [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]

iptables

# namei -l "$(command -v iptables)"
f: /sbin/iptables
drwxr-xr-x root root /
drwxr-xr-x root root sbin
lrwxrwxrwx root root iptables -> xtables-multi
-rwxr-xr-x root root   xtables-multi

# dpkg -S "$(command -v iptables)"
iptables: /sbin/iptables

# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# iptables -t security -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

información del módulo

# ethtool -i wlan0                   
driver: brcmsmac
version: 3.2.0-3-686-pae
firmware-version: N/A
bus-info: 0000:12:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

# modinfo brcmsmac
filename:       /lib/modules/3.2.0-3-686-pae/kernel/drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko
license:        Dual BSD/GPL
description:    Broadcom 802.11n wireless LAN driver.
author:         Broadcom Corporation
alias:          pci:v000014E4d00000576sv*sd*bc*sc*i*
alias:          pci:v000014E4d00004727sv*sd*bc*sc*i*
alias:          pci:v000014E4d00004353sv*sd*bc*sc*i*
alias:          pci:v000014E4d00004357sv*sd*bc*sc*i*
depends:        mac80211,brcmutil,cfg80211,cordic,crc8
intree:         Y
vermagic:       3.2.0-3-686-pae SMP mod_unload modversions 686

No hay es /sys/module/brcmsmac/parameters. Esto es lo que tengo allí:

# tree /sys/module/brcmsmac
/sys/module/brcmsmac
├── drivers
│   └── pci:brcmsmac -> ../../../bus/pci/drivers/brcmsmac
├── holders
├── initstate
├── notes
├── refcnt
├── sections
│   └── __bug_table
└── uevent

Algunos sitios realmente funcionan

Según lo sugerido por el Dr. , probé algunos otros sitios, y para mi gran sorpresa, algunos de ellos realmente funcionaron. Aquí hay algunos hosts que funcionaron:

  • rambler.ru
  • google.ru
  • ya.ru
  • opennet.ru
  • tut.by
  • ro-che.info
  • yahoo.com
  • ebay.com

Y aquí hay algunos que no lo hicieron:

  • vk.com
  • meta.ua
  • ukr.net
  • tenet.ua
  • prom.ua
  • reddit.com
  • github.com
  • stackexchange.com

Captura de red

Hice una captura de red y la cargué aquí .

debian  networking  tcp 
— Roman Cheplyaka
fuente
1
Solo por curiosidad: ¿Cuál es el estado de su NIC cuando ocurre el problema? (/ sbin / ifconfig?)
— yves Baumes
¿Has intentado oler el tráfico realmente enviado en la interfaz (wireshark / tcpdump ...)? ¿Qué NIC es? ¿Es inalámbrico? ¿Cuál es la salida iptables-save, de ip rule show, ip route show table all. ¿Alguna QoS en su lugar?
— Stéphane Chazelas
Se actualizó la publicación con respuestas a sus preguntas.
— Roman Cheplyaka
1
No construí controladores desde la fuente. El módulo en sí proviene del núcleo de Debian (paquete linux-image-3.2.0-3-686-pae), y el firmware proviene del firmware-brcm80211paquete. ¿Tuviste problemas similares a los míos? Prefiero evitar construir cosas a mano, a menos que sea un problema conocido. Además, ¿por qué un problema del módulo NIC se manifestaría en la capa 4?
— Roman Cheplyaka
1
Lo más probable es que lo que esté mal esté en su estación base, conmutador o enrutador Wi-Fi. Si es posible, intente rastrear paquetes (o recuentos de paquetes) allí. Si no, intente intercambiarlos con alternativas.
— bahamat

Respuestas:

5

En la captura que proporcionó, la respuesta de eco de sello de tiempo en el SYN-ACK en el segundo paquete no coincide con el TSVal en el SYN en el primer paquete y está unos segundos atrás.

Y vea cómo todos los TSecr enviados por 173.194.70.108 y 209.85.148.100 son todos iguales e irrelevantes desde el TSVal que envía.

Parece que hay algo que se mezcla con las marcas de tiempo TCP. No tengo idea de qué puede estar causando eso, pero parece que está fuera de su máquina. ¿Reiniciar el enrutador ayuda en esta instancia?

No sé si es lo que está causando que su máquina envíe un RST (en el tercer paquete). Pero definitivamente no le gusta ese SYN-ACK, y es lo único malo que puedo encontrar al respecto. La única otra explicación que se me ocurre es que si no es su máquina la que envía el RST, pero dada la diferencia horaria entre el SYN-ACK y el RST, lo dudaría. Pero por si acaso, ¿utiliza máquinas virtuales o contenedores o espacios de nombres de red en esta máquina?

Puede intentar deshabilitar las marcas de tiempo TCP por completo para ver si eso ayuda:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Entonces, esos sitios envían TSecr falso o hay algo en el camino (cualquier enrutador en camino o proxy transparente) que destruye el TSVal saliente o el TSecr entrante, o un proxy con una pila TCP falsa. Por qué uno destrozaría las marcas de tiempo de tcp solo puedo especular: error, evasión de detección de intrusos, un algoritmo de conformación de tráfico demasiado inteligente / falso. Eso no es algo que haya escuchado antes (pero tampoco soy un experto en el tema).

Cómo investigar más a fondo:

  • Vea si el enrutador TPLink tiene la culpa de por qué reiniciarlo para ver si eso ayuda o captura el tráfico en el exterior también, si es posible, para ver si estropea las marcas de tiempo
  • Verifique si hay un proxy transparente en camino jugando con TTL, mirando los encabezados de solicitud recibidos por los servidores web o vea el comportamiento al solicitar sitios web muertos.
  • capturar el tráfico en un servidor web remoto para ver si se trata de TSVal o TSecr.
— Stéphane Chazelas
fuente
No, no tenía ningún vms / contenedor ejecutándose. Probaré tus sugerencias la próxima vez, gracias.
— Roman Cheplyaka
1
Xm .. Su sugerencia sobre tcp_timestamps definitivamente resuelve mi problema. No hay ningún problema con google y otros sitios web después de configurar net.ipv4.tcp_timestamps en 0 y todos los problemas nuevamente en caso de net.ipv4.tcp_timestamps = 1 pero ¿POR QUÉ?
— dr.
1

Dice suma de verificación incorrecta arriba. ¿Hay una descarga de suma de verificación para ese dispositivo (no sabía que los dispositivos inalámbricos podrían descargar sumas de verificación).

¿Qué sudo ethtool -k wlan0te dice? Si hay una descarga, puede intentar desactivarla.

Debe ser root para llamar a iptables-save. Todavía hay una remota posibilidad de que algo esté destrozando paquetes allí. Si iptables-saveno funciona, intente:

iptables -nvL
iptables -t mangle -nvL
iptables -t nat -nvL
iptables -t security -nvL

En su captura de red, ¿la dirección MAC de destino coincide con la del enrutador? ¿Algo interesante en una comparación del tráfico UDP al tráfico TCP?

Además, ¿dónde $devestá el controlador del kernel (módulo) (consulte ethtool -i wlan0) para su adaptador inalámbrico, qué hacer modinfo "$dev"y qué grep . /sys/module/"$dev"/parameters/*decirle?

— Stéphane Chazelas
fuente
¡Buena atrapada! No noté las sumas de verificación incorrectas. Actualizaré la respuesta con la salida de ethtool. iptables-save se ejecutó como root, no imprime nada. La próxima vez volveré a ejecutar tcpdump para mostrar las direcciones MAC.
— Roman Cheplyaka
Si iptables-save no devuelve nada, entonces hay algo definitivamente mal. ¿Qué hacer namei -l "$(command -v iptables)"y dpkg -S "$(command -v iptables)"decirte?
— Stéphane Chazelas
Publicado el resultado.
— Roman Cheplyaka
Se actualizó la publicación con información del módulo.
— Roman Cheplyaka
Gracias. Ver mis ediciones a mi respuesta. ¿También puede pegar un pcap para su captura en algún lugar, o tal vez la salida de tshark -Viwlan0 tcpuno de esos paquetes SYN aquí?
— Stéphane Chazelas
1

Parece que tengo exactamente el mismo comportamiento en mi computadora portátil también. No sé la razón, pero de vez en cuando no pude conectarme a google.com y algunos otros recursos externos. Pings y consultas DNS funcionan perfectamente. También he encontrado una sola solución: reiniciar .

Podría agregar varias observaciones:

  1. Si inicio algún otro sistema operativo en mi Virtual Box (Windows, ArchLinux, Ubuntu), podría establecer conexiones TCP con hosts problemáticos sin ningún problema.
  2. Algunos de los hosts en Internet se comportan como google.com, pero hay muchos de ellos, a los que normalmente se puede acceder mediante telnet o navegador web
  3. No tengo un adaptador WIFI en mi computadora portátil, solo tengo un enlace Ethernet al enrutador
  4. He intentado pasar al espacio de usuario de debian / gentoo, no ayuda
  5. He reemplazado mi NIC por la nueva, no ayuda

Alguna información técnica sobre mi caja:

SO: Último ArchLinux amd64

$ ethtool -i  eth0
driver: via-rhine
version: 1.5.0
firmware-version: 
bus-info: 0000:02:07.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

$uname -a
Linux eniac-2 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 08:12:04 CEST 2012 x86_64 GNU/Linux

Supongo que este comportamiento defectuoso ocurre debido a algún error sutil en algunas versiones del kernel de Linux, pero no sé cómo depurar este problema, y ​​debido a la reproducción inestable, estoy atascado.

— Dr.
fuente
¡Gracias por compartir! ¿Cuáles son algunos ejemplos de hosts que funcionan?
— Roman Cheplyaka
Ejemplos de hosts, que funcionan cuando se produce este comportamiento defectuoso: opennet.ru, tut.by.
— dr.
Ahora estoy convencido de que realmente tenemos el mismo problema ...
— Roman Cheplyaka
¡Si! Estoy de acuerdo. Estoy pensando en actualizar el firmware de mi enrutador en algo como dd-wrt o openwrt, o simplemente degradar el kernel de Linux. ¿Has probado alguno de estos pasos?
— dr.
1
No. Sin embargo, me encantaría saber qué demonios está pasando aquí.
— Roman Cheplyaka
0 
/sbin/iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Tuve el mismo problema que describiste hasta que agregué el comando anterior a mis comandos de iptables de la puerta de enlace de Internet. En se incluye por defecto en el paquete rp-pppoe y otros. Pero cuando elija configuraciones personalizadas y no las configure manualmente, las computadoras en la LAN detrás de la puerta de enlace tendrán los problemas que usted describe.

— Kostya Berger
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.