☰

ComCast 経由で TigerVNC が数分間停止する原因を突き止める; なぜ「* * *」なのか

tag-icon • tag-icon ssh networking internet troubleshooting tigervnc
ComCast 経由で TigerVNC が数分間停止する原因を突き止める; なぜ「* * *」なのか

TigerVNC セッションで断続的に、時には非常に長い遅延が発生する場合、その根本原因を突き止めるにはどのようなテクニックがありますか?

TigerVNCを使用してSSH経由でリモートで作業しています。ほとんどの場合、画面は応答します。ただし、1日に何度も応答に遅延が発生します。遅延は0.5秒から数秒に及ぶことがあります。分文字の入力、マウスの動き、アクションはバッファリングされたままです。コード行を書いている途中でこれが発生すると、非常に混乱を招きます。

これらの遅延の間、ping は (これまでのところ) 問題なく通過し、その他のインターネット アクセスは正常に動作します。

私たちは比較的高性能なプランで ComCast を利用しています。私のラップトップはスイッチを介してルーター/ケーブル モデムに有線接続されているため、WiFi は問題ではありません。私が働いている会社は別の ISP を利用しています。IT 部門によると、ComCast を利用している他のユーザーも同様の問題を抱えているそうですが、現在私が住んでいる地域では他の ISP オプションは利用できません。

トレースルート（若干編集済み）...一時停止ホップ 9 で、* * *そのホップのショーを表示します。

scott@scott-HP-Pavilion-15-dk0xxx:~$ traceroute <redacted>.com
traceroute to <redacted> (<redacted>), 64 hops max
  1   192.168.0.1  0.660ms  1.224ms  0.691ms 
  2   <redacted>  12.768ms  13.083ms  9.222ms 
  3   24.153.80.113  12.028ms  9.766ms  10.039ms 
  4   69.139.164.217  11.650ms  17.848ms  10.298ms 
  5   24.124.128.249  14.816ms  10.285ms  10.711ms 
  6   68.86.93.165  11.076ms  15.245ms  11.115ms 
  7   96.110.40.89  11.764ms  12.553ms  10.458ms 
  8   96.110.32.234  10.686ms  9.901ms  10.849ms 
  9   *  *  *    <---  this part runs slowly.
 10   64.125.23.46  11.342ms  9.551ms  8.964ms 
 11   64.125.29.3  10.094ms  11.916ms  11.782ms 
 12   64.125.36.106  11.953ms  9.912ms  9.900ms 
 13   <redacted>  14.820ms  9.314ms  10.101ms 
 14   <redacted>  12.224ms  9.792ms  10.748ms 
 15   <redacted>  10.585ms  11.545ms  12.545ms 
 16   *  *  * 
...
 64   *  *  *

Comcast のテクニカル サポートに電話したところ、サポート チケット番号が提示され、(かなり新しい) ケーブル モデムを交換するよう促す反射的な試みが行われたものの、(今のところ) 折り返しの電話はありませんでした。ただし、問題は通常の操作中に速度が遅いということではなく、接続が (私の知る限り) 切断されることもありません。ping やその他のインターネット アクセスは、一時停止中でも遅延なく動作し続け、キー入力やマウス操作はバッファリングされたままです。

以下の点についてのアイデアをいただければ幸いです:

  • 問題をソフトウェア、ネットワークの問題、あるいは に切り分けるにはどうすればよいでしょうか?
  • 隔離に役立つツール
  • 後者の場合、ISPに何が問題なのかを伝え、それを修正できるアクセス権を持つ誰かにそれが伝わることを期待する方法
  • これを乗り越える方法（おそらく別の ISP が利用できるオフィスを借りるだけ）

編集： 使用の提案ごとにsudo journalctl -b 0 -u NetworkManager：

ログには次の三つ組が多数表示されます:

  • connectivity: (en01) timed out、その後すぐに次の文が続きます:
  • manager: NetworkManager state is now CONNECTED_SITE、
  • その後、毎回 4 分 31 秒の遅延(?) が経過します。
  • manager: NetworkManager state is now CONNECTED_GLOBALシーケンス。

システム名を省略した例:

Oct 24 17:14:06 <name> NetworkManager[1065]: <info>  [1635120846.1948] connectivity: (eno1) timed out
Oct 24 17:14:06 <name> NetworkManager[1065]: <info>  [1635120846.1949] manager: NetworkManager state is now CONNECTED_SITE
Oct 24 17:18:37 <name> NetworkManager[1065]: <info>  [1635121117.3196] manager: NetworkManager state is now CONNECTED_GLOBAL

答え1

IP パケットには、パケットが永久にループするのを防ぐために設計された Time-To-Live フィールドがあります。

各ルータは、パケットが転送されるたびに TTL フィールドを減らす必要があります。

TTL が 1 未満になると、ルータは TTL フィールドの有効期限が切れたことを知らせる ICMP パケットを送り返す必要があります。また、パケットをドロップする必要があります。

tracerouteTTL 1 で 3 つのパケットを送信し、ICMP パケットを待機することで動作します。所要時間とレポートの送信元を報告します。次に、TTK 2 で 3 つのパケットを送信し、ホストと時間を報告します。最初は TTL が 3、次は TTL が 4 というように続きます。ただし、プログラムは無期限に待機するわけではありません。ur が ICMP 応答を受信しない場合は、 を出力します*。

したがって、TTL が 9 の場合、ICMP 応答は受信されません。これは、ルータが応答を送信しないように設定されているか、ファイアウォール ルールによってパケットがブロックされている可能性があります。応答を待っているだけで、速度が遅くなります。

TTL 値が 16 ～ 64 の場合、ファイアウォールが原因と考えられます。

これらすべては完全に正常問題があるという証拠は示されていません。

PING データが提供されていないため、ネットワークに輻輳があるかどうかはわかりません。

あなたは見つけるかもしれないmtr https://github.com/traviscross/mtrより良い洞察が得られます。

関連情報