Eröffnet am: 2017-09-06 11:48
Letztes Update: 2019-05-08 15:40
| Auswertung: |  doda | Verantwortlicher: | doda |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | Tera Term 4.103 |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | TTSSH | Status: | Offen [Owner assigned] |
| Lösung | Accepted |
SSH接続時に致命的エラーになった後、未接続状態になったVTウィンドウを使って再度SSH接続しようとしても接続出来ない。 何らかの初期化が漏れていると思われる。
[teraterm:1275]
Eröffnet am: 2019-05-02 03:50
Letztes Update: 2019-05-02 03:50
| Auswertung: | (Anonym) | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Support-Anfragen | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term | Status: | Offen |
| Lösung | Keine |
I've been writing a YMODEM file sender for the Arduino, and it's all working, except that when I send a file from my Arduino to TeraTerm using YMODEM, the resulting downloaded file retains all the padding characters in the last block, regardless of whether I use 0x00 or 0x1A (as suggested in the YMODEM documentation from many years ago). If I compare the transmitted file and the received file, they're identical down to the start of the padding in the final packet. I've tried various things, such as sending the first packet with "filename 0x00 filesize 0x20" (again as the protocol seems to show), but I always get that last chunk in the received file. I've duplicated the example 67-byte file shown in the TT YMODEM documentation in terms of block size, separator characters, etc, but no luck. Any suggestions?
Eröffnet am: 2019-05-03 09:14
Letztes Update: 2019-05-03 09:14
| Auswertung: | ckeays | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | (Keine) | Status: | Offen |
| Lösung | Keine |
Hardware flow control in serial port setup does not work. Using CTS and RTS. I have tested this with other terminal programs including Hyperterminal and it is working. Something is wrong with Teraterm.
Eröffnet am: 2018-03-05 21:43
Letztes Update: 2019-05-14 00:39
| Auswertung: | vivek | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term | Status: | Offen |
| Lösung | Keine |
Installed teraTerm 4.97 in Windows7 x64. Opened a Serialport connection with the given baudrate and other settings as prescribed in the board manual. On starting the connection, I see only symbols in the terminal. (Please check the attached screenshot)
Hi vivek,
I am having the same issue. Were you able to resolve this problem?
Eröffnet am: 2018-05-20 23:43
Letztes Update: 2019-05-14 00:42
| Auswertung: | (Anonym) | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 8 | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term | Status: | Offen |
| Lösung | Keine |
If I send data too fast to tera term it some how thinks there is an escape sequence or something and start showing funny ASCII characters, maybe changing mode or something?
If highlight the funny characters and copy into a text editor they are the correct values.
I am not sure what is going on with tera term but would love a fix.
Hi,
I am having the same issue, were you able to resolve?
Eröffnet am: 2018-03-05 21:43
Letztes Update: 2019-05-15 14:49
| Auswertung: | vivek | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term | Status: | Offen |
| Lösung | Keine |
Installed teraTerm 4.97 in Windows7 x64. Opened a Serialport connection with the given baudrate and other settings as prescribed in the board manual. On starting the connection, I see only symbols in the terminal. (Please check the attached screenshot)
In my case the issue got resolved when I used the TTL based rs232-usb converter cable.
Eröffnet am: 2019-05-15 15:42
Letztes Update: 2019-05-15 17:24
| Auswertung: | nakaji42 | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term Macro | Status: | Offen |
| Lösung | Keine |
お世話になります。
ttpmacroを利用してリモート先で処理を行っており、バージョンは4.95を使用しています。
macro中のconnect時の処理は以下のように記述しています。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
; Remote Access Server(SSH Connect)
sh_connect=HOSTNAME
strconcat sh_connect ' /I /V /ssh /2 /nosecuritywarning /auth=password /user='
strconcat sh_connect USERNAME
strconcat sh_connect ' /passwd='
strconcat sh_connect PASSWORD
;; 接続
connect sh_connect
; Connet decision
if result<>2 then
endif
;; 10秒以内にプロンプトが表示されない場合
timeout = 10
wait ':' '%' '$' '#'
if result=0 then
endif
timeout = 0
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ここでユーザID、パスワードを間違えて入力した際、下記のようなttermpro.exeのプロセスが必ず残ってしまう事象があるようで困っております。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Caption=ttermpro.exe
CommandLine=TTERMPRO /D=003A0026 hogehost /I /V /ssh /2 /nosecuritywarning /auth=password /user=test /passwd=test
CreationClassName=Win32_Process
CreationDate=20190515144612.587803+540
CSCreationClassName=Win32_ComputerSystem
CSName=hogehogehost
Description=ttermpro.exe
ExecutablePath=C:\Program Files (x86)\teraterm\TTERMPRO.exe
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
こちらは仕様なのでしょうか？
ログインが正常にでき、処理が終わる場合はプロセスは残りません。
ちなみに、最新のバージョンで行ったところ、ログインが正常にできた場合もプロセスが残ってしまうこととなりまして、現在は4.95に戻しております。
それと、実行はサービスプログラムからSystemアカウントで実行しております。
よろしくお願いします。
end する前に disconnect したらどうでしょうか？
Eröffnet am: 2019-05-15 20:55
Letztes Update: 2019-05-15 20:55
| Auswertung: | chrdou | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 8 | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 8 |
| Komponente: | (Keine) | Status: | Offen |
| Lösung | Keine |
TeraTerm version 4.102 7452
Windows 10 Pro Version 10.0.17763 Build 17763
I am using TeraTerm connected to an embedded device 2 wires Rx/Tx UART through FTDI chip (for RS232 - USB conversion).
When I send string "test" from the embedded UART, it is received and displayed by TeraTerm even is hardware flow control is enabled whereas I would expect no char is received when flow control is enabled.
It is a bug, isn't it ?
Eröffnet am: 2019-05-15 15:42
Letztes Update: 2019-05-16 09:03
| Auswertung: | nakaji42 | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term Macro | Status: | Offen |
| Lösung | Keine |
お世話になります。
ttpmacroを利用してリモート先で処理を行っており、バージョンは4.95を使用しています。
macro中のconnect時の処理は以下のように記述しています。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
; Remote Access Server(SSH Connect)
sh_connect=HOSTNAME
strconcat sh_connect ' /I /V /ssh /2 /nosecuritywarning /auth=password /user='
strconcat sh_connect USERNAME
strconcat sh_connect ' /passwd='
strconcat sh_connect PASSWORD
;; 接続
connect sh_connect
; Connet decision
if result<>2 then
endif
;; 10秒以内にプロンプトが表示されない場合
timeout = 10
wait ':' '%' '$' '#'
if result=0 then
endif
timeout = 0
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ここでユーザID、パスワードを間違えて入力した際、下記のようなttermpro.exeのプロセスが必ず残ってしまう事象があるようで困っております。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Caption=ttermpro.exe
CommandLine=TTERMPRO /D=003A0026 hogehost /I /V /ssh /2 /nosecuritywarning /auth=password /user=test /passwd=test
CreationClassName=Win32_Process
CreationDate=20190515144612.587803+540
CSCreationClassName=Win32_ComputerSystem
CSName=hogehogehost
Description=ttermpro.exe
ExecutablePath=C:\Program Files (x86)\teraterm\TTERMPRO.exe
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
こちらは仕様なのでしょうか？
ログインが正常にでき、処理が終わる場合はプロセスは残りません。
ちなみに、最新のバージョンで行ったところ、ログインが正常にできた場合もプロセスが残ってしまうこととなりまして、現在は4.95に戻しております。
それと、実行はサービスプログラムからSystemアカウントで実行しております。
よろしくお願いします。
返信ありがとうございます。
(匿名)への返信
end する前に disconnect したらどうでしょうか？
さっそくやってみましたが、残念ながら変わりませんでした。 といいますか、試しにteratermを起動しメニュー、コントロールからマクロをクリックし、.ttlファイルを直接指定してフォアグランドで実行したところdisconnectコマンドでMACRO Errorで止まってしまいました。 まだconnect前なのでdisconnectコマンドは無効なのではないでしょうか。
Eröffnet am: 2019-05-17 17:08
Letztes Update: 2019-05-17 17:08
| Auswertung: | (Anonym) | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Funktionsanfragen | Schweregrad: | 5 - Mittel |
| Komponente: | (Keine) | Status: | Offen |
| Lösung | Keine |
Implement dialog windows for selecting files (log, send file) to be scalable. Currently they are fixed in size and cannot be stretched. As a result of this it is difficult to see long file / directory names.
Eröffnet am: 2017-07-21 10:43
Letztes Update: 2019-05-18 18:25
| Auswertung: | yeh_shao | Verantwortlicher: |  yutakapon |
|---|---|---|---|
| Priorität: | 6 | Meilenstein: | Tera Term 4.103 |
| Typ: | Fehler | Schweregrad: | 6 |
| Komponente: | Tera Term Macro | Status: | Offen [Owner assigned] |
| Lösung | Gefixt |
Hi,
Following is the result that windows report when issue happen
Source: Tera Term
Summary: Stopped working
Date: 2017/7/21 上午 09:05
Status: Not reported
Description
Faulting Application Path: C:\Program Files (x86)\teraterm\ttermpro.exe
Problem signature
Problem Event Name: APPCRASH
Application Name: TTERMPRO.exe
Application Version: 4.91.0.0
Application Timestamp: 574d8b72
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 0443df50
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1028 Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Files that help describe the problem
WERInternalMetadata.xml
AppCompat.txt
memory.hdmp
minidump.mdmp
id:zmatsuo commited r7686.
This is current snapshot that includes the fix. Please test this snapshot.
https://osdn.net/downloads/users/24/24104/snapshot-20190518-maya-r7686.zip/
Eröffnet am: 2016-12-14 23:51
Letztes Update: 2019-05-18 18:06
| Auswertung: | yutakapon | Verantwortlicher: | yutakapon |
|---|---|---|---|
| Priorität: | 7 | Meilenstein: | (Keine) |
| Typ: | Funktionsanfragen | Schweregrad: | 7 |
| Komponente: | TTSSH | Status: | Offen [Owner assigned] |
| Lösung | Accepted |
OpenSSL 1.0.2から1.1.0になって、APIのインターフェイスが変更されており、
OpenSSL 1.1.0系をリンクするためには、TTSSHの実装を改修する必要がある。
●●●OpenSSL 1.1.1●●●
https://osdn.net/projects/ttssh2/scm/svn/tree/head/branches/openssl_1_1_1/
(*1) OpenSSL GitHubにも問い合わせ中 https://github.com/openssl/openssl/issues/8948
未
●●●OpenSSL 1.1.0●●●
https://osdn.net/projects/ttssh2/scm/svn/tree/head/branches/openssl_1_1_0/
(*1) dumpbin /dependents コマンドで見ると、 ttxssh.dll が「libcrypto-1_1.dll」に 依存関係を持っているのが原因。当該DLLを格納すれば起動はできた。 r6576で処置済み。
http://ttssh2.osdn.jp/tmp/openssl_api_list/ func_list.txt
https://www.openssl.org/docs/manpages.html
https://www.openssl.org/policies/releasestrat.html
https://www.openssl.org/source/
Eröffnet am: 2019-05-15 15:42
Letztes Update: 2019-05-23 09:16
| Auswertung: | nakaji42 | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term Macro | Status: | Offen |
| Lösung | Keine |
お世話になります。
ttpmacroを利用してリモート先で処理を行っており、バージョンは4.95を使用しています。
macro中のconnect時の処理は以下のように記述しています。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
; Remote Access Server(SSH Connect)
sh_connect=HOSTNAME
strconcat sh_connect ' /I /V /ssh /2 /nosecuritywarning /auth=password /user='
strconcat sh_connect USERNAME
strconcat sh_connect ' /passwd='
strconcat sh_connect PASSWORD
;; 接続
connect sh_connect
; Connet decision
if result<>2 then
endif
;; 10秒以内にプロンプトが表示されない場合
timeout = 10
wait ':' '%' '$' '#'
if result=0 then
endif
timeout = 0
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ここでユーザID、パスワードを間違えて入力した際、下記のようなttermpro.exeのプロセスが必ず残ってしまう事象があるようで困っております。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Caption=ttermpro.exe
CommandLine=TTERMPRO /D=003A0026 hogehost /I /V /ssh /2 /nosecuritywarning /auth=password /user=test /passwd=test
CreationClassName=Win32_Process
CreationDate=20190515144612.587803+540
CSCreationClassName=Win32_ComputerSystem
CSName=hogehogehost
Description=ttermpro.exe
ExecutablePath=C:\Program Files (x86)\teraterm\TTERMPRO.exe
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
こちらは仕様なのでしょうか？
ログインが正常にでき、処理が終わる場合はプロセスは残りません。
ちなみに、最新のバージョンで行ったところ、ログインが正常にできた場合もプロセスが残ってしまうこととなりまして、現在は4.95に戻しております。
それと、実行はサービスプログラムからSystemアカウントで実行しております。
よろしくお願いします。
まだconnect前なのでdisconnectコマンドは無効なのではないでしょうか。
なるほど、closettが正しいかもです。
お返事ありがとうございます。
closettもフォアグランドで実行したところ、同じく「connectを最初にしてください」的なエラーが出てマクロ自体が停止してしまいました。
closettがない状態で実行するとマクロエラーは出ませんが、最後にTTSSHのメッセージボックスで「ユーザ認証が失敗しました」が表示されています。
ひょっとしたらバックグランドで実行した際も「ユーザ認証が失敗しました」で止まっている状態なのかなと思いました。
バックグラウンド時にこの認証エラーで止まるのをスキップするにはどうしたらよいでしょうか？
Eröffnet am: 2019-05-27 09:37
Letztes Update: 2019-05-27 09:37
| Auswertung: | jr4qpv | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Support-Anfragen | Schweregrad: | 5 - Mittel |
| Komponente: | (Keine) | Status: | Offen |
| Lösung | Keine |
Kermitファイル転送で、ファイル属性情報を通知するように KmtFileAttr=on と設定して、ファイル送信時のタイムスタンプを確認すると、Windowsのファイルプロパティーで確認できる「作成日時」が通知されています。できれば「更新日時」を通知して貰いたいです。 どこかで設定変更とか出来たりしますでしょうか？ 現在公開の最新版のバージョンでも確認しましたが、同様でした。
Eröffnet am: 2016-12-14 23:51
Letztes Update: 2019-05-26 16:36
| Auswertung: | yutakapon | Verantwortlicher: | yutakapon |
|---|---|---|---|
| Priorität: | 7 | Meilenstein: | (Keine) |
| Typ: | Funktionsanfragen | Schweregrad: | 7 |
| Komponente: | TTSSH | Status: | Offen [Owner assigned] |
| Lösung | Accepted |
OpenSSL 1.0.2から1.1.0になって、APIのインターフェイスが変更されており、
OpenSSL 1.1.0系をリンクするためには、TTSSHの実装を改修する必要がある。
●●●OpenSSL 1.1.1●●●
https://osdn.net/projects/ttssh2/scm/svn/tree/head/branches/openssl_1_1_1/
(*1) OpenSSL GitHubにも問い合わせ中→クローズ https://github.com/openssl/openssl/issues/8948
未
●●●OpenSSL 1.1.0●●●
https://osdn.net/projects/ttssh2/scm/svn/tree/head/branches/openssl_1_1_0/
(*1) dumpbin /dependents コマンドで見ると、 ttxssh.dll が「libcrypto-1_1.dll」に 依存関係を持っているのが原因。当該DLLを格納すれば起動はできた。 r6576で処置済み。
http://ttssh2.osdn.jp/tmp/openssl_api_list/ func_list.txt
https://www.openssl.org/docs/manpages.html
https://www.openssl.org/policies/releasestrat.html
https://www.openssl.org/source/
Eröffnet am: 2019-05-27 09:37
Letztes Update: 2019-05-27 19:05
| Auswertung: | jr4qpv | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Support-Anfragen | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term | Status: | Offen |
| Lösung | Accepted |
Kermitファイル転送で、ファイル属性情報を通知するように KmtFileAttr=on と設定して、ファイル送信時のタイムスタンプを確認すると、Windowsのファイルプロパティーで確認できる「作成日時」が通知されています。できれば「更新日時」を通知して貰いたいです。 どこかで設定変更とか出来たりしますでしょうか？ 現在公開の最新版のバージョンでも確認しましたが、同様でした。
プロトコルの仕様としては Creation Date となっているのですが、kermit95のソースを眺めた感じだと更新日時の方を使っているようですね。
検討します。
Eröffnet am: 2019-05-27 18:07
Letztes Update: 2019-05-27 18:07
| Auswertung: | doda | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | TTSSH | Status: | Offen |
| Lösung | Keine |
OpenSSH クライアントでは、StrictHostKeyChecking no 設定でホスト鍵がknown_hostsと異なるホストに接続した場合、セキュリティ上の理由から以下の機能が無効化される。
ttsshでの近い動作を行う /nosecuritywarning オプション指定時にホスト鍵が違った場合も同様に機能を無効化すべきではないか。
Eröffnet am: 2019-05-27 09:37
Letztes Update: 2019-06-01 14:53
| Auswertung: | jr4qpv | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Support-Anfragen | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term | Status: | Offen |
| Lösung | Accepted |
Kermitファイル転送で、ファイル属性情報を通知するように KmtFileAttr=on と設定して、ファイル送信時のタイムスタンプを確認すると、Windowsのファイルプロパティーで確認できる「作成日時」が通知されています。できれば「更新日時」を通知して貰いたいです。 どこかで設定変更とか出来たりしますでしょうか？ 現在公開の最新版のバージョンでも確認しましたが、同様でした。
お返事ありがとうございます。 C-Kermitも更新日時のようでした。 よろしくご検討お願いします。
Eröffnet am: 2016-03-04 01:31
Letztes Update: 2019-06-04 02:47
| Auswertung: | (Anonym) | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | (Keine) | Status: | Offen |
| Lösung | Keine |
XON/XOFF limits are currently set to 2048 bytes. This number is too high. The software flow control numbers are set from the ends of the buffer, and most UART buffers are much smaller than 2048. This causes poor performance in software flow control mode because the UART would send XON/XOFF constantly.
https://osdn.jp/projects/ttssh2/scm/svn/blobs/head/trunk/teraterm/teraterm/commlib.c lines 81/82.
Recommend changing XON/XOFF hardcoded limits to 128/128.
Prefer adding user-setting for XON/XOFF limits to configuration window.
Thank you.
https://www.silabs.com/documents/public/data-sheets/cp2102n-datasheet.pdf
4.3.8 Software Handshaking
The CP2102N also supports software handshaking using the XON and XOFF event characters. The characters used for XON/XOFF is set by the host software. If the CP2102N receives an XOFF request, it will stop transmission, even if the CP2102N receiver needs to transmit an XOFF over UART. This can potentially allow an overflow to occur or a deadlock condition if both the CP2102N and the connected UART device transmit XOFF at the same time. The XOFF_CONTINUE setting allows the CP2102N transmitter to send XOFF/XON requests even if it has received an XOFF request from the connected UART device. Once the connected UART device transmits XON, normal transmission from the CP2102N resumes. Software handshaking uses the same watermark levels as hardware handshaking and can be configured dynamically by host software. Watermark levels greater than 512 are converted to an XON limit of 192 bytes and an XOFF limit of 64 bytes. If the XON limit crosses over the XOFF limit, the XON limit will automatically be modified to not cross over the XOFF limit. An XOFF limit of 0 is converted to 64 to guarantee buffer space is available until the UART end device stops transmission. When setting the XON and XOFF limits, it's recommended to use values where the XON limit added to the XOFF limit is less than 512 bytes, like 192/192 or 128/128. CP2102N testing shows that the XON limit set to 192 and XOFF limit set to 192 provides optimal software flow control behavior.
Eröffnet am: 2019-06-04 19:45
Letztes Update: 2019-06-04 20:14
| Auswertung: | andesm | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | (Keine) | Status: | Offen |
| Lösung | Keine |
インターネットに出られないサーバ(以下、対象サーバ)に対して、TeraTermの SSHリモートポートフォワードを使って社内LANのProxyサーバと接続し、対象 サーバ上でISOファイル等の大きなファイルをインターネットからwgetすると、 TeraTermが異常終了する(「TeraTermは動作を停止しました」のダイアログが 出る)。
この時、wget開始から異常終了直前までメモリが増え続けているように見える。 上記ダイアログのボタンからTeraTermプログラムを終了させるとメモリが減る (wget開始前の容量に戻る)。
添付画像参照。
Tera Term v4.102（19/02/28）
社内LAN Proxy server(proxy.xx.jp:8080)
↑
クライアントWindows PC(TeraTermマクロ実行)
↓ ↑
踏み台1 Linux(11.11.11.11)
↓ ↑
踏み台2 Linux(22.22.22.22)
↓ ↑
踏み台3 Linux(33.33.33.33)
↓ ↑
対象サーバ Linux(44.44.44.44)
↓ : SSH接続
↑ : SSHリモートポートフォワード接続
connect '11.11.11.11:22 /ssh /2 /auth=password /user=xxxxx /passwd=xxxxx /ssh-R8888:proxy.xx.jp:8080' wait '$' sendln 'ssh -o stricthostkeychecking=no -o userknownhostsfile=/dev/null xxxx@22.22.22.22 -p xxxxx -g -R 8888:localhost:8888 wait 'password:' sendln 'xxxxx' wait '$' sendln 'ssh -o stricthostkeychecking=no -o userknownhostsfile=/dev/null root@33.33.33.33 -R *:8888:localhost:8888 wait 'password:' sendln 'root123' wait '#' sendln 'ssh -o stricthostkeychecking=no -o userknownhostsfile=/dev/null root@44.44.44.44 -R *:8888:localhost:8888 wait 'password:' sendln 'root123' wait '#'
# env | grep http http_proxy=http://localhost:8888 HTTPS_PROXY=http://localhost:8888 https_proxy=http://localhost:8888 HTTP_PROXY=http://localhost:8888
対象サーバでwgetすると100%問題発生する。但し、何回かに一度はダイアログ が出ずに突然落ちる時がある。また、踏み台2、踏み台3までのログインで止めて wgetしても100%問題発生する。
踏み台1までのログイン止めてwgetでは問題発生しない(メモリ増加も見られない。 つまり多段にssh接続すると問題発生？)
なお、同様の接続の仕方でRLoginではいずれのケースでも問題発生しない。
Kommentar
別の再現する手順…Fatal Error と同じ？
ここから