Wiresharkでの”Bad TCP”エラー

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

スポンサーリンク
スポンサーリンク

[TCP Previous segment not captured]

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

1つ前のパケットがキャプチャできていない原因はおそらく以下2つのどちらかです。

  1. 一つ前のパケットがロスしている
  2. キャプチャ開始前に受信している

スポンサーリンク

[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から20ms以内に、その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#のパケットを受信してから3ms以内にそれよりも低いSeq#のパケットにマークされます。

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

  1. NW経路が(等コスト負荷分散などにより)異なるために本当に順番が入れ替わった
  2. Dup ACKを3回受信する前、かつ3ms以内にそのACKで要求しているパケットを受信した(再送されたのか遅れて来たのかは不明)

スポンサーリンク

[TCP Spurious Retransmission]

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

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

スポンサーリンク

[TCP Retransmission]

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

Wiresharkの勉強については、以下の書籍がお薦めです。

スポンサーリンク
スポンサーリンク
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
スポンサーリンク

Comment

  1. 加藤正寛 より:

    SEマスターさま
    「Wiresharkでの”Bad TCP”エラー」を読ませていただき、感動するくらいわかりやすかったです。他の記事も全部読んで見たいとおもっています。

    ひとつ相談ですが、本編の解説がわかりやすいので、私たちの会社のお客様への説明のために、転載元(出展)を記載して上で資料に含めさせていただきたいのですが、可能でしょうか?
    箇所は、「Wiresharkでの”Bad TCP”エラー」の回で、Wiresharkでのエラー多発の解析資料に参考資料として利用したいと思っています。ご検討よろしくお願いします。
    会社は、某社の営業本部のものです。説明先は地方の某社です。

    よろしくお願いします。  加藤

    • se-master より:

      本サイトをご覧頂きありがとうございます。頂いた件、実は本記事はまだ修正中の記事ではありますが、ぜひご活用下さい。出展も記載頂けるとのこと、光栄でございます。
      本記事に限らず、別の記事に関しても色々と忌憚のないご意見・ご要望を頂けるとありがたいです。
      引き続き、当サイトをごひいきに宜しくお願い致します。