TCP umiera na laptopie z systemem Linux

17

Raz na kilka dni mam następujący problem. Mój laptop (testowanie Debiana) nagle przestaje działać z połączeniami TCP z Internetem.

Następujące rzeczy działają poprawnie:

  • UDP (DNS), ICMP (ping) - otrzymuję natychmiastową odpowiedź
  • Połączenia TCP z innymi komputerami w sieci lokalnej (np. Mogę ssh do sąsiedniego laptopa)
  • wszystko jest w porządku dla innych maszyn w mojej sieci LAN

Ale kiedy próbuję połączeń TCP z mojego laptopa, przekroczą limit czasu (brak odpowiedzi na pakiety SYN). Oto typowy wynik curl:

% 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

Ponowne uruchomienie połączenia i / lub ponowne załadowanie modułu jądra karty sieciowej nie pomaga. Jedyne, co pomaga, to restart.

Najwyraźniej coś jest nie tak z moim systemem (wszystko inne działa dobrze), ale nie mam pojęcia co dokładnie.

Moja konfiguracja to router bezprzewodowy, który jest podłączony do ISP za pośrednictwem PPPoE.

Jakakolwiek rada?

Odpowiedzi na komentarze

Co to jest karta sieciowa?

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

Jaki jest stan Twojej karty sieciowej, kiedy wystąpi problem?

iptables-save nic nie drukuje.

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

Wszystkie powyższe są takie same, gdy urządzenie pracuje w trybie normalnym.

ifconfig- Uruchomiłem, ale jakoś zapomniałem zapisać przed ponownym uruchomieniem. Będę musiał poczekać, aż problem pojawi się następnym razem. Przepraszam za to.

Jakieś QoS?

Prawdopodobnie nie - przynajmniej nie zrobiłem nic specjalnie, aby to umożliwić.

Czy próbowałeś wąchać ruch faktycznie wysłany przez interfejs?

Uruchomiłem curl i tcpdump kilka razy i były dwa wzory.

Pierwszy to tylko pakiety SYN bez odpowiedzi.

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

Drugi to:

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

produkcja ettoolu

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

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

Tam nie jest /sys/module/brcmsmac/parameters. Oto co mam tam:

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

Niektóre strony faktycznie działają

Jak zasugerował dr , wypróbowałem kilka innych stron i ku mojemu wielkiemu zdziwieniu niektóre z nich rzeczywiście działały. Oto niektóre hosty, które działały:

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

A oto niektóre, które nie:

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

Przechwytywanie sieci

Zrobiłem przechwytywanie sieci i przesłałem go tutaj .

debian  networking  tcp 
— Roman Cheplyaka
źródło
1
Z ciekawości: Jaki jest stan Twojej karty sieciowej, kiedy wystąpi problem? (/ sbin / ifconfig?)
— yves Baumes
Czy próbowałeś sniffować ruch faktycznie wysłany przez interfejs (wireshark / tcpdump ...)? Co to jest karta sieciowa? Czy to jest bezprzewodowe? Co znajduje się wyjście iptables-save, z ip rule show, ip route show table all. Jakieś QoS?
— Stéphane Chazelas,
Zaktualizowałem post z odpowiedziami na twoje pytania.
— Roman Cheplyaka
1
Nie budowałem sterowników ze źródła. Sam moduł pochodzi z podstawowego jądra Debiana (pakietu linux-image-3.2.0-3-686-pae), a oprogramowanie układowe pochodzi z firmware-brcm80211pakietu. Czy miałeś problemy podobne do moich? Wolę unikać budowania rzeczy ręcznie, chyba że jest to znany problem. Ponadto, dlaczego problem modułu NIC objawiałby się na warstwie 4?
— Roman Cheplyaka
1
Bardziej niż prawdopodobne, że coś jest nie tak, znajduje się na stacji bazowej, przełączniku lub routerze Wi-Fi. Jeśli to możliwe, spróbuj tam śledzić pakiety (lub liczbę pakietów). Jeśli nie, spróbuj zamienić je na alternatywne.
— bahamat

Odpowiedzi:

5

W podanym uchwyceniu odpowiedź echa znacznika czasu w SYN-ACK w drugim pakiecie nie pasuje do TSVal w SYN w pierwszym pakiecie i jest kilka sekund za nim.

I zobacz, jak wszystkie TSecr wysłane zarówno przez 173.194.70.108, jak i 209.85.148.100 są takie same i nie mają znaczenia z wysyłanego TSVal.

Wygląda na to, że istnieje coś, co miesza się ze znacznikami czasu TCP. Nie mam pojęcia, co może być tego przyczyną, ale wygląda na to, że znajduje się poza twoim komputerem. Czy ponowne uruchomienie routera pomaga w tym przypadku?

Nie wiem, czy to powoduje, że twoja maszyna wysyła RST (na 3. pakiecie). Ale zdecydowanie nie podoba się to SYN-ACK i to jedyna zła rzecz, jaką mogę o tym znaleźć. Jedyne inne wyjaśnienie, jakie mogę wymyślić, to to, że to nie twoja maszyna wysyła RST, ale biorąc pod uwagę różnicę czasu między SYN-ACK i RST, wątpiłbym w to. Ale na wszelki wypadek, czy używasz maszyn wirtualnych, kontenerów lub sieciowych przestrzeni nazw na tym komputerze?

Możesz spróbować całkowicie wyłączyć znaczniki czasu TCP, aby sprawdzić, czy to pomoże:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Tak więc albo te strony wysyłają fałszywy TSecr, albo po drodze jest coś (dowolny router w drodze lub przezroczysty serwer proxy), który zakłóca wychodzący TSVal lub przychodzący TSecr, lub serwer proxy z fałszywym stosem TCP. Dlaczego należy zmieniać znaczniki czasu tcp, które mogę jedynie spekulować: błąd, unikanie wykrywania włamań, zbyt inteligentny / fałszywy algorytm kształtowania ruchu. To nie jest coś, o czym słyszałem wcześniej (ale wtedy nie jestem ekspertem w tej dziedzinie).

Jak dalej badać:

  • Sprawdź, czy router TPLink ma obwiniać, dlaczego zresetować go, aby sprawdzić, czy to pomaga, czy też przechwycić ruch na zewnątrz, a jeśli to możliwe, aby sprawdzić, czy zakłóca znaczniki czasu
  • Sprawdź, czy po drodze jest przezroczysty serwer proxy, grając z TTL, przeglądając nagłówki żądań otrzymywane przez serwery sieciowe lub zobacz zachowanie podczas żądania martwych stron internetowych.
  • przechwytuj ruch na zdalnym serwerze WWW, aby sprawdzić, czy jest to TSVal lub TSecr, który jest zniekształcony.
— Stéphane Chazelas
źródło
Nie, nie miałem uruchomionych żadnych vms / kontenerów. Spróbuję twoich sugestii następnym razem, dzięki.
— Roman Cheplyaka,
1
Xm .. Sugestia dotycząca tcp_timestamps zdecydowanie rozwiązuje mój problem. Nie ma problemu z Google i inną witryną po ustawieniu net.ipv4.tcp_timestamps na 0 i wszystkich innych problemów w przypadku net.ipv4.tcp_timestamps = 1, ale DLACZEGO?
— dr.
1

Powyżej podano nieprawidłową sumę kontrolną. Czy istnieje odciążenie sumy kontrolnej dla tego urządzenia (nie wiedziałem, że urządzenia bezprzewodowe mogą odciążyć sumy kontrolne).

Co sudo ethtool -k wlan0ci mówi Jeśli występuje odciążenie, możesz spróbować je wyłączyć.

Musisz być rootem, aby wywołać iptables-save. Nadal istnieje niewielka szansa, że ​​coś tam coś psuje pakiety. Jeśli iptables-savenie działa, spróbuj:

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

Czy w przechwytywaniu sieci docelowy adres MAC jest zgodny z adresem routera. Czy jest coś interesującego w porównaniu z ruchem UDP do ruchu TCP?

Ponadto, gdzie $devznajduje się sterownik jądra (moduł) (patrz ethtool -i wlan0) dla karty sieci bezprzewodowej, co zrobić modinfo "$dev"i grep . /sys/module/"$dev"/parameters/*powiedzieć?

— Stéphane Chazelas
źródło
Dobry chwyt! Nie zauważyłem niewłaściwych sum kontrolnych. Zaktualizuję odpowiedź za pomocą wyjścia ethtool. iptables-save został uruchomiony jako root, nic nie drukuje. Następnym razem uruchomię ponownie program tcpdump, aby wyświetlić adresy MAC.
— Roman Cheplyaka
Jeśli iptables-save nic nie zwraca, oznacza to, że coś jest zdecydowanie nie tak. Co zrobić namei -l "$(command -v iptables)"i dpkg -S "$(command -v iptables)"powiedzieć?
— Stéphane Chazelas
Wysłano wyjście.
— Roman Cheplyaka
Zaktualizowano wpis o informacje o module.
— Roman Cheplyaka
Dzięki. Zobacz moje zmiany mojej odpowiedzi. Czy możesz też wkleić gdzieś pcap do przechwytywania, a może wyjście tshark -Viwlan0 tcpjednego z tych pakietów SYN tutaj?
— Stéphane Chazelas
1

Wygląda na to, że mam dokładnie takie samo zachowanie na laptopie. Nie znam przyczyny, ale od czasu do czasu nie mogłem połączyć się z google.com i innymi zasobami zewnętrznymi. Pingi i zapytania DNS działają idealnie. Znalazłem też tylko jedno rozwiązanie: uruchom ponownie .

Mógłbym dodać kilka uwag:

  1. Jeśli uruchomię jakiś inny system operacyjny w moim Virtual Boxie (Windows, ArchLinux, Ubuntu), mogę bez problemu nawiązać połączenia TCP z problemowymi hostami.
  2. Niektóre hosty w Internecie zachowują się jak google.com, ale istnieje wiele z nich, które są normalnie dostępne za pomocą telnetu lub przeglądarki internetowej
  3. Nie mam adaptera WIFI na moim laptopie, mam tylko łącze Ethernet do routera
  4. Próbowałem chrootować w przestrzeni użytkownika debian / gentoo - to nie pomaga
  5. Wymieniłem moją kartę sieciową na nową - to nie pomaga

Niektóre informacje techniczne o moim pudełku:

System operacyjny: 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

Podejrzewam, że to błędne zachowanie występuje z powodu subtelnego błędu w niektórych wersjach jądra Linuksa, ale nie wiem, jak rozwiązać ten problem, a także z powodu niestabilnej reprodukcji utknąłem.

— dr.
źródło
Dzięki za udostępnienie! Jakie są przykłady działających hostów?
— Roman Cheplyaka
Przykłady hostów, które działają, gdy wystąpiło takie błędne zachowanie: opennet.ru, tut.by.
— dr.
Jestem teraz przekonany, że rzeczywiście mamy ten sam problem ...
— Roman Cheplyaka,
Tak! Zgadzam się. Zastanawiam się nad aktualizacją oprogramowania routera na czymś takim, jak dd-wrt lub openwrt, lub po prostu obniżeniem poziomu jądra systemu Linux. Czy wypróbowałeś któryś z tych kroków?
— dr.
1
Nie. Chciałbym jednak dowiedzieć się, co tu się do cholery dzieje.
— Roman Cheplyaka,
0 
/sbin/iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Miałem ten sam problem, który opisałeś, dopóki nie dodałem powyższego polecenia do moich poleceń iptables mojej bramy internetowej. In jest domyślnie dołączony do pakietu rp-pppoe i innych. Ale jeśli wybierzesz niestandardowe konfiguracje i nie ustawisz go ręcznie, komputery w sieci LAN za bramą będą miały opisane problemy.

— Kostya Berger
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.