4月 3, 2008

Wiresharkが1.0にアップデートされた
早速、使用するお仕事が…
あるサーバ間の通信が異常でアプリケーションがエラーになってしまうとのこと。
一晩かけて、10万パケットのデータをチェック。とは言っても、エラーになった時間近辺を丹念にみてまわればいいだけなのだが。
エラーになった箇所の大部分がコネクション確立後にすぐ切られていた。
具体的には
10.0.1.1:50000 -> SYN -> 10.0.2.1:8080
10.0.1.1:50000 <- SYN,ACK <- 10.0.2.1:8080 10.0.1.1:50000 -> ACK -> 10.0.2.1:8080
10.0.1.1:50000 -> FIN,ACK -> 10.0.2.1:8080
10.0.1.1:50000 <- ACK <- 10.0.2.1:8080 さらにエラー箇所を丹念に調べてみると、不思議なことが判明 10.0.1.1:50000 -> SYN -> 10.0.2.1:8080
10.0.1.1:49999 <- FIN,PSH,ACK <- 10.0.2.1:8080 10.0.1.1:49999 -> ACK -> 10.0.2.1:8080
10.0.1.1:49999 -> FIN,ACK -> 10.0.2.1:8080
10.0.1.1:50000 <- SYN,ACK <- 10.0.2.1:8080 10.0.1.1:50000 -> ACK -> 10.0.2.1:8080
10.0.1.1:50000 -> FIN,ACK -> 10.0.2.1:8080
10.0.1.1:50000 <- ACK <- 10.0.2.1:8080 10.0.1.1:49999 <- ACK <- 10.0.2.1:8080 どこも、[SYN]と[SYN,ACK]の間に、他のポートの[FIN,PSH,ACK]が挟まっている時に限って、コネクション確立後に[FIN,ACK]を送信していた。 なんで、他のポートのFINが影響しているような状況なんだ？TCP実装上考えられないけど、状況証拠的には影響しているとしか思えん。 さすがに夜勤明け、15時まで残っての状態で私はもうふらふら…、他の人に引き継ぎして帰ってきた。引き継いだ人ごめんなさい、これは原因を突き止めるのがかなり難しいと思う…って考えてみたら、私の役割は一次対応なんだから、ここまでする必要無かったのでは？ それにしても、頭がぼーっとしてきたせいか、パケットの一覧を見ていると、読まなくてもパターン認識で上記のような、おかしなところが判別できるようになった気がする。もちろん別のパターンの異常には対応できないが…。