Wireshark でしばしば観測される TCP エラー (Wireshark の『Bad TCP』のフィルターで引っ掛かるもの) について、それぞれの意味と原因をまとめます。

これは『パケットの Seq# (シーケンス番号) を見る限り、このパケットよりも一つ前に本来あるべきパケットが Wireshark からは見られない』ときに表示されます。

これがマークされる原因はおそらく以下 2 つのどちらかです。

1 については実際にパケットロスしている可能性もありますが、Wireshark が取りこぼしているだけ (実際のクライアントアプリ⇔サーバアプリ間では通信は取りこぼしていない) のケースもあり得ます。

ACK は本来「このシーケンス番号の直前までのパケットを受信したよ！」という合図なのですが、このマークがされているときは、その直前までのパケットが見えていないにも関わらず、「パケットを受信したよ！」という ACK だけ返っている状態です。

これも [ TCP Previous segment not captured ] に似ていて、主に以下の2つのパターンが考えられます。

TCP Previous segment not captured と異なり、これが見えるときは、実際のクライアントアプリ⇔サーバアプリ間では通信は取りこぼしていないことは確定です。つまり、アプリレベルでは正しく送受信できているけど、Wireshark ではパケットを取りこぼしています。

例えば、以下は 192.168.0.23 から 192.168.0.22 に 500MiB のデータを SMB で送付しているときのパケットキャプチャですが、Seq#=6033514, Len=1460 のパケットに対する ACK が、本来は 「6033514+1460=6034974」になるところが、「6138634」となっており、[TCP ACKed unseen segment] がマークされています。

Time の列を見ると6.311672 で大量のパケットが来ていますが、その後を Wireshark で取りこぼしているように見受けられます。ですがファイル共有サービス (SMB) としては正しく受信できているため、ACK はキャプチャでは見えていないパケットに対しても ACK を返しているのだと推定できます。

ついでにその次のパケットが [TCP Previous segment not captured] でマークされていますね。これも同様に、ファイル共有サービス (SMB) としては取りこぼしていないけど、Wireshark で取りこぼしている、と推定できます。(本来は 6138634 - 1460 = 6137174 の Seq# のパケットが見えてなければならない。)

『【Wireshark 上の一番左の Field の No. が XXX であるパケット】と同じ Ack# (応答確認番号)のパケット (N回目) が観測されたとき』にこのマークが表示されます。

例えば Ack# = 1000 のときは「次は Seq# = 1000 のパケットが欲しいよ！」という意味になります。これを何度も送る、というのは Seq# = 1000 のパケットが受信できていないため、再送要求をしている、と考えられます。

なのでこの Dup ACK が多発している場合は、少なくない頻度でパケットロスが発生していることが考えられます。

また、Seq# が進んでいないパケットを受信したときは『TCP Fast Retransmission』か『TCP Out-Of-Order』か『TCP Spurious Retransmission』か『TCP Retransmission』かの4つのうちのいずれかに分類されます。

上記のように TCP Dup ACK が3回 (初回も併せて4回) 送られてきた場合、TCP の Fast Recovery アルゴリズムが動作し、相手は RTO (再送タイムアウト) を待たず再送をします。Wireshark から見て、このアルゴリズムにより再送されたと考えられるものにこのマークが表示されます。具体的なコードの実装は「Seq# が進んでおらず、同じ Ack# のパケットを2回以上受信し、かつ最後の Dup ACK から 20 ms 以内に、その Ack# と同じ Seq# のパケットを受信もしくは送信したときにマークされます。

Fast Recovery Algorithm としては Dup ACK が3回以上受信した場合が該当するのですが、WireShark の実装として、Dup ACK の取りこぼしも考慮し、Dup ACK 2回以上受信が該当するようになっています。

Seq# が進んでおらず、かつ一番高い Seq# のパケットを受信してから 3 ms 以内にそれよりも低い Seq# のパケットにマークされます。

原因は以下2つが考えられます。

ただし、インタフェースの高速化が進んだ現状において、TCP の再送はマイクロ秒オーダーでも発生している現実があり、再送パケットに『Out-Of-Order』のマークが付くことが多いです。

以下は、相手からのレスポンスが15マイクロ秒来なかったため、自発的に再送している様子を捉えています。赤枠のシーケンス番号が同じであることが確認できます。

一度Ack を返したはずのパケットを再度受信するときにマークされます。

クライアント側で Wireshark を仕掛けており、クライアント側では Ack パケットを返しているように見えるが、その後のどこかで Ack パケットがパケットロスしている可能性が高いです。また、可能性としては低いと思われますが、リプレイ攻撃を受けているケースもありえます。

これは Fast と異なり、単純に『RTO (再送タイムアウト) 後にパケットが Seq# の順番と異なった順番で受信した場合』にこのマークが表示されます。

パケットキャプチャ関連でお奨めの本を 3 冊紹介します。どれも私のサイトからの購入率が高いものです。

追加: "title": "パケットキャプチャの教科書", 削除:

現場での利用方法や具体的なトラブルシュート方法など、現場で活用できる技が豊富に記載されています。サンプルのキャプチャファイルを実際に見ながら学べるので初心者にも分かり易く学べます。

無線を見える化し、セキュリティやトラブルシュートを行うためのノウハウが豊富に記載されています。無線LANのエンジニアなら必携です。

あなたが成長の日々を歩めますように。

あなたが成長の日々を歩めますように。