TCP meurt sur un ordinateur portable Linux

17

Une fois en plusieurs jours, j'ai le problème suivant. Mon ordinateur portable (test Debian) devient soudainement incapable de fonctionner avec des connexions TCP à Internet.

Les choses suivantes continuent de bien fonctionner:

  • UDP (DNS), ICMP (ping) - je reçois une réponse instantanée
  • Connexions TCP à d'autres machines du réseau local (par exemple, je peux ssh vers un ordinateur portable voisin)
  • tout va bien pour les autres machines de mon LAN

Mais lorsque j'essaie les connexions TCP depuis mon ordinateur portable, elles expirent (pas de réponse aux paquets SYN). Voici une sortie curl typique:

% 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

Redémarrer la connexion et / ou recharger le module du noyau de la carte réseau n'aide pas. La seule chose qui aide est de redémarrer.

De toute évidence, quelque chose ne va pas avec mon système (tout le reste fonctionne bien), mais je n'ai aucune idée de quoi exactement.

Ma configuration est un routeur sans fil qui est connecté au FAI via PPPoE.

Aucun conseil?

Réponses aux commentaires

De quelle carte réseau s'agit-il?

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

Quel est l'état de votre carte réseau lorsque le problème se produit?

iptables-save n'imprime rien.

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

Tout ce qui précède est le même lorsque la machine fonctionne en mode normal.

ifconfig- Je l'ai exécuté, mais j'ai oublié de sauvegarder avant de redémarrer. Devra attendre la prochaine fois que le problème se produira. Désolé pour ça.

Y a-t-il une QoS en place?

Probablement pas - au moins, je n'ai rien fait spécifiquement pour l'activer.

Avez-vous essayé de flairer le trafic réellement envoyé sur l'interface?

J'ai couru plusieurs fois curl et tcpdump, et il y avait deux modèles.

Le premier n'est que des paquets SYN sans réponses.

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

La seconde est la suivante:

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

sortie 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

informations sur le module

# 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

Il n'y a pas /sys/module/brcmsmac/parameters. Voici ce que j'y ai:

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

Certains sites fonctionnent réellement

Comme suggéré par dr , j'ai essayé d'autres sites, et à ma grande surprise, certains d'entre eux ont effectivement fonctionné. Voici quelques hôtes qui ont fonctionné:

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

Et voici certains qui n'ont pas:

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

Capture réseau

J'ai fait une capture réseau et l'ai téléchargée ici .

debian networking tcp Roman Cheplyaka
la source
1
Juste par curiosité: quel est l'état de votre carte réseau lorsque le problème se produit? (/ sbin / ifconfig?)
Yves Baumes
AVEZ-VOUS essayé de flairer le trafic réellement envoyé sur l'interface (wireShark / tcpdump ...)? De quelle carte réseau s'agit-il? Est-ce sans fil? Quelle est la sortie iptables-save, de ip rule show, ip route show table all. Une QoS en place?
Stéphane Chazelas
Mise à jour du message avec des réponses à vos questions.
Roman Cheplyaka du
1
Je n'ai pas construit de pilotes à partir des sources. Le module lui-même provient du noyau Debian d'origine (package linux-image-3.2.0-3-686-pae), et le firmware provient du firmware-brcm80211package. Avez-vous eu des problèmes similaires au mien? Je préfère éviter de construire des trucs à la main, sauf s'il s'agit d'un problème connu. Aussi, pourquoi un problème de module NIC se manifesterait-il sur la couche 4?
Roman Cheplyaka du
1
Il est plus que probable que tout ce qui ne va pas se trouve sur votre borne d'accès Wi-Fi, commutateur ou routeur. Si possible, essayez de suivre les paquets (ou le nombre de paquets) là-bas. Sinon, essayez de les échanger avec des suppléants.
bahamat

Réponses:

5

Dans la capture que vous avez fournie, la réponse d'écho d'horodatage dans le SYN-ACK dans le deuxième paquet ne correspond pas au TSVal dans le SYN dans le premier paquet et a quelques secondes de retard.

Et voyez comment tous les TSecr envoyés à la fois par 173.194.70.108 et 209.85.148.100 sont tous identiques et sans rapport avec le TSVal que vous envoyez.

Il semble qu'il y ait quelque chose qui se mélange aux horodatages TCP. Je n'ai aucune idée de ce qui peut provoquer cela, mais il semble que ce soit en dehors de votre machine. Le redémarrage du routeur est-il utile dans ce cas?

Je ne sais pas si c'est ce qui fait que votre machine envoie un RST (sur le 3ème paquet). Mais il n'aime vraiment pas ce SYN-ACK, et c'est la seule chose que je puisse trouver. La seule autre explication à laquelle je peux penser est que si ce n'est pas votre machine qui envoie le RST mais étant donné la différence de temps entre le SYN-ACK et le RST, j'en doute. Mais au cas où, utilisez-vous des machines virtuelles ou des conteneurs ou des espaces de noms réseau sur cette machine?

Vous pouvez essayer de désactiver complètement les horodatages TCP pour voir si cela aide:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Donc, soit ces sites envoient de faux TSecr, soit il y a quelque chose en route (n'importe quel routeur en cours de route ou proxy transparent) qui gêne le TSVal sortant ou le TSecr entrant, ou un proxy avec une pile TCP bidon. Pourquoi on pourrait modifier les horodatages TCP, je ne peux que spéculer: bogue, évasion de détection d'intrusion, un algorithme de mise en forme du trafic trop intelligent / faux. Ce n'est pas quelque chose dont j'ai entendu parler auparavant (mais je ne suis pas un expert en la matière).

Comment enquêter davantage:

  • Voyez si le routeur TPLink est à blâmer pourquoi le réinitialiser pour voir si cela aide ou capturer le trafic à l'extérieur aussi bien que possible pour voir s'il modifie les horodatages
  • Vérifiez s'il y a un proxy transparent sur le chemin en jouant avec les TTL, en regardant les en-têtes de demande reçus par les serveurs Web ou voyez le comportement lors de la demande de sites Web morts.
  • capturez le trafic sur un serveur Web distant pour voir si c'est le TSVal ou le TSecr qui est déformé.
Stéphane Chazelas
la source
Non, je n'avais pas de vms / conteneurs en cours d'exécution. Je vais essayer vos suggestions la prochaine fois, merci.
Roman Cheplyaka
1
Xm .. Votre suggestion sur tcp_timestamps résout définitivement mon problème. Aucun problème avec Google et d'autres sites Web après avoir défini net.ipv4.tcp_timestamps à 0 et tous les tas de problèmes à nouveau en cas de net.ipv4.tcp_timestamps = 1 mais POURQUOI?
dr.
1

Il indique une somme de contrôle incorrecte ci-dessus. Existe-t-il un déchargement de la somme de contrôle pour cet appareil (je ne savais pas que les appareils sans fil pouvaient décharger les sommes de contrôle).

Qu'est-ce que ça sudo ethtool -k wlan0vous dit. En cas de déchargement, vous pouvez essayer de le désactiver.

Vous devez être root pour appeler iptables-save. Il y a encore quelques chances éloignées que quelque chose gâche des paquets là-bas. Si iptables-savecela ne fonctionne pas, essayez:

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

Dans votre capture réseau, l'adresse MAC de destination correspond-elle à celle du routeur. Quelque chose d'intéressant dans une comparaison entre le trafic UDP et le trafic TCP?

En outre, où se $devtrouve le pilote du noyau (module) (voir ethtool -i wlan0) pour votre adaptateur sans fil, que faire modinfo "$dev"et grep . /sys/module/"$dev"/parameters/*vous dire?

Stéphane Chazelas
la source
Bonne prise! Je n'ai pas remarqué les mauvaises sommes de contrôle. Je mettrai à jour la réponse avec la sortie ethtool. iptables-save a été exécuté en tant que root, n'imprime rien. La prochaine fois, je relancerai tcpdump pour afficher les adresses MAC.
Roman Cheplyaka
Si iptables-save ne renvoie rien, alors il y a vraiment quelque chose qui ne va pas. Que faites -vous namei -l "$(command -v iptables)"et dpkg -S "$(command -v iptables)"dites-vous?
Stéphane Chazelas
Publié la sortie.
Roman Cheplyaka
Mise à jour du message avec des informations sur le module.
Roman Cheplyaka
Merci. Voir mes modifications à ma réponse. Pouvez-vous également coller un pcap pour votre capture quelque part, ou peut-être la sortie de l' tshark -Viwlan0 tcpun de ces paquets SYN ici?
Stéphane Chazelas
1

Il semble que j'ai exactement le même comportement sur mon ordinateur portable. Je ne connais pas la raison, mais de temps en temps, je ne pouvais pas me connecter à google.com et à d'autres ressources externes. Les requêtes ping et DNS fonctionnent parfaitement. De plus, je n'ai trouvé qu'une seule solution: redémarrer .

Je pourrais ajouter plusieurs observations:

  1. Si je démarre un autre système d'exploitation dans ma boîte virtuelle (Windows, ArchLinux, Ubuntu), je pourrais établir des connexions TCP avec des hôtes problématiques sans aucun problème.
  2. Certains hôtes sur Internet se comportent comme google.com, mais il y en a beaucoup, qui sont normalement accessibles via telnet ou un navigateur Web
  3. Je n'ai pas d'adaptateur WIFI sur mon ordinateur portable, je n'ai qu'un lien Ethernet vers le routeur
  4. J'ai essayé de chrooter dans l'espace utilisateur debian / gentoo - cela n'aide pas
  5. J'ai remplacé ma carte réseau par la nouvelle - ça n'aide pas

Quelques informations techniques sur ma box:

Système d'exploitation: 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

Je suppose que ce comportement de bogue se produit à cause d'un bogue subtil dans certaines versions du noyau Linux, mais je ne sais pas comment déboguer ce problème et à cause d'une reproduction instable, je suis bloqué.

dr.
la source
Merci d'avoir partagé! Quels sont quelques exemples d'hôtes qui fonctionnent?
Roman Cheplyaka
Exemples d'hôtes, qui fonctionnent lorsque ce comportement de buggy s'est produit: opennet.ru, tut.by.
dr.
Je suis maintenant convaincu que nous avons en effet le même problème ...
Roman Cheplyaka
Ouais! Je suis d'accord. Je pense à mettre à jour le firmware de mon routeur sur quelque chose comme dd-wrt ou openwrt, ou simplement à rétrograder le noyau linux. Avez-vous essayé l'une de ces étapes?
dr.
1
J'adorerais savoir ce qui se passe ici, cependant.
Roman Cheplyaka
0 
/sbin/iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

J'ai eu le même problème que vous avez décrit jusqu'à ce que ajouté ci - dessus commande mes iptables de passerelle Internet. In est inclus par défaut dans le package rp-pppoe et autres. Mais lorsque vous optez pour des configurations personnalisées et que vous ne le définissez pas manuellement, les ordinateurs sur le LAN derrière la passerelle auront les problèmes que vous décrivez.

Kostya Berger
la source