TCP morre em um laptop Linux

17

Uma vez em vários dias, tenho o seguinte problema. Meu laptop (teste Debian) de repente se torna incapaz de funcionar com conexões TCP à Internet.

As seguintes coisas continuam funcionando bem:

  • UDP (DNS), ICMP (ping) - recebo resposta instantânea
  • Conexões TCP com outras máquinas na rede local (por exemplo, eu posso ssh para um laptop vizinho)
  • está tudo bem para outras máquinas na minha LAN

Mas quando tento conexões TCP no meu laptop, elas atingem o tempo limite (sem resposta aos pacotes SYN). Aqui está uma saída de curvatura 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 a conexão e / ou recarregar o módulo do kernel da placa de rede não ajuda. A única coisa que ajuda é reiniciar.

Claramente, algo está errado com meu sistema (tudo funciona bem), mas não tenho idéia do que exatamente.

Minha configuração é um roteador sem fio conectado ao ISP via PPPoE.

Algum conselho?

Respostas aos comentários

O que é NIC?

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

Qual é o estado da sua NIC quando o problema ocorre?

iptables-save 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

Todas as opções acima são as mesmas quando a máquina trabalha no modo normal.

ifconfig- Eu executei, mas de alguma forma esqueci de salvar antes de reiniciar. Terá que esperar até a próxima vez que o problema ocorrer. Me desculpe por isso.

Alguma QoS no lugar?

Provavelmente não - pelo menos não fiz nada especificamente para habilitá-lo.

Você já tentou cheirar o tráfego realmente enviado na interface?

Corri curl e tcpdump várias vezes e havia dois padrões.

O primeiro são apenas pacotes SYN sem respostas.

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

O segundo é o seguinte:

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

saída de ettool

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

informações do 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

Não tem /sys/module/brcmsmac/parameters. Aqui está o que eu tenho lá:

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

Alguns sites realmente funcionam

Como sugerido pelo dr , tentei outros sites e, para minha grande surpresa, alguns deles realmente funcionaram. Aqui estão alguns hosts que funcionaram:

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

E aqui estão alguns que não:

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

Captura de rede

Eu fiz uma captura de rede e carreguei aqui .

debian  networking  tcp 
— Roman Cheplyaka
fonte
1
Apenas por curiosidade: Qual é o estado da sua NIC quando o problema ocorre? (/ sbin / ifconfig?)
— yves Baumes
Você tentou detectar o tráfego realmente enviado na interface (wireshark / tcpdump ...)? O que é NIC? É sem fio? Qual é a saída iptables-save, de ip rule show, ip route show table all. Alguma QoS no lugar?
— Stéphane Chazelas
Atualizou a postagem com respostas para suas perguntas.
— Roman Cheplyaka
1
Não criei drivers a partir da fonte. O módulo em si é proveniente do kernel Debian padrão (pacote linux-image-3.2.0-3-686-pae) e o firmware é proveniente do firmware-brcm80211pacote. Você teve problemas semelhantes aos meus? Prefiro evitar construir coisas manualmente, a menos que seja um problema conhecido. Além disso, por que um problema no módulo NIC se manifestaria na camada 4?
— Roman Cheplyaka
1
Provavelmente, o que estiver errado está na sua estação base, switch ou roteador Wi-Fi. Se possível, tente rastrear pacotes (ou contagens de pacotes) lá. Caso contrário, tente trocá-los por alternativas.
— bahamat

Respostas:

5

Na captura que você forneceu, a resposta de eco de carimbo de data / hora no SYN-ACK no segundo pacote não corresponde ao TSVal no SYN no primeiro pacote e está alguns segundos atrás.

E veja como todos os TSecr enviados por 173.194.70.108 e 209.85.148.100 são iguais e irrelevantes para o TSVal que você envia.

Parece que há algo que se mistura aos registros de data e hora do TCP. Não tenho ideia do que pode estar causando isso, mas parece que está fora da sua máquina. A reinicialização do roteador ajuda nessa instância?

Não sei se é o que está causando a sua máquina enviar um RST (no terceiro pacote). Mas definitivamente não gosta do SYN-ACK, e é a única coisa errada que posso encontrar sobre isso. A única outra explicação em que consigo pensar é se não é sua máquina que está enviando o RST, mas, dada a diferença de horário entre o SYN-ACK e o RST, duvido. Mas, por precaução, você usa máquinas virtuais ou contêineres ou namespaces de rede nessa máquina?

Você pode tentar desativar completamente os carimbos de data e hora do TCP para ver se isso ajuda:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Portanto, esses sites enviam TSecr falsos ou há algo a caminho (qualquer roteador a caminho ou proxy transparente) que gerencia o TSVal de saída ou o TSecr de entrada ou um proxy com uma pilha TCP falsa. Por que alguém alteraria os timestamps tcp, posso apenas especular: erro, evasão de detecção de intrusão, um algoritmo de modelagem de tráfego muito inteligente / falso. Isso não é algo que eu já ouvi falar antes (mas não sou especialista no assunto).

Como investigar mais:

  • Veja se o roteador TPLink é o culpado por que redefini-lo para ver se isso ajuda ou captura o tráfego externo também, se possível, para ver se ele altera os registros de data e hora.
  • Verifique se há um proxy transparente no caminho, jogando com TTLs, observando os cabeçalhos de solicitação recebidos pelos servidores da Web ou veja o comportamento ao solicitar sites mortos.
  • capture o tráfego em um servidor da Web remoto para ver se é o TSVal ou TSecr que está mutilado.
— Stéphane Chazelas
fonte
Não, eu não tinha nenhum vms / contêiner em execução. Vou tentar suas sugestões da próxima vez, obrigado.
— Roman Cheplyaka
1
Xm .. Sua sugestão sobre tcp_timestamps definitivamente resolve meu problema. Não há nenhum problema com o google e outro site depois de definir net.ipv4.tcp_timestamps como 0 e todos os problemas novamente no caso de net.ipv4.tcp_timestamps = 1, mas POR QUÊ?
— dr.
1

Ele diz soma de verificação incorreta acima. Existe descarregamento de soma de verificação para esse dispositivo (eu não sabia que dispositivos sem fio poderiam descarregar somas de verificação).

O que sudo ethtool -k wlan0te diz. Se houver descarregamento, convém tentar desativá-lo.

Você precisa ser root para chamar iptables-save. Ainda há alguma chance remota de que algo esteja mutilando pacotes lá. Se iptables-savenão funcionar, tente:

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

Na captura de rede, o endereço MAC de destino corresponde ao do roteador. Algo interessante em uma comparação do tráfego UDP ao tráfego TCP?

Além disso, onde $devestá o driver (módulo) do kernel (consulte ethtool -i wlan0) para o seu adaptador sem fio, o que você deve fazer modinfo "$dev"e grep . /sys/module/"$dev"/parameters/*informar?

— Stéphane Chazelas
fonte
Boa pegada! Não notei as somas de verificação erradas. Vou atualizar a resposta com a saída ethtool. O iptables-save foi executado como root, não imprime nada. Da próxima vez, vou executar novamente o tcpdump para mostrar os endereços MAC.
— Roman Cheplyaka
Se o iptables-save não retornar nada, haverá algo definitivamente errado. O que fazer namei -l "$(command -v iptables)"e dpkg -S "$(command -v iptables)"lhe dizer?
— Stéphane Chazelas
Postado a saída.
— Roman Cheplyaka
Atualizada a postagem com informações do módulo.
— Roman Cheplyaka
Obrigado. Veja minhas edições na minha resposta. Você também pode colar um pcap para sua captura em algum lugar ou talvez a saída de tshark -Viwlan0 tcpum desses pacotes SYN aqui?
— Stéphane Chazelas
1

Parece que também tenho exatamente o mesmo comportamento no meu laptop. Não sei o motivo, mas de tempos em tempos não conseguia me conectar ao google.com e a outros recursos externos. As consultas Pings e DNS funcionam perfeitamente. Também encontrei apenas uma solução: reiniciar .

Eu poderia adicionar várias observações:

  1. Se eu inicializar algum outro sistema operacional na minha Caixa Virtual (Windows, ArchLinux, Ubuntu), eu poderia estabelecer conexões TCP com hosts com problemas sem problemas.
  2. Alguns hosts da Internet se comportam como google.com, mas existem muitos, que normalmente são acessíveis usando telnet ou navegador da web
  3. Não tenho um adaptador WIFI no meu laptop, tenho apenas um link Ethernet para o roteador
  4. Eu tentei fazer chroot no espaço de usuário debian / gentoo - não ajuda
  5. Substituí minha placa de rede pela nova - não ajuda

Algumas informações técnicas sobre minha caixa:

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

Suponho que esse comportamento de bugs ocorra por causa de algum bug sutil em algumas versões do kernel Linux, mas não sei como depurar esse problema e, por causa da reprodução instável, estou preso.

— dr.
fonte
Obrigado por compartilhar! Quais são alguns exemplos de hosts que funcionam?
— Roman Cheplyaka
Exemplos de hosts, que funcionam quando esse comportamento de bugs ocorreu: opennet.ru, tut.by.
— dr.
Agora eu estou convencido de que nós, na verdade têm o mesmo problema ...
— Roman Cheplyaka
sim! Concordo. Estou pensando em atualizar o firmware do meu roteador em algo como dd-wrt ou openwrt, ou apenas desatualizar o kernel do linux. Você já tentou alguma dessas etapas?
— dr.
1
Não. Eu adoraria descobrir o que diabos está acontecendo aqui, no entanto.
— Roman Cheplyaka 10/10/12
0 
/sbin/iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Eu tive o mesmo problema que você descreveu até adicionar o comando acima meus comandos iptables do gateway da Internet. In é incluído por padrão no pacote rp-pppoe e outros. Mas quando você escolhe configurações personalizadas e não as define manualmente, os computadores na LAN atrás do gateway terão os problemas que você descreve.

— Kostya Berger
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.