BBルータでTCP通信のデータ部が捨てられている？

質問

インターネット上のServerと自宅PC間でWebを併用したデータ交換をしているのですが、ある限られたデータ部のみ、自宅のBBルータにより毎回捨てられているようで受信できません。

Serverと自宅PC(Client)にEtherealを同時に仕掛けPacketをモニタリングしました。
Server側のLogを見る限り、Serverは該当データを正しく送り、BBルータも正しく受信しているようです。
しかし、Client側のLogを見ると、その部分は Len=0 になっており、ヘッダ部だけのPacketが送信されて来たかのようになっております。
BBルータの設定可能項目では、いたって通常の設定になっており、また、自宅PCはWindowsXP SP2でFirewallはOff、ウィルス対策ソフトもアンインストール状態で実験しております。今回のトラブル以外は全てにおいて不具合は発生しておりません。

何か単純なTCP規則違反に該当しているのではとRFC793も確認したのですが原因がわかりません。
該当部分のEtherealのLogは以下の通りです。

何か大事なことを忘れていそうなのですが、どなたかご教授をお願い致します。

<Server側Log>
※No.292～294は3way handshakeです。
※()内はTCP詳細部の内容抜粋です。
※Server側のPortはWeb併用なので80番をそのまま使用。
No.　SRC　 DIST　 Prot　 Info
295 Client Server HTTP Continuation or non-HTTP Trafic

296 Server Client HTTP Continuation or non-HTTP Trafic
(http > 62327 [PSH,ACK] Seq=1 Ack=24 Win=65512 Len=90)

297 Server Client TCP http > 62327 [FIN,ACK] Seq=91 Ack=24 Win=65512 Len=0

298 Client Server TCP 62327 > http [ACK] Seq=24 Ack=92 Win=65535 Len=0

299 Client Server TCP 62327 > http [FIN,ACK] Seq=24 Ack=92 Win=65535 Len=0

300 Server Client TCP http > 62327 [ACK] Seq=92 Ack=25 Win=65512 Len=0

<Client側Log>
※No.295と297～300はServer側Logと矛盾はありません。
No.　SRC　 DIST　 Prot　 Info
296 Server Client TCP http > 1157 [PSH,ACK] Seq=1 Ack=24 Win=65512 Len=0
以上

回答No.6

goood7

質問者です。
ハードのNetwork Analyzerを借りてきて、BBルータのWAN側/LAN側両方のPacket Capturingを同時にやることができました。
その結果、やはり推測通り、BBルータで当該Packetのデータ部が捨てられておりました。
当該BBルータを使わない特殊な方法でテスト通信をしたところ、データ部は捨てられず、通信が成功しているのが確認できました。

これで、原因は以下のどちらかに絞られました。
1. BBルータのProtocol Stack実装に問題がある。
2. Serverが何らかの通信規約違反をしていて、BBルータがデータを
　　捨て、ACKのみを中継している。
さて、これからが大変です。

回答いただいた皆様、ありがとうございました。

回答No.5

zenzen99

一応参考までに。。。

１．サーバからの"PSH/ACK"に対して
２．クライアントからの"ACK"がある
３．サーバからの"FIN/ACK"に対して
４．クライアントからの"ACK"がある
５．クライアントからの"FIN/ACK"に対して
６．サーバからの"ACK"がある

のが正常シーケンスのはずです。

見えているシーケンスでは
１．＝296
２．ない　（想定では　sec=24 ack=91 len=0）
３．＝297
４．＝298
５．＝299
６．＝300

ということでPUSHに対するACKがない以外は想定通りのシーケンスです。

そもそも受け取ったかどうかもわからないままにFINを投げるという動作は通常ありえないと考えます。
要は再送しないという考え方になるので、それならTCPを使わなくてもいいわけで。
そう考えると
●アプリの作りとして先にFINを投げる仕様がおかしいか
●想定外のところからRSTが返ってきているか（296と297の間）
の２択と思います。

個人的には後者じゃないかなぁと思いますが。

お礼

上の補足に書いた、友人宅で当該通信が問題なく行われている場合のPacket Capturingデータが届きました。

<Server側Log>
BBルータのPort#と双方のWin値が異なる他は質問時に記載したトラブル時のものと全く同じデータでした。

<PC側Log>
No. SRC DEST Prot Info
295 PC Server HTTP Continuation or non-HTTP Trafic
(1244 > http [PSH,ACK] Seq=1 Ack=1 Win=8760 Len=23)

296 Server PC HTTP Continuation or non-HTTP Trafic
(http > 1244 [PSH,ACK] Seq=1 Ack=24 Win=65504 Len=90)

297 Server PC TCP http > 1244 [FIN,ACK] Seq=91 Ack=24 Win=65504 Len=0

298 PC Server TCP 1244 > http [ACK] Seq=24 Ack=92 Win=8670 Len=0

299 PC Server TCP 1244 > http [FIN,ACK] Seq=24 Ack=92 Win=8670 Len=0

300 Server PC TCP http > 1244 [ACK] Seq=92 Ack=25 Win=65504 Len=0

見てわかるように、PC側もトラブル時と基本的なやりとりは全く同じです。違うのはNo.296がLen=90となっていて、それを正常に受信できていることと、それ以降のSeq値とACK値がそれを反映していることです。
私の解釈では、上のデータからもトラブル時にはBBルータがデータを破棄しているのではないかという疑いが強まりました。
他の解釈がありましたらよろしくお願いします。

それから、上のデータと共に有益な情報が入手できました。
それは、「ネットワーク機器の中には、ある条件が重なった時、独立したACKしか受付けず、仮にそのACKにデータが付いて来た場合、そのデータを破棄し中継しないというプロトコルスタック実装のものがある」という情報です。
この情報が正しいかどうか現段階ではわかりませんが、もし正しいと仮定した場合、今回のケース(No.296)は正にそれにあてはまります。
残念ながら友人も詳細までは覚えていないとのことなので、取り敢えずはYahooBBに確認すると共に、TCPの仕様がどうなっているかRFC等を調べてみることにします。

今後も引き続き、解釈が違っているというアドバイスや、解決につながりそうな情報がありましたらよろしくお願いします。

補足

回答ありがとうございます。

私の知識の整理と確認のために、TCPについて書かれているWebを何ヶ所か見てみました。
http://www.atmarkit.co.jp/fwin2k/serial/index/index.html
など数ヶ所です。

> １．サーバからの"PSH/ACK"に対して
> ２．クライアントからの"ACK"がある
> ３．サーバからの"FIN/ACK"に対して
> ４．クライアントからの"ACK"がある
> ５．クライアントからの"FIN/ACK"に対して
> ６．サーバからの"ACK"がある
これは基本的ないしは理想的な形態の場合ですね。
しかし、TCPはある複数の受信に対し、まとめてACKを返したり、ACKと共に次のデータを一緒に送ったり、順番が入れ替わってもリカバリできる仕組みになっていたりするので、必ずしも上のように1から6までが独立して必要なわけでもないようです。

例えば、クロージングの実例では下記のようになっていることを結構多く見かけます。
1. FINを送る
2. 1に対し FIN/ACK(1のFINに対するACKと自らのFIN)を同時に送る
3. 2に対しACKを返す

また、FINは「もう受信しない」の意味ではなく、「以上でもう送るべきものはない」の意味だそうで、データを送った直後に相手のACKを待たずに送っても良いどころか、送るべき最後のデータにFINフラグを立てて送るのもアリのようです。
FINを受信した側は、自らFINを送るまでは何回でもデータ送信可能です。従って、

> そもそも受け取ったかどうかもわからないままにFINを投げるという
> 動作は通常ありえないと考えます。
これは、私も間違えて理解していたのですが、TCPの仕様上は全く問題ないようです。

それから、ACKの値はやはり実際に受信した値を返さなければならないようです。その値を元にWindow制御すると書かれています。

これらのことから、私は以下のように解釈できるのではないかと思っています。

295: 23バイト送信
296: ACK=24なので295受信済みACK、同時に90バイトのデータ送信
297: Clientに対するFIN
298: ACK=92なので296と297受信済みACK
299: Serverに対するFIN
300: 299に対するACK

> ●想定外のところからRSTが返ってきているか（296と297の間）
これは該当しないことが確認されております。

それから、リピータHUBを使ってWAN側のPacket Capturingを試みましたが、Capture用のPCをつなぐと、本来の通信(Client PC⇔Web Server)が不安定になりうまくいきませんでした。

※友人宅で当該通信が問題なく行われている場合のPacket Capturingが
　できそうなので、届き次第書き込みます。

回答No.4

zenzen99

言ってることがやや右往左往しているようですが。。。

まずBBルータの外側でキャプチャするのにグローバルは複数いりません。
MAC管理だったらL2つないでSpanとかできるのでは？
それすらNGならおばかなHUBを間にかましてPCにグローバル振らなければいいと思う。

>しかし、サーバ側のLog No.298からわかるように、BBルータは90バイト受信したとサーバにACKを返しているので、バイト数的には間違いなく受信していると解釈するのが自然だと思います。

う～ん見方を間違えてるなぁ。
BBルータは90バイトを受け取ったから"ACK=92"なのではなくて、
サーバからきたFINに対して"ACK=91"に対して"+1"して返しているだけ。
つまりNo.298のクライアント=>サーバのACKは「PUSHに対するものではなく、FINに対するもの」ということ。
それともまた情報はしょってる？
残念ながら公開されている情報からはクライアント（BBルータ含む）が
90バイトのデータを受け取ったことはどこにもないです。

>アプリケーション層では意味あるデータですがTCPでは当然ただのASCII文字データ列として解釈されます。
>(仮にエラーコードだった場合でも、それはアプリケーション層のエラーコードであり、アプリケーションに渡されるべきものなので、TCPでは解釈されず、BBルータがそれを判断材料にして勝手に落とすことはないと理解しております)

そこまでわかっててなんで「BBルータで破棄される」と聞いたのかよくわかりません。
個人的にはそれ以前の問題で、サーバ側のキャプチャだけで判断すると
「PSH/ACKに対するACKがこないのに、FIN/ACKを投げる」という仕様が不思議でなりません。
どうやってキャプチャしたかわかりませんが、フィルタしているとしたら別のアドレスの人がリセット返してませんか？

最近のBBルータであればある程度のFW機能が搭載されていることもありそうで、
不適切なスクリプトや表現、文字列が含まれてたりすると破棄されたりするのではないか？
と勝手に想像しています。
それはBBルータに限らずインターネット上にあるといわれるサーバ側の環境も含めてですが。

だからBBルータの外側でとってみては？というアドバイスに行き着くんですけどね。

補足

貴重な時間を割き回答いただきありがとうございます。

> MAC管理だったらL2つないでSpanとかできるのでは？
残念ながらL2スイッチは持ってないのです。

> それすらNGならおばかなHUBを間にかましてPCにグローバル振らなけ
> ればいいと思う。
私の理解では、PCに同じネットワークアドレスを持つIPを振る必要があると思っていたのですが、それは間違いということですね。
それならできそうですのでリピータHUBを購入しやってみたいと思います。

> BBルータは90バイトを受け取ったから"ACK=92"なのではなくて、
> サーバからきたFINに対して"ACK=91"に対して"+1"して返しているだ
> け。
え？ ACKは実際に受取ったデータのバイト数に"+1"して返すものだと理解していますが、違いますか?
FINに対するACKはNo.299で、No.298のACKはFINに対するACKではなく、No.296に対するACKだと思っていますが、この理解は合ってますか？
この場合は、たまたまACKを返す前にFINを受信したので、それを含めて92を返していると思います。
送られてきたSeq値に"+1"するだけだと受取れなかった場合の再送処理ができないような…。う～ん、私の理解が根本的に間違ってるのかなぁ。

> そこまでわかっててなんで「BBルータで破棄される」と聞いたのかよ
> くわかりません。
Captureデータから、私は「BBルータで破棄されている」と解釈したのですが、その解釈が正しいかどうか、もし間違っていれば、どの部分の解釈が間違っているかお聞きしたかったのです。

> 個人的にはそれ以前の問題で、サーバ側のキャプチャだけで判断する
> と「PSH/ACKに対するACKがこないのに、FIN/ACKを投げる」という仕
> 様が不思議でなりません。
この部分については、私もそう思いますので、改善すべき仕様として相手に伝えてあります。

> 最近のBBルータであればある程度のFW機能が搭載されていることもあ
> りそうで、不適切なスクリプトや表現、文字列が含まれてたりすると
> 破棄されたりするのではないか？
このBBルータにもFW機能が搭載されております。
このBBルータ提供元のYahooBBの現段階での見解は、
・FW機能でパケットのデータ部のみを破棄する機能はない。
・TCP或いはその他の通信規則(RFC等)に関わる内容かもしれないので、
　調査するため時間が欲しい。
です。

> だからBBルータの外側でとってみては？というアドバイスに行き着く
> んですけどね。
やってみます。

回答No.3

zenzen99

NAPTね。。。

あとは「本当にBBルータで破棄されているのか」を検証してみると良いのでは。
BBルータの前段・後段でキャプチャして同じようにパケットの比較。

そこで同一（LEN=0）の結果が出るようであればBBルータで破棄されているのは間違いないということになりますよね。
とは言えそれがわかったところでどうすればよいかわかりませんが。。。（なんで破棄されるかわからないし）
ルータでデバッグでも取れればいいんですけどね。

>ある限られたデータ部のみ
とおっしゃってますが、特定データのみ受信ができないということですか？
たとえばサーバの同じフォルダに適当なテキストデータを置いても見れないのか
はたまたどこのサイトを見てもデータがGETできていないのか。

ついでにもう一つ。
サーバからデータを送信したと思われる（LEN=90）キャプチャデータのデータの中身は解析できませんか？
90Byteってデータとしては少ない感じもするので何気にエラーコードだったりしないかなぁということです。

補足

回答ありがとうございます。

> BBルータの前段・後段でキャプチャして同じようにパケットの比較。
BBルータのWAN側で簡易的にCaptureする方法としてリピータHUBを介す方法が考えられますが、Global IPアドレスがもう1個必要となるためできません。YahooBBの場合、MACアドレスを管理しているのでPCをダイレクトに接続することもできません。
しかし、サーバ側のLog No.298からわかるように、BBルータは90バイト受信したとサーバにACKを返しているので、バイト数的には間違いなく受信していると解釈するのが自然だと思います。

それから、ある限られたデータ部と書いたのは、同時に複数のTCPコネクションが張られているのですが、他は問題なく送受信できているからです。
当該TCPコネクションの3Way Handshake直後の一発目の要求に対する回答データがPCに返ってきません。(この部分は定型的なやり取りなので再現性100%)

データの中身はわかっております。
アプリケーション層では意味あるデータですがTCPでは当然ただのASCII文字データ列として解釈されます。
また、90バイトというのはエラーコードではありません。サーバ側のCapture Logのデータ部の中身で確認できます。
(仮にエラーコードだった場合でも、それはアプリケーション層のエラーコードであり、アプリケーションに渡されるべきものなので、TCPでは解釈されず、BBルータがそれを判断材料にして勝手に落とすことはないと理解しております)

回答No.2

zenzen99

MTUとかWindowSizeとかが関わってんのかなぁと思いましたが、
よくよく見ると　サーバ－＞クライアント　のLengthが90。。。

このサイズならフラグメント等の問題ではないので、

ざーっとシーケンスを眺めてみると
296のパケットがおかしい

Server>
296 Server Client TCP http > 62327 [PSH,ACK] Seq=1 Ack=24 Win=65512 Len=90

Client>
296 Server Client TCP http > 1157 [PSH,ACK] Seq=1 Ack=24 Win=65512 Len=0

Destinationポートの指定がかわっています。
この状態だと正常通信は無理な気がしますが。。。

3WayHandShake時のシーケンスのそーいった不整合はありませんか？

補足

回答ありがとうございます。
質問が言葉足らずで申し訳ありませんでした。
BBルータでNAPTが機能しているので、

BBルータ Port 62327 ＝ PC Port 1157

とご理解下さい。

回答No.1

123admin

要はパケットロスが起こっているって事でしょうか？

提示されているLogよりもtracertコマンドのLogの方が適切かもしれません。

tracertでネットワークの経路を調査する
http://www.atmarkit.co.jp/fwin2k/win2ktips/290tracert/tracert.html

YBBに問い合わせる前にサーバーと自宅のＰＣのMTUやRwinは確認の上明記しておいた方が良いでしょうね。
YBBサポートは経験上ＰＣ側に責を求める傾向にあります。
実際に大部分はその通りなのですが・・・

ロストするDATAは画像やバイナリでしょうか？
結構多いのがＭＴＵの設定に問題がある場合もあります。
サーバー側がPPPoEでの接続の場合にMTUが1500のままだったりすると起こる可能性がありますね。

サーバーやＰＣ側の設定に間違いない場合には、正直テクニカルサポートにまわして貰うのに相当の努力が必要です。
明らかにMDFや局側の不具合なのを調べ上げて善処を求めたにも関わらず不満なら解約してくださいと対応された方々を知っています。

まぁ以前と違いマイナス成長していますから門前払いは無いかもしれないけど、以前のトラブった時のＹＢＢの対応はそんなものです。

価格的な優位性もありませんので、この頃は一度他に移る事を薦めます。
なんせ対応はモデム交換を行うのがデフォの処置ですから。

補足

回答ありがとうございます。
パケットロスではありません。
パケットは全て受信できていますが、BBルータでNo.296のデータ部のみ破棄されている状態に見受けられるのです。
ヘッダ部は、あたかもサーバーがデータ部をつけないで送信したかのごとく辻褄をきちんと合わせて直してPCに送ってきていますので何か意図的にやっていると思っています。