LinuxラップトップでTCPが死ぬ


17

数日に一度、次の問題があります。私のラップトップ(Debianテスト)が突然、インターネットへのTCP接続で動作できなくなります。

次のことは引き続き正常に機能します。

  • UDP(DNS)、ICMP(ping)—即座に応答します
  • ローカルネットワーク内の他のマシンへのTCP接続(例:隣のラップトップにSSH接続できます)
  • LAN内の他のマシンではすべて問題ありません

しかし、ラップトップからTCP接続を試みると、タイムアウトします(SYNパケットへの応答なし)。典型的な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

接続を再開したり、ネットワークカードカーネルモジュールをリロードしたりしても効果はありません。唯一役立つのは再起動です。

明らかに、私のシステムに何か問題があります(他のすべてが正常に機能します)が、何が正確かはわかりません。

私のセットアップは、PPPoEを介してISPに接続されているワイヤレスルーターです。

何かアドバイス?

コメントへの回答

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

問題が発生したときのNICの状態は何ですか?

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を数回実行しましたが、2つのパターンがありました。

1つ目は、応答のない単なる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

2番目はこれです。

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の出力

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

一部のサイトは実際に動作します

drが示唆するように、私は他のサイトをいくつか試しましたが、驚いたことにそれらのいくつかは実際に動作しました。動作したホストを次に示します。

  • rambler.ru
  • google.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

ネットワークキャプチャ

ネットワークキャプチャを作成し、ここにアップロードしました


1
好奇心だけで:問題が発生したときのNICの状態は何ですか?(/ sbin / ifconfig?)
yvesボームズ

インターフェイスで実際に送信されたトラフィック(wireshark / tcpdump ...)をスニッフィングしようとしましたか?何のNICですか?ワイヤレスですか?出力何iptables-saveの、ip rule showip route show table all。適切なQoSはありますか?
ステファンシャゼル

質問への回答で投稿を更新しました。
ローマンチェプリャカ

1
ソースからドライバーをビルドしませんでした。モジュール自体は標準のDebianカーネル(パッケージlinux-image-3.2.0-3-686-pae)から取得され、ファームウェアはパッケージから取得されfirmware-brcm80211ます。私と同様の問題がありましたか?既知の問題でない限り、手作業での構築は避けたいです。また、レイヤー4でNICモジュールの問題が明らかになるのはなぜですか?
ローマンチェプリカ

1
おそらく、Wi-Fiベースステーション、スイッチ、またはルーターに問題があります。可能であれば、そこでパケット(またはパケットカウント)をトレースしてみてください。そうでない場合は、代替と交換してみてください。
バハマ

回答:


5

指定したキャプチャでは、2番目のパケットのSYN-ACK のタイムスタンプエコー応答が最初のパケットのSYNのTSValと一致せず、数秒遅れています。

また、173.194.70.108と209.85.148.100の両方によって送信されたTSecrがすべて同じであり、送信するTSValとは無関係であることがわかります。

TCPタイムスタンプと混ざり合っているものがあるようです。何が原因なのかわかりませんが、あなたのマシンの外にあるようです。この場合、ルーターの再起動は役立ちますか?

マシンがRSTを(3番目のパケットで)送信する原因になっているかどうかはわかりません。しかし、それは間違いなくそのSYN-ACKが好きではなく、それについて私が見つけることができる唯一の間違いです。私が考えることができる他の唯一の説明は、RSTを送信しているのがあなたのマシンではないが、SYN-ACKとRSTの時間差が与えられている場合、私はそうは思わないでしょう。しかし、念のため、このマシンで仮想マシンまたはコンテナーまたはネットワーク名前空間を使用していますか?

TCPタイムスタンプを完全に無効にして、それが役立つかどうかを確認できます。

sudo sysctl -w net.ipv4.tcp_timestamps=0

したがって、それらのサイトは偽のTSecrを送信するか、発信TSValまたは着信TSecrのいずれか、または偽のTCPスタックを持つプロキシを破壊する何かが途中にあります(途中のルーター、または透過プロキシ)。推測できるのは、バグ、侵入検知回避、スマートすぎる/偽のトラフィックシェーピングアルゴリズムだけです。それは私が以前に聞いたことのないことです(しかし、私はこの問題の専門家ではありません)。

さらに調査する方法:

  • TPLinkルーターがリセットの理由を責めるかどうかを確認し、それが可能であればタイムスタンプを破壊するかどうかを確認するために、外部のトラフィックを助けるかキャプチャするかどうかを確認します
  • TTLで遊ぶか、Webサーバーが受信したリクエストヘッダーを調べるか、デッドWebサイトをリクエストする際の動作を確認して、透過的なプロキシがあるかどうかを確認します。
  • リモートWebサーバー上のトラフィックをキャプチャして、TSValまたはTSecrがマングルされているかどうかを確認します。

いいえ、vms / containersを実行していません。次回はあなたの提案をお試しください、ありがとう。
ローマンCheplyaka

1
Xm .. tcp_timestampsについてのあなたの提案は間違いなく私の問題を解決します。net.ipv4.tcp_timestamps = 1の場合にnet.ipv4.tcp_timestampsを0に設定し、すべての問題を再度設定すると、Googleや他のWebサイトに問題はありませんが、なぜですか?
博士。

1

上記の誤ったチェックサムを示しています。そのデバイスのチェックサムオフロードはありますか(ワイヤレスデバイスがチェックサムをオフロードできるとは知りませんでした)。

何が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/*あなたを教えて?


良いキャッチ!間違ったチェックサムに気付きませんでした。ethtoolの出力で回答を更新します。iptables-saveはルートとして実行され、何も出力されません。次回は、tcpdumpを再実行してMACアドレスを表示します。
ローマンCheplyaka

iptables-saveが何も返さない場合は、間違いがあります。何namei -l "$(command -v iptables)"dpkg -S "$(command -v iptables)"教えてくれますか?
ステファンシャゼラス

出力を投稿しました。
ローマンチェプリカ

モジュール情報で投稿を更新しました。
ローマンチェプリアカ

ありがとう。回答の編集内容を確認してください。キャプチャのpcapをどこかに貼り付けることもできますか、それともtshark -Viwlan0 tcpそれらのSYNパケットの1つの出力をここに貼り付けることはできますか?
ステファンシャゼル

1

私が持っている、と思われる、全く同じ振る舞いをあまりにも私のラップトップで。理由はわかりませんが、時々google.comや他の外部リソースに接続できませんでした。pingとDNSクエリは完全に機能します。また、解決策は1つしか見つかりませんでした:reboot

いくつかの観測を追加できます。

  1. Virtual Box(Windows、ArchLinux、Ubuntu)で他のOSを起動すると、問題のあるホストとのTCP接続を問題なく確立できます。
  2. インターネットのホストの一部はgoogle.comのように動作しますが、それらの多くは通常telnetまたはWebブラウザを使用してアクセスできます。
  3. ラップトップにWIFIアダプターがありません。ルーターへのイーサネットリンクしかありません
  4. 私はdebian / gentooユーザー空間にchrootしようとしました-助けにはなりません
  5. NICを新しいものに交換しました-役に立たない

私の箱に関するいくつかの技術情報:

OS:最後の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カーネルのいくつかのバージョンの微妙なバグが原因で発生すると考えられますが、この問題をデバッグする方法がわかりません。


共有してくれてありがとう!動作するホストの例は何ですか?
ローマンチェプリカ

このバグのある動作が発生したときに機能するホストの例:opennet.ru、tut.by。
博士。

今、私たちは確かに同じ問題を抱えていると確信しています...
ローマCheplyaka

うん!同意する。ルーターのファームウェアをdd-wrtやopenwrtなどで更新するか、Linuxカーネルをダウングレードすることを考えています。これらの手順を試しましたか?
博士。

1
いいえ。ここで何が起こっているのかを知りたいのですが。
ローマンチェプリカ

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

上記のコマンドをインターネットゲートウェイのiptablesコマンドに追加するまであなたが説明したのと同じ問題がありまし。Inはデフォルトでrp-pppoeパッケージなどに含まれています。ただし、カスタム構成に進み、手動で設定しないと、ゲートウェイの背後にあるLAN上のコンピューターに、説明した問題が発生します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.