チケット #39614

SSHポートフォワーディング時にHTTPによる画像ダウンロードが正常に実行できないことがある

登録: 2019-09-27 13:33 最終更新: 2019-12-09 10:09

報告者:
担当者:
チケットの種類:
状況:
完了
コンポーネント:
マイルストーン:
優先度:
7
重要度:
7
解決法:
修正済み
ファイル:
3
投票
点数: 0
No votes
0.0% (0/0)
0.0% (0/0)

詳細

バージョン

  • Teraterm version: 4.104(SVN# 8043)
  • OS: Windows 10

環境

本現象を再現させた環境は、Web Server(Ubuntu)、踏み台Server(FreeBSD)、SSH実行マシン(Windows10)、Client(Ubuntu)の4台構成です。

ClientからWeb Serverに対してHTTP/1.1のPOSTでリクエストを送信し、Web ServerからHTTP/1.1のTransfer-Encoding: chunkedで画像データをレスポンスとして受信する際に、全てのデータを受信する前にSSH実行マシン上のClient側のSocketが、shutdownされてしまい、エラーとなる場合があります。

具体的には、Clientからは2つのHTTPのリクエストを同時に送信します。1つ目のリクエストはSSH実行マシン上のポート8080、2つ目はポート8900に送信します。

SSH実行マシンでは事前に踏み台ServerにTeratermでログインし、以下のようなポートフォワーディングの設定を行います。

  • 0.0.0.0:8080:<Web ServerのIPアドレス>:8000
  • 0.0.0.0:8900:<Web ServerのIPアドレス>:8000

Web Serverでは、ポート8000で画像データをHTTP/1.1のTransfer-Encoding: chunkedで返すプロセスを起動させています。

この状態で、Clientから2つのリクエストを送信すると、以下のようなエラーダイアログが表示されます。

 Communications error writing forwarded local 8900.
 The forwarding connection could not be established (code 10058).
 The forwarded connection will be closed.

踏み台ServerのOSはFreeBSDですが、Ubuntuにしても発生することがあります(発生頻度はFreeBSDの方が高いです)。

確認した時点では、50回実行した場合に15回エラーが発生しました。

チケットの履歴 (14 件中 3 件表示)

2019-09-27 13:33 更新者: shiro2019
  • 新しいチケット "SSHポートフォワーディング時にHTTPによる画像ダウンロードが正常に実行できないことがある" が作成されました
2019-09-27 13:43 更新者: shiro2019
コメント

検証用コード

Web ServerとClientの検証用のコードを添付します。(test_sources.zip)

Web ServerはPython 3で動作します。

事前に10MByteほどのjpgファイルを、pyserver配下にtarget.jpgとして配置してください。

pyserver配下に移動し、./pyserver.pyでポート8000をlistenするHTTPのサーバが起動します。

ClientはNode.jsで動作します。以下を参考にNode.jsをインストールしました。

https://qiita.com/seibe/items/36cef7df85fe2cefa3ea

また、依存パッケージのaxiosは以下を参考にインストールしました。

https://qiita.com/ksh-fthr/items/2daaaf3a15c4c11956e9

client配下に移動し、node ./getFiles.jsで起動します。起動するとgetFiles.jsの5行目のIPアドレスに対してHTTPリクエストを送信しますので、環境に合わせて、Teratermを起動しSSHポートフォワーディングを設定するマシンのIPアドレスに変更してください。

2019-09-27 13:49 更新者: shiro2019
コメント

対処

原因は推測ですが、SSH2_MSG_CHANNEL_EOFを受信した際、即座にlocalのsocketに対して、shutdown(channel->local_socket, 1)しており、その後対象のsocketに対して、write_local_connection_bufferを行っているため、本現象が発生しているものと考えています。

何故、SSH2_MSG_CHANNEL_EOFが来た後に、データをwriteしているのかまでは追っていませんが、バッファリングされているデータが処理されていないではないかと推測しています。

そのため、FWD_channel_input_eof()内ではshutdownせずに、SSH2_MSG_CHANNEL_CLOSEを処理する、handle_SSH2_channel_close()で、対象のsocketをshutdownするように変更しました。変更内容は添付したファイル(FWD_shutdown_channel.diff)のとおりです。

この変更を加え、ttxssh.dllをビルドし、再度確認を行ったところ、本現象は発生しませんでした。

2019-09-27 18:02 更新者: doda
  • 解決法なし から 受領 に更新されました
  • マイルストーン(未割り当て) から Tera Term 4.105 (完了済み) に更新されました
コメント

現象確認しました。

頂いた修正だとポートフォワーディングの接続が正しく切断されなくなるので、別の方法を取る事になると思います。

2019-09-30 09:23 更新者: shiro2019
コメント

ご確認ありがとうございます。

承知しました。

ご対応よろしくお願いします。

2019-10-02 18:14 更新者: doda
  • 解決法受領 から 修正済み に更新されました
  • 担当者(未割り当て) から doda に更新されました
コメント

r8239 で修正。

2019-10-02 18:21 更新者: doda
コメント

snapshot-r8239-20191002-doda-ticket39614.zip を試してもらえますか?

2019-10-03 09:32 更新者: None
コメント

Reply To doda

snapshot-r8239-20191002-doda-ticket39614.zip を試してもらえますか?

試したところ、本現象は再現しませんでした。

ご対応ありがとうございます。

2019-12-08 09:01 更新者: None
2019-12-09 09:49 更新者: doda
  • 状況オープン から 完了 に更新されました
2019-12-09 10:09 更新者: doda
コメント

Tera Term 4.105 で修正済み。

添付ファイルリスト

編集

ログインしていません。ログインしていない状態では、コメントに記載者の記録が残りません。 » ログインする