TCP morre em um laptop Linux

Question

Uma vez em vários dias, tenho o seguinte problema. Meu laptop (teste do Debian) de repente se torna incapaz de trabalhar com conexões TCP para a internet.

As seguintes coisas continuam funcionando bem:

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

Mas quando eu tento conexões TCP do meu laptop, elas param (sem resposta para pacotes SYN). Aqui está uma saída típica de curvas:

% 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.

É evidente que algo está errado com o meu sistema (tudo funciona bem), mas eu não tenho ideia do que exatamente.

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

Algum conselho?

Respostas aos comentários

O que é o 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 não 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 funciona no modo normal.

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

Alguma QoS em vigor?

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

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

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

O primeiro é 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

A segunda é esta:

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

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 há /sys/module/brcmsmac/parameters . Aqui está o que eu tenho aí:

# 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 por dr , experimentei alguns outros sites e, para minha grande surpresa, eles de fato 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 fiz o upload dela aqui .

    

Answer 1

Na captura que você forneceu, o Time Stamp Echo Reply no SYN-ACK no segundo pacote não corresponde ao TSVal no SYN no primeiro pacote e está alguns segundos atrasado.

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

Parece que há algo que se mistura com os timestamps 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 é isso 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 eu posso encontrar sobre isso. A única outra explicação que posso pensar é se não é a sua máquina que está enviando o RST, mas dada a diferença de tempo entre o SYN-ACK e RST eu duvido que sim. Mas apenas no caso, você usa máquinas virtuais ou containers ou namespaces de rede nesta máquina?

Você pode tentar desabilitar todos os timestamps TCP para ver se isso ajuda:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Então, esses sites enviam o falso TSecr ou há algo no caminho (qualquer roteador a caminho, ou proxy transparente) que manipula tanto o TSVal de saída quanto o TSecr de entrada, ou um proxy com uma pilha TCP falsa. Por que um iria mangle os timestamps tcp eu só posso especular: bug, 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á tenha ouvido antes (mas eu não sou especialista no assunto).

Como investigar mais:

• Veja se o roteador TPLink é responsável por redefini-lo para ver se isso ajuda ou capturar o tráfego do lado de fora também, se possível, para ver se ele manipula os timestamps
• Verifique se há um proxy transparente no caminho jogando com TTLs, procurando cabeçalhos de solicitação recebidos por servidores da web ou ver comportamento ao solicitar sites mortos.
• captura o tráfego em um servidor da web remoto para ver se é o TSVal ou o TSecr que está desconfigurado.

Answer 2

Ele informa a soma de verificação incorreta acima. Há descarregamento de checksum para esse dispositivo (eu não sabia que dispositivos sem fio poderiam descarregar somas de verificação).

O que sudo ethtool -k wlan0 lhe diz. Se houver descarregamento, você pode tentar desativá-lo.

Você precisa ser root para chamar o iptables-save. Ainda há algumas chances remotas de que algo esteja bagunçando pacotes lá. Se iptables-save não funcionar, tente:

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

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

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

    

Answer 3

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

Eu poderia adicionar várias observações:

1. Se eu inicializar algum outro sistema operacional em minha caixa virtual (Windows, ArchLinux, Ubuntu), eu poderia estabelecer conexões TCP com hosts problemáticos sem nenhum problema.
2. Alguns dos hosts na Internet se comportam como google.com, mas há muitos deles, que normalmente são acessíveis usando o telnet ou o navegador da Web
3. Eu não tenho um adaptador WIFI no meu laptop, tenho apenas um link Ethernet para o roteador
4. Eu tentei chroot no espaço do usuário debian / gentoo - não ajuda
5. Eu substituí meu NIC pelo novo - não ajuda

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

SO: Last 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 ocorre devido a algum bug sutil em algumas versões do kernel do Linux, mas não sei como depurar esse problema e, devido à reprodução instável, estou presa.

    

Answer 4

/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 aos comandos iptables do meu gateway de Internet . In está 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.