Ticket #39614

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

Open Date: 2019-09-27 13:33 Last Update: 2019-10-03 09:32

Reporter:
Owner:
Type:
Status:
Open [Owner assigned]
Component:
MileStone:
Priority:
7
Severity:
7
Resolution:
Fixed
File:
3
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

Details

バージョン

  • 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回エラーが発生しました。

Ticket History (3/11 Histories)

2019-09-27 13:33 Updated by: shiro2019
  • New Ticket "SSHポートフォワーディング時にHTTPによる画像ダウンロードが正常に実行できないことがある" created
2019-09-27 13:43 Updated by: shiro2019
Comment

検証用コード

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 Updated by: shiro2019
Comment

対処

原因は推測ですが、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 Updated by: doda
  • Resolution Update from None to Accepted
  • Milestone Update from (None) to Tera Term 4.105
Comment

現象確認しました。

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

2019-09-30 09:23 Updated by: shiro2019
Comment

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

承知しました。

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

2019-10-02 18:14 Updated by: doda
  • Owner Update from (None) to doda
  • Resolution Update from Accepted to Fixed
Comment

r8239 で修正。

2019-10-02 18:21 Updated by: doda
Comment

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

2019-10-03 09:32 Updated by: None
Comment

Reply To doda

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

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

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

Attachment File List

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login