Раз на кілька днів у мене виникає така проблема. Мій ноутбук (тестування Debian) раптово стає неможливим працювати з TCP-підключеннями до Інтернету.

Наступні речі продовжують працювати нормально:

• UDP (DNS), ICMP (ping) - я отримую миттєву відповідь
• TCP-з'єднання з іншими машинами в локальній мережі (наприклад, я можу перейти до сусідського ноутбука)
• для інших машин у моїй мережі все нормально

Але коли я пробую TCP-з'єднання зі свого ноутбука, вони закінчуються (час відповіді на SYN-пакети немає). Ось типовий вихід завитка:

% 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

Перезавантаження з'єднання та / або перезавантаження модуля ядра мережевої карти не допоможе. Єдине, що допомагає - це перезавантажити.

Зрозуміло, що з моєю системою щось не так (все інше працює нормально), але я поняття не маю, що саме.

Моя установка - це бездротовий маршрутизатор, який підключений до провайдера через PPPoE.

Будь-яка порада?

Відповіді на коментарі

Що це за 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

Який стан вашого НІК, коли виникає проблема?

iptables-save нічого не друкує.

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

Все вищезазначене те саме, коли машина працює в звичайному режимі.

ifconfig- Я запустив це, але якось забув зберегти перед перезавантаженням. Доведеться почекати до наступного разу, коли проблема виникне. Вибач за це.

Якийсь QoS на місці?

Можливо, ні - принаймні я нічого конкретно не зробив, щоб це зробити.

Ви спробували нюхати трафік, фактично відправлений на інтерфейс?

Я кілька разів запускав curl і tcpdump, і було дві схеми.

Перший - це лише SYN-пакети без відповідей.

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

Друге:

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

випуск етитолу

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         

інформація про модуль

# 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 

Немає /sys/module/brcmsmac/parameters. Ось що я там маю:

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

Деякі сайти насправді працюють

За пропозицією доктора , я спробував деякі інші сайти, і на моє велике здивування, деякі з них справді спрацювали. Ось кілька хостів, які працювали:

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

А ось ось що не вдалося:

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

Захоплення мережею

Я зробив мережеве захоплення і завантажив його сюди .

У наданому вами захопленні відповідь ехо -відповіді на часову марку в SYN-ACK у другому пакеті не відповідає TSVal в SYN в першому пакеті і відстає на кілька секунд.

І подивіться, як усі TSecr, надіслані як 173.194.70.108, так і 209.85.148.100, однакові і не мають відношення до TSVal, який ви надсилаєте.

Схоже, є щось, що поєднується з часовими позначками TCP. Я поняття не маю, що це може спричинити, але це здається, що це поза вашої машини. Чи допомагає перезавантаження маршрутизатора в цьому випадку?

Я не знаю, через що ваша машина надсилає RST (на 3-й пакет). Але це SYN-ACK йому точно не подобається, і це єдине, що я можу знайти про це. Єдине інше пояснення, про яке я можу придумати, - це якщо не ваша машина надсилає RST, але враховуючи різницю у часі між SYN-ACK і RST, я б сумнівався в цьому. Але про всяк випадок на цій машині ви використовуєте віртуальні машини чи контейнери чи простори мережних імен?

Ви можете спробувати відключити часові позначки TCP, щоб побачити, чи це допомагає:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Отже, або ці сайти надсилають фальшивий TSecr, або там є щось на шляху (будь-який маршрутизатор на шляху, або прозорий проксі), який керує або вихідним TSVal, або вхідним TSecr, або проксі з фальшивим стеком TCP. Чому можна заплутати часові позначки tcp, я можу лише здогадуватися: помилка, ухилення від виявлення вторгнень, занадто розумний / хибний алгоритм формування трафіку. Це не те, що я чув раніше (але тоді я не є експертом з цього питання).

Як дослідити далі:

• Подивіться, чи винен маршрутизатор TPLink, чому скинути його, щоб побачити, чи це допомагає або захоплює трафік зовні, а також, якщо можливо, щоб дізнатись, чи він порушує часові позначки
• Перевірте, чи є на шляху прозорий проксі-сервер, граючи з TTL, переглядаючи заголовки запитів, отримані веб-серверами, або дивіться поведінку під час запиту мертвих веб-сайтів.
• зафіксуйте трафік на віддаленому веб-сервері, щоб побачити, чи це TSVal або TSecr, який налаштований.

Зверху зазначено неправильну контрольну суму. Чи є розвантаження контрольної суми для цього пристрою (я не знав, що бездротові пристрої можуть завантажувати контрольні суми).

Що sudo ethtool -k wlan0вам каже. Якщо відбувається завантаження, ви можете спробувати його відключити.

Щоб викликати iptables-save, потрібно мати root. Існує ще певний віддалений шанс, що щось там маніпулює пакетами. Якщо iptables-saveне виходить, спробуйте:

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

Чи відповідає мережева адреса MAC-адреса в мережевому заході з адресою маршрутизатора. Що цікавого у порівнянні від трафіку UDP до трафіку TCP?

Крім того, де $devдрайвер ядра (модуль) (див. ethtool -i wlan0) Для вашого бездротового адаптера, що робити modinfo "$dev"і що grep . /sys/module/"$dev"/parameters/*говорити?

Здається, у мене точно така ж поведінка і на моєму ноутбуці. Я не знаю причини, але час від часу мені не вдалося підключитися до google.com та деяких інших зовнішніх ресурсів. Pings та DNS-запити працюють ідеально. Також я знайшов лише одне рішення: перезавантажити .

Я можу додати кілька спостережень:

1. Якщо я завантажую якусь іншу ОС у своїй віртуальній вікні (Windows, ArchLinux, Ubuntu), я можу встановити TCP-з'єднання з проблемними хостами без проблем.
2. Деякі хости в Інтернеті поводяться як google.com, але є багато з них, які зазвичай доступні за допомогою telnet або веб-браузера
3. У мене на ноутбуці немає WIFI-адаптера, у мене є тільки Ethernet-посилання на роутер
4. Я намагався хронізувати в користувацький простір debian / gentoo - це не допомагає
5. Я замінив свій NIC на новий - він не допомагає

Деякі технічні відомості про мій ящик:

ОС: Останній 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

Я думаю, що ця поведінка баггі виникає через деяку тонку помилку в деяких версіях ядра Linux, але я не знаю, як налагодити цю проблему, і через нестабільне відтворення я застряг.

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

У мене була та сама проблема, яку ви описали, поки не додали вищевказану команду до своїх команд iptables iptables. Включається за замовчуванням у пакет rp-pppoe та інші. Але якщо ви скористаєтеся власною конфігурацією та не встановите її вручну, комп'ютери в локальній мережі за шлюзом матимуть описані вами проблеми.