Una volta ogni giorno ho il seguente problema. Il mio laptop (test Debian) diventa improvvisamente incapace di funzionare con connessioni TCP a Internet.

Le seguenti cose continuano a funzionare bene:

• UDP (DNS), ICMP (ping) - Ottengo una risposta immediata
• Connessioni TCP ad altre macchine nella rete locale (ad es. Posso inviare ssh a un laptop vicino)
• va tutto bene per le altre macchine nella mia LAN

Ma quando provo le connessioni TCP dal mio laptop, queste scadono (nessuna risposta ai pacchetti SYN). Ecco un tipico output di arricciatura:

% 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

Riavviare la connessione e / o ricaricare il modulo del kernel della scheda di rete non aiuta. L'unica cosa che aiuta è il riavvio.

Chiaramente qualcosa non va nel mio sistema (tutto il resto funziona bene), ma non ho idea di cosa esattamente.

La mia configurazione è un router wireless collegato all'ISP tramite PPPoE.

Qualche consiglio?

Risposte ai commenti

Che scheda di rete è?

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 è lo stato della scheda NIC quando si verifica il problema?

iptables-save non stampa nulla.

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

Tutto quanto sopra è lo stesso quando la macchina funziona in modalità normale.

ifconfig- L'ho eseguito, ma in qualche modo ho dimenticato di salvare prima di riavviare. Dovrà attendere fino alla prossima volta che si verifica il problema. Mi dispiace per quello.

Qualche QoS in atto?

Probabilmente no - almeno non ho fatto nulla di specifico per abilitarlo.

Hai provato ad annusare il traffico effettivamente inviato sull'interfaccia?

Ho corso più volte a curl e tcpdump e c'erano due schemi.

Il primo è solo pacchetti SYN senza risposte.

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

Il secondo è questo:

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

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

informazioni sul modulo

# 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 

Non c'è /sys/module/brcmsmac/parameters. Ecco cosa ho lì:

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

Alcuni siti funzionano davvero

Come suggerito dal dr , ho provato alcuni altri siti e con mia grande sorpresa alcuni di loro hanno davvero funzionato. Ecco alcuni host che hanno funzionato:

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

Ed eccone alcuni che non lo hanno fatto:

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

Acquisizione di rete

Ho effettuato un'acquisizione di rete e l'ho caricata qui .

Nella cattura fornita, Time Stamp Echo Reply nel SYN-ACK nel secondo pacchetto non corrisponde al TSVal nel SYN nel primo pacchetto ed è indietro di alcuni secondi.

E guarda come tutti i TSecr inviati da 173.194.70.108 e 209.85.148.100 sono tutti uguali e irrilevanti rispetto al TSVal che invii.

Sembra che ci sia qualcosa che si confonde con i timestamp TCP. Non ho idea di cosa possa essere la causa, ma sembra fuori dalla tua macchina. Il riavvio del router aiuta in questo caso?

Non so se è ciò che sta causando la tua macchina per inviare un RST (sul 3 ° pacchetto). Ma sicuramente non piace quel SYN-ACK, ed è l'unica cosa sbagliata che posso trovare al riguardo. L'unica altra spiegazione a cui riesco a pensare è se non è la tua macchina che sta inviando l'RST, ma data la differenza di tempo tra SYN-ACK e RST, ne dubito. Ma per ogni evenienza, usi macchine virtuali o contenitori o spazi dei nomi di rete su questa macchina?

Potresti provare a disabilitare del tutto i timestamp TCP per vedere se questo aiuta:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Quindi, o quei siti inviano falsi TSecr o c'è qualcosa sulla strada (qualsiasi router in arrivo, o proxy trasparente) che manipola il TSVal in uscita o il TSecr in arrivo, o un proxy con uno stack TCP fasullo. Perché uno potrebbe manipolare i timestamp TCPC che posso solo speculare: bug, evasione del rilevamento delle intrusioni, un algoritmo di modellamento del traffico troppo intelligente / falso. Non è qualcosa di cui ho sentito parlare prima (ma poi non sono un esperto in materia).

Come indagare ulteriormente:

• Verifica se il router TPLink deve incolpare perché reimpostarlo per vedere se ciò aiuta o cattura il traffico all'esterno e, se possibile, controlla se riesce a manipolare i timestamp
• Controlla se c'è un proxy trasparente sulla strada giocando con i TTL, guardando le intestazioni delle richieste ricevute dai server web o vedi il comportamento quando richiedi siti Web morti.
• acquisire il traffico su un server Web remoto per vedere se è il TSVal o TSecr ad essere alterato.

Dice sopra checksum errato. Esiste un offload di checksum per quel dispositivo (non sapevo che i dispositivi wireless potessero scaricare i checksum).

Cosa sudo ethtool -k wlan0ti dice. Se è presente l'offload, è possibile provare a disabilitarlo.

Devi essere root per chiamare iptables-save. C'è ancora qualche remota possibilità che qualcosa stia manipolando i pacchetti lì. Se iptables-savenon funziona, prova:

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

Nell'acquisizione di rete, l'indirizzo MAC di destinazione corrisponde a quello del router. Qualcosa di interessante in un confronto tra il traffico UDP e il traffico TCP?

Inoltre, dov'è $devil driver del kernel (modulo) (vedi ethtool -i wlan0) per la tua scheda wireless, cosa ti dicono modinfo "$dev"e cosa grep . /sys/module/"$dev"/parameters/*ti dicono?

A quanto pare, ho esattamente lo stesso comportamento anche sul mio laptop. Non ne conosco il motivo, ma di tanto in tanto non riesco a collegarmi a google.com e ad altre risorse esterne. Ping e query DNS funzionano perfettamente. Inoltre ho trovato una sola soluzione: riavviare .

Potrei aggiungere diverse osservazioni:

1. Se avessi avviato qualche altro sistema operativo nella mia Virtual Box (Windows, ArchLinux, Ubuntu), avrei potuto stabilire connessioni TCP con host problematici senza problemi.
2. Alcuni host in Internet si comportano come google.com, ma ce ne sono molti, che sono normalmente accessibili tramite telnet o browser web
3. Non ho un adattatore WIFI sul mio laptop, ho solo un collegamento Ethernet al router
4. Ho provato a chroot nello spazio utente debian / gentoo - non aiuta
5. Ho sostituito il mio NIC con quello nuovo - non aiuta

Alcune informazioni tecniche sulla mia scatola:

Sistema operativo: ultimo 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

Suppongo che questo comportamento errato si verifichi a causa di alcuni bug sottili in alcune versioni del kernel Linux, ma non so come eseguire il debug di questo problema e a causa della riproduzione instabile sono bloccato.

/sbin/iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Ho avuto lo stesso problema che hai descritto fino a quando non è stato aggiunto il comando precedente i miei comandi iptables del gateway Internet. In è incluso di default nel pacchetto rp-pppoe e altri. Ma quando scegli configurazioni personalizzate e non le imposti manualmente, i computer sulla LAN dietro il gateway avranno i problemi che descrivi.