From hibari.michiro ＠ lab.ntt.co.jp Mon Dec 10 12:40:38 2012 From: hibari.michiro ＠ lab.ntt.co.jp (Hibari Michiro) Date: Mon, 10 Dec 2012 12:40:38 +0900 Subject: [Ultramonkey-l7-develop 837] Re: =?iso-2022-jp?b?W1VsdHJhbW9ua2V5LWw3LXVzZXJzIDUzMV0gUmU6IFVs?= =?iso-2022-jp?b?dHJhTW9ua2V5LUw3IHYzGyRCN08kTj1oTX0wWz5vO3Y+XUpzOXAbKEI=?= In-Reply-To: <50C1AA8E.5030305@nttcom.co.jp> References: <20121204190604.1E90.E9CC3206@gcc.co.jp> <50BFF311.6010808@lab.ntt.co.jp> <20121206123445.1EA8.E9CC3206@gcc.co.jp> <50C0232C.7040609@lab.ntt.co.jp> <50C04E72.1090201@nttcom.co.jp> <50C086C8.1010103@nttcom.co.jp> <50C188F3.1000101@nttcom.co.jp> <50C18F5C.5020308@nttcom.co.jp> <50C1A27F.7080804@nttcom.co.jp> <50C1AA8E.5030305@nttcom.co.jp> Message-ID: <50C559B6.5070808@lab.ntt.co.jp> 雲雀です。 コード追っかけてみました。 本事象の原因は以下の内容だと思います。 > 他のHTTPヘッダ要素も含めて、4096を超えると壊れてるって > 感じでしょうか。 中野さんに解析していただいた上記の通り、send_bufferを上回る（※） データを送るときの処理にバグが潜んでいました。 具体的には、protocol_module_ip.cppのput_data_into_sendbuffer()関数内、 「//sendbuffer rest size is too small」コメント以下のelse文が該当箇所に なります。 send_bufferを上回った場合、以下の処理で残ったデータの 開始位置とサイズを計算していますが、 //set item position buffer_element.first += sendbuffer_rest_size; buffer_element.second -= sendbuffer_rest_size; その後、data_ptr->buffer_sequenceにpushする処理が 抜けているため、残ったデータの開始位置とサイズが 更新されていませんでした。 そのため、残りのデータを送信しようとしたときに、 前と同じデータの開始位置で送信を行うため、 同じデータが2回送られてしまい、HTTPリクエストが壊れた と考えられます。 本田さんから頂いたパケットキャプチャからはsize limited版 でしたので、上記事象が記録されているデータは取得 できませんでしたが、手元環境で同様のリクエストを送信した ところ、上記事象が確認できました。 【添付ファイル】 send.txt 送信したリクエスト recv.txt バックエンドが実際に受信したデータ 本事象はipモジュールのみ発生する問題で、 XFFを追加して、送信データがsend_bufferを上回るサイズになった場合や、 Sorry-URI書き換え時にも同様の事象が発生します。 修正patchを作成したので、別メールで投稿します。 （※）補足　send_bufferを上回る場合について、 recv_bufferとsend_bufferは同じサイズであるため、 どんなに大きなサイズのデータが送られてきても、 受信処理の中で、send_bufferサイズを上回るデータを 取得することはない。 送信データサイズがsend_bufferサイズを上回るのは、 データ送信前に、URIの書き換えやXFFの追加を行うことで、 データサイズが増加した場合にのみ起こる。 以上、宜しくお願いいたします。 (2012/12/07 17:36), 中野　宏朗 wrote: > 中野@幕張です。 > > sessionlessとipのhandle_client_recv見比べてるんだけど、 > protocol_module_sessionless.cppのL1998からあるルーチン、 > > //there are still rest data need to　process > //new status created and add to status list > while (request_data_remain_size > 0) { > > から始まる部分がprotocol_module_ip.cppのほうにはなさそう > に見えるんだけど・・・ > > ここかな？ > > (2012/12/07 17:02), 中野　宏朗 wrote: >> 中野@幕張です。 >> >> urlencodeされたPOSTデータの部分だけ切り出して >> サイズを測ったら、パターン1、パターン2ともサイズが >> 3.3KBくらいまではOKで、3.6KBくらいになると駄目になってました。 >> >> 調べると、HTTPヘッダを入れるバッファはMAX_BUFFER_SIZEまでで >> 確保されていて、MAX_BUFFER_SIZEはconfigure.iniの >> l7vs_max_buffer_size=4096で定義されているのかな？ >> >> 他のHTTPヘッダ要素も含めて、4096を超えると壊れてるって >> 感じでしょうか。 >> これって、設定ファイルで設定できたりはしない数字ですよね。 >> >> # まあ、POSTデータを全部urlencodeにする作りもどうなんだとは >> # 思いますが＾＾； >> >> configureオプションでバッファサイズは変えられそうですね。 >> ---- >> Optional Packages: >> --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] >> --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) >> --with-pic try to use only PIC/non-PIC objects [default=use >> both] >> --with-gnu-ld assume the C compiler uses GNU ld [default=no] >> --with-l7vs-moddir=DIR l7vs module is to be installed in DIR. >> default=LIBDIR/l7vs >> --with-l7vsadm-sockdir=DIR l7vsadm sockfile PATH. >> default=/var/run/l7vs >> --with-l7vs-buffer-size=NUM l7vsd using heap buffer size. >> default=4096 >> --with-l7vs-config-dir=DIR l7vs configfile PATH. >> default=/etc/l7vs/l7vs.cf >> ---- >> >> これを変えたら、投入できる行がそれだけ増えそうではあります。 >> >> 根本的には、バッファに入りきらないやつは、分割して格納するとか、 >> なにか別のルーチンに変えるとか(セッションレスやV2ではうまくいくんだし) >> しないとですかね・・・ >> >> (2012/12/07 15:40), 中野　宏朗 wrote: >>> 中野@幕張です。 >>> >>> 障害パターン2だと、Malformedは出てなかった。 >>> となると、Malformedとは別に原因があるかぁ。 >>> >>> urlencodeの長さかな？ >>> >>> (2012/12/07 15:13), 中野　宏朗 wrote: >>>> 中野@幕張です。 >>>> >>>> セッションレスとかの正常編パケットキャプチャみてると、 >>>> Malformedは出て無いね。 >>>> Malformed パケットのHTTPレスポンスが契機なのかな。 >>>> >>>> となると、ヘッダにContent-Lengthが無くて >>>> HTTP chunked responseがある場合、各Data ChunkのChunk sizeを >>>> ちゃんと解釈してHTTPパケット長を計算するルーチンを >>>> handle_realserver_recv()(と、そこから呼ばれるhttp_utilの >>>> 中)に実装してやればこの事象は出ないのかな。 >>>> >>>> Chunk sizeって、テキストに直した数字は16進数なんだな。 >>>> 10進数と思ってそのまんまぶち込むと全然違う結果になるから注意ｗ >>>> >>>> (2012/12/06 20:51), 中野　宏朗 wrote: >>>>> 中野@幕張です。 >>>>> >>>>> 最初に貰ったキャプチャデータみてますが、 >>>>> 最初のMalformedになったレスポンスのHTTPヘッダ内には >>>>> Content-Lengthが無くて、2回目のやつにはContent-Lengthが >>>>> 入っているんだけど、1回目のときは、 >>>>> >>>>> protocol_module_ip.cpp ＠ handle_realserver_recv():L3618 >>>>> >>>>> のところで、NGになってelse文に行っちゃうんじゃね？ >>>>> >>>>> L3677でsession_data_ptr->data_state == UNKNOWN なら、 >>>>> バッファサイズのdata_length をごっそりパケットとして >>>>> 送るから、Malformedになってる気がする。 >>>>> >>>>> Web側capのサイズunlimited版が欲しいな・・・ >>>>> 58番パケットとか、HTTPヘッダの途中でsize limitでぶちきられてる。 >>>>> X-Forwarded-forが入ったヘッダを確認したいのに。 >>>>> Postデータがちゃんと途切れずにWebに届いているか確認したい。 >>>>> >>>>> (2012/12/06 16:51), 中野　宏朗 wrote: >>>>>> 中野@幕張です。 >>>>>> 開発MLもCcに入れてます。 >>>>>> >>>>>> (2012/12/06 13:46), Hibari Michiro wrote: >>>>>>> 太田様 >>>>>>> >>>>>>> 雲雀です。 >>>>>>> 早速の対応ありがとうございます。 >>>>>>> >>>>>>>> 複数パターンで検証いたしました。 >>>>>>>> 結論から申し上げますと、 >>>>>>>> >>>>>>>> 「module = IP -F」の場合のみ、障害が発生いたします。 >>>>>>> 情報ありがとうございます。 >>>>>>> >>>>>>> コードをざっと確認したところ、ipモジュールのXFF付与処理に >>>>>>> 問題がありそうな感じでした。 >>>>>>> ちなみに、sessionlessモジュールにもXFF付与処理が実装されていますが、 >>>>>>> ipモジュールと実装方法が異なるようで、ipモジュールにのみ問題が >>>>>>> 含まれている模様です。 >>>>>>> ＃まだ、ざっくり見ただけなので、確証はありませんが・・・ >>>>>>> ＃頂いた情報をもとに、引き続き調査します。 >>>>>> ipモジュールだけ、モジュール内のクライアントからの受信処理内に >>>>>> HTTPヘッダ解析ルーチンが入っていますね。 >>>>>> その中で、今回のPOSTのクエリストリングを解釈しきれていない >>>>>> ルーチンがあるんだと思います。 >>>>>> # 頑張って見つけます(汗) >>>>>> >>>>>> で、途中でちょん切れたクエリを受け取ったWebアプリが、空の >>>>>> セットを返して真っ白な表になった、という感じかと。 >>>>>> -- 雲雀　路朗 (Michiro Hibari) MAIL: hibari.michiro ＠ lab.ntt.co.jp 所属: NTT OSSセンタ 基盤技術ユニット 高信頼担当 TEL : 03-5860-5135 / FAX: 03-5463-5490 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: test_data.zip 型: application/x-zip-compressed サイズ: 2963 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/ultramonkey-l7-develop/attachments/20121210/5ed8ba0b/attachment.bin From hibari.michiro ＠ lab.ntt.co.jp Mon Dec 10 12:51:03 2012 From: hibari.michiro ＠ lab.ntt.co.jp (Hibari Michiro) Date: Mon, 10 Dec 2012 12:51:03 +0900 Subject: [Ultramonkey-l7-develop 838] [PATCH] proto_mod_ip XFF/SorryURI bugfix(1/1) In-Reply-To: <20121204160206.1E85.E9CC3206@gcc.co.jp> References: <20121204160206.1E85.E9CC3206@gcc.co.jp> Message-ID: <50C55C27.2090702@lab.ntt.co.jp> 雲雀です。 userのML投稿で見つかった、ipモジュールで-Fオプションを 使用した際に、HTTPリクエストが壊れる問題の修正patchです。 コードを解析したところ、本問題はipモジュールでSorryURIオプションを 利用したときにも発生します。 添付のpatchで、-Fオプション利用時とSorryURIオプション利用時、 どちらの場合でも、事象が解消します。 本修正は、v3.1.0に取り込むのが良いと思います。 （修正内容） put_data_into_sendbuffer()関数内で、送信データがsend_bufferを 上回った場合に、残ったデータの開始位置とサイズが更新されていな かった箇所を修正しました。 以上、宜しくお願いいたします。 -------- Original Message -------- Subject: [Ultramonkey-l7-users 524] UltraMonkey-L7 v3系の処理異常事象報告 Date: Tue, 04 Dec 2012 16:23:51 +0900 From: 株式会社ジーシーシー 太田 立志 To: ultramonkey-l7-users ＠ lists.sourceforge.jp 開発者の皆様 太田と申します。 UltraMonkey-L7を大変有意義に使用させていただいております。 この場を借りて感謝の言葉を述べさせていただきます。 さて、 UltraMonkey-L7 v3系において、 ロードバランサー経由のPost処理後のWeb画面が正常に 表示されない事象が発生しましたので、 ご報告いたします。 パケットキャプチャ等取得しましたので、 ご確認いただけますと幸いです。 【事象】 クライアントPCから、 UltraMonkey-l7-3.0.3-1経由でWebシステムのPost処理を 行った際に処理後のWeb画面が正常に表示されない場合がある。 （事象を記したpdfファイルを別途お送りします） 【検証】 ・Webサーバに直接アクセスして処理を行った場合、正常に動作します。 ・UltraMonkey-l7-2.1.3-1であれば問題なく動作します。 ・UltraMonkey-l7-3.0.4-2では同様に処理異常となります。 ・処理異常が発生する前に「Malformed Packet」が発生しております。 【環境】 <ロードバランサー> OS：Cent OS 5.6 32bit Kernel：2.6.18-238.el5 UltraMonkey-l7バージョン：3.0.3-1 振り分け方法：IPモジュール（ module = ip -F -R ） OS：RHEL 5.4 Kernel：2.6.18-164.el5 32bit Apache：2.2.15 【お送りする情報】 ※各種取得情報を竹林様宛に別途送らせていただきます。 ・Ultramonkeyl7-3.0.3.1経由の処理異常画面.pdf ・パケットキャプチャ 　　＜UltraMonkey-l7-3.0.3-1経由＞ 　　１．クライアントPCパケットキャプチャ「PC_dump_UMv3.pcap」 　　２．ロードバランサーパケットキャプチャ「LB_dump_UMv3.pcap」 　　３．WEBサーバーパケットキャプチャ「WEB_dump_UMv3.pcap」 　　＜UltraMonkey-l7-2.1.3-1経由＞ 　　４．クライアントPCパケットキャプチャ 　　　　「PC_dump_UMv2.pcap」 ・l7directord.cf ※その他必要な情報がありましたら、 　お申し付けください。 以上、よろしくお願いいたします。 _______________________________________________ Ultramonkey-l7-users mailing list Ultramonkey-l7-users ＠ lists.sourceforge.jp http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users _______________________________________________ Ultramonkey-l7-users mailing list Ultramonkey-l7-users ＠ lists.sourceforge.jp http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users -------------- next part -------------- --- protocol_module_ip.cpp.org 2012-12-10 11:10:51.240650941 +0900 +++ protocol_module_ip.cpp 2012-12-10 11:14:07.519280924 +0900 @@ -5657,6 +5657,11 @@ bool protocol_module_ip::put_data_into_s buffer_element.first += sendbuffer_rest_size; buffer_element.second -= sendbuffer_rest_size; sendbuffer_rest_size = 0; + + //add remain item + data_ptr->buffer_sequence.push_back(buffer_element); + //delete the item + data_ptr->buffer_sequence.pop_front(); break; } } From nakano.hiroaki ＠ nttcom.co.jp Mon Dec 10 16:25:05 2012 From: nakano.hiroaki ＠ nttcom.co.jp (=?ISO-2022-JP?B?GyRCQ2ZMbiEhOShPLxsoQg==?=) Date: Mon, 10 Dec 2012 16:25:05 +0900 Subject: [Ultramonkey-l7-develop 839] Re: [PATCH] proto_mod_ip XFF/SorryURI bugfix(1/1) In-Reply-To: <50C55C27.2090702@lab.ntt.co.jp> References: <20121204160206.1E85.E9CC3206@gcc.co.jp> <50C55C27.2090702@lab.ntt.co.jp> Message-ID: <50C58E51.5030106@nttcom.co.jp> 中野@幕張です。 このパッチで良さそうですね。 buffer_sequenceがdequeであることを探すのに手間取りました＾＾； # コード書いた人、whileの中のif文だけ見て、「size変えればオッケー！」 # って思っちゃったのかな。その前の代入文とかwhile文条件をすっかり # 忘れてたんだろうなｗ 修正、3.0.4にもバックポートしたいです。 今現在、一般に普及させているのは3.0.4で、既存の安定版を メンテナンスしていくのは、UltraMonkey-L7を多くの人に使って 貰うには大事な活動だと思うので。 V3.1.0への取り込みとともに、3.0.4-3を3.0.4のerrataバージョンとして リリースする方向でパッチコードを適用しようと思います。 # チケットきって、解析結果とパッチ内容を書いてもらって、 # v3.1.0-develとv3.0.4-2のブランチにコミット、その後rpm作成、かな。 こちらで組んだデータ確認用の環境がいまいちなものしか組めていないので、 なるべく早く事象確認用の仮rpmを作って、発見者の太田さんに確認してもらう ようにします。 RHEL5用i386コンパイル環境、どこだろう・・・ # 竹田くぅ〜〜んｗ ## うちでクロスコンパイル環境を作ろうとしてたんだけど、CentOS特化な ## ツールを使おうとして挫折したままだったんだよなぁorz ## 頑張って構築しておくべきだったか。。。 (2012/12/10 12:51), Hibari Michiro wrote: > 雲雀です。 > > userのML投稿で見つかった、ipモジュールで-Fオプションを > 使用した際に、HTTPリクエストが壊れる問題の修正patchです。 > > コードを解析したところ、本問題はipモジュールでSorryURIオプションを > 利用したときにも発生します。 > 添付のpatchで、-Fオプション利用時とSorryURIオプション利用時、 > どちらの場合でも、事象が解消します。 > > 本修正は、v3.1.0に取り込むのが良いと思います。 > > （修正内容） > put_data_into_sendbuffer()関数内で、送信データがsend_bufferを > 上回った場合に、残ったデータの開始位置とサイズが更新されていな > かった箇所を修正しました。 > > 以上、宜しくお願いいたします。 > > -------- Original Message -------- > Subject: [Ultramonkey-l7-users 524] UltraMonkey-L7 v3系の処理異常事象報告 > Date: Tue, 04 Dec 2012 16:23:51 +0900 > From: 株式会社ジーシーシー 太田 立志 > To: ultramonkey-l7-users ＠ lists.sourceforge.jp > > > > 開発者の皆様 > > 太田と申します。 > > UltraMonkey-L7を大変有意義に使用させていただいております。 > この場を借りて感謝の言葉を述べさせていただきます。 > > さて、 > UltraMonkey-L7 v3系において、 > ロードバランサー経由のPost処理後のWeb画面が正常に > 表示されない事象が発生しましたので、 > ご報告いたします。 > > パケットキャプチャ等取得しましたので、 > ご確認いただけますと幸いです。 > > 【事象】 > クライアントPCから、 > UltraMonkey-l7-3.0.3-1経由でWebシステムのPost処理を > 行った際に処理後のWeb画面が正常に表示されない場合がある。 > （事象を記したpdfファイルを別途お送りします） > > 【検証】 > ・Webサーバに直接アクセスして処理を行った場合、正常に動作します。 > ・UltraMonkey-l7-2.1.3-1であれば問題なく動作します。 > ・UltraMonkey-l7-3.0.4-2では同様に処理異常となります。 > ・処理異常が発生する前に「Malformed Packet」が発生しております。 > > 【環境】 > <ロードバランサー> > OS：Cent OS 5.6 32bit > Kernel：2.6.18-238.el5 > UltraMonkey-l7バージョン：3.0.3-1 > 振り分け方法：IPモジュール（ module = ip -F -R ） > > > OS：RHEL 5.4 > Kernel：2.6.18-164.el5 32bit > Apache：2.2.15 > > 【お送りする情報】 > ※各種取得情報を竹林様宛に別途送らせていただきます。 > > ・Ultramonkeyl7-3.0.3.1経由の処理異常画面.pdf > > ・パケットキャプチャ > 　　＜UltraMonkey-l7-3.0.3-1経由＞ > 　　１．クライアントPCパケットキャプチャ「PC_dump_UMv3.pcap」 > 　　２．ロードバランサーパケットキャプチャ「LB_dump_UMv3.pcap」 > 　　３．WEBサーバーパケットキャプチャ「WEB_dump_UMv3.pcap」 > > 　　＜UltraMonkey-l7-2.1.3-1経由＞ > 　　４．クライアントPCパケットキャプチャ > 　　　　「PC_dump_UMv2.pcap」 > > ・l7directord.cf > > ※その他必要な情報がありましたら、 > 　お申し付けください。 > > > 以上、よろしくお願いいたします。 > > _______________________________________________ > Ultramonkey-l7-users mailing list > Ultramonkey-l7-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users > > _______________________________________________ > Ultramonkey-l7-users mailing list > Ultramonkey-l7-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users > > > > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > -- 中野 宏朗 (NAKANO Hiroaki) NTTコムウェア 品質生産性技術本部 技術SE部 基盤ソフトSE・OSS部門 OSS適用推進担当 Tel: 043-211-2452 (Ext: 特番+26-8341), Fax: 043-211-5086 Zip/Address: 261-0023 千葉県千葉市美浜区中瀬1-6 NTT幕張ビル21F-En