Wireshark でしばしば観測される TCP エラー (Wireshark の『Bad TCP』のフィルターで引っ掛かるもの) について、それぞれの意味と原因をまとめます。
[TCP Previous segment not captured]
これは『パケットの Seq# (シーケンス番号) を見る限り、このパケットよりも一つ前に本来あるべきパケットが Wireshark からは見られない』ときに表示されます。
これがマークされる原因はおそらく以下 2 つのどちらかです。
- 一つ前のパケットを取りこぼしている
- キャプチャ開始前に受信している
1 については実際にパケットロスしている可能性もありますが、Wireshark が取りこぼしているだけ (実際のクライアントアプリ⇔サーバアプリ間では通信は取りこぼしていない) のケースもあり得ます。
[TCP ACKed unseen segment]
ACK は本来「このシーケンス番号の直前までのパケットを受信したよ！」という合図なのですが、このマークがされているときは、その直前までのパケットが見えていないにも関わらず、「パケットを受信したよ！」という ACK だけ返っている状態です。
これも [ TCP Previous segment not captured ] に似ていて、主に以下の2つのパターンが考えられます。
- 直前の該当パケットを Wireshark が取りこぼしている
- キャプチャ開始前に該当パケットを受信している
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# のパケットが見えてなければならない。)
[TCP Dup ACK XXX#N]
『【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 Fast Retransmission]
上記のように 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回以上受信が該当するようになっています。
packet-tcp.c のソースコードより引用 1104行目～1109行目
/* If there were >=2 duplicate ACKs in the reverse direction * (there might be duplicate acks missing from the trace) * and if this sequence number matches those ACKs * and if the packet occurs within 20ms of the last * duplicate ack * then this is a fast retransmission
[TCP Out-Of-Order]
Seq# が進んでおらず、かつ一番高い Seq# のパケットを受信してから 3 ms 以内にそれよりも低い Seq# のパケットにマークされます。
原因は以下2つが考えられます。
- NW 経路が(等コスト負荷分散などにより)異なるために本当に順番が入れ替わった
- Dup ACK を3回受信する前、かつ 3ms 以内にその ACK で要求しているパケットを受信した (再送されたのか遅れて来たのかは不明)
ただし、インタフェースの高速化が進んだ現状において、TCP の再送はマイクロ秒オーダーでも発生している現実があり、再送パケットに『Out-Of-Order』のマークが付くことが多いです。
以下は、相手からのレスポンスが15マイクロ秒来なかったため、自発的に再送している様子を捉えています。赤枠のシーケンス番号が同じであることが確認できます。
[TCP Spurious Retransmission]
一度Ack を返したはずのパケットを再度受信するときにマークされます。
クライアント側で Wireshark を仕掛けており、クライアント側では Ack パケットを返しているように見えるが、その後のどこかで Ack パケットがパケットロスしている可能性が高いです。また、可能性としては低いと思われますが、リプレイ攻撃を受けているケースもありえます。
[TCP Retransmission]
これは Fast と異なり、単純に『RTO (再送タイムアウト) 後にパケットが Seq# の順番と異なった順番で受信した場合』にこのマークが表示されます。
【厳選 3 冊】パケットキャプチャを学ぶための本
パケットキャプチャ関連でお奨めの本を 3 冊紹介します。どれも私のサイトからの購入率が高いものです。
追加: "title": "パケットキャプチャの教科書",
削除:
現場での利用方法や具体的なトラブルシュート方法など、現場で活用できる技が豊富に記載されています。サンプルのキャプチャファイルを実際に見ながら学べるので初心者にも分かり易く学べます。
無線を見える化し、セキュリティやトラブルシュートを行うためのノウハウが豊富に記載されています。無線LANのエンジニアなら必携です。
あなたが成長の日々を歩めますように。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント
SEマスターさま
「Wiresharkでの”Bad TCP”エラー」を読ませていただき、感動するくらいわかりやすかったです。他の記事も全部読んで見たいとおもっています。
ひとつ相談ですが、本編の解説がわかりやすいので、私たちの会社のお客様への説明のために、転載元（出展）を記載して上で資料に含めさせていただきたいのですが、可能でしょうか？
箇所は、「Wiresharkでの”Bad TCP”エラー」の回で、Wiresharkでのエラー多発の解析資料に参考資料として利用したいと思っています。ご検討よろしくお願いします。
会社は、某社の営業本部のものです。説明先は地方の某社です。
よろしくお願いします。 加藤
本サイトをご覧頂きありがとうございます。頂いた件、実は本記事はまだ修正中の記事ではありますが、ぜひご活用下さい。出展も記載頂けるとのこと、光栄でございます。
本記事に限らず、別の記事に関しても色々と忌憚のないご意見・ご要望を頂けるとありがたいです。
引き続き、当サイトをごひいきに宜しくお願い致します。