☰

Wiresharkパケットキャプチャポイント[閉じる]

tag-icon • tag-icon networking tc wireshark delay
Wiresharkパケットキャプチャポイント[閉じる]

tc qdisc以下のように、eth2インターフェイスのパケットを使用して遅延を追加しています。

sudo tc qdisc add dev eth2 root netem delay 100ms 10ms 25%

その後、ホストにpingを実行していくつかの結果を得ました。ターミナルの結果には74ミリ秒のRTTが表示され、Wiresharkタイムスタンプに基づいてRTTを計算した結果、約64ミリ秒でした。

これは、Wiresharkがlibpcapからのパケットをすぐに表示することを意味します。 libpcap は NIC の後ろにあり、すべての netem 待ち時間は libpcap がパケットを確認した後にのみ追加されます。最終結果に対して、pingプログラムはnetem遅延（例えば100+ミリ秒）の後にパケットをチェックします。

Wiresharkを使用してアプリケーション層またはnetemで遅延パケットを表示する方法はありますか？

Wiresharkがこれを行うことができない場合、誰かが私に代替案を提案できますか？私はテスト中のボックスの外にある他のLinuxボックスを使用でき、外部ボックスで延期できることを知っています。しかし、私は追加のLinuxボックスを使用することを避けたいと思います。

答え1

Wiresharkはインターフェイスを受信する必要があり、アプリケーション層のパケットを見ることはできません。

Wiresharkなどのツールが本当に必要な場合は、VMまたはコンテナでpingを実行し、Wiresharkが仮想インターフェイスまたはVMを物理インターフェイスに接続するブリッジで（ホスト上で）受信できるようにすることができます。仮想マシンを作成する負担を避けたい場合は、vethペアを設定することもできます。

ただし、興味のあるものがタイミングであれば、strace現在の構成で十分です。

# strace -r -T -e network ping 1.2.3.4
...
0.000113 sendmsg(...) = 64 <0.000032>
0.000055 recvmsg(...) = 84 <0.101680>
64 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=101 ms
...

山括弧の間には、システムコール中に費やされた時間があります。瞬間的なためsendmsg（バイトがサブネットワーク層に直接移動する）、次の時間はrecvmsg実際にpingメッセージ（つまりRTT）を送受信するのにかかる時間を（おおよそ）示しています。

関連情報