The z modem file receiving seems broken with 5.6..1 release

Start a file transmission with "sz file_name" in the terminal, then goes to file -transfer- Z modem- receive. The file transfer starts but it stuck in the middle of transmission.
I revert back to release 5.5.0. It works well. Not sure since which release this occurs?

Thanks for reporting.

I could not be reproduced.
I sent a file using sz on a host connected via SSH.

$ sz --help | grep version
sz version 0.12.21rc
$ dd if=/dev/urandom of=20MB.bin bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB, 20 MiB) copied, 0.562414 s, 37.3 MB/s
$ sha256sum 20MB.bin
1267da88c716c30d19e2d334c6de5e0044584b187cfbebb62a887fe7ef4c7ff5  20MB.bin
$ sz 20MB.bin

SHA256 value of the file received by Tera Term matched.

Thank you for replying. I was using a USB cable connected to a microcontroller, and the USB was working in USB CBC, virtual com port mode.

The following fix may be related.

@zmatsuo

@zmatsuo
「5.6.1 ではだめで、5.5.0 では正常（間のいつからだめになったかは知らない）」、つまり5.5.1 の修正が含まれている 5.6.1 で問題が起きていると言っているように見えます。

Could you please confirm the following points:

Does the transfer always stop at the same position, or is it random?
Please let us know the number of bytes received when the transfer stops.
You mentioned that the file reception stops -- does file transmission work without any issues?
Which options are you using with the sz command? (e.g., sz -b file_name)

For further investigation, could you obtain a debug log?
The procedure for enabling the debug log is as follows:

Enable ZmodemLog=on in the INI file (default is off).
INI file location for the installer version: %APPDATA%\teraterm5\TERATERM.INI
Setting: ZmodemLog=on
Receive a file using ZMODEM.
Please send us the ZMODEM.LOG if its contents are safe to share.
If the log is large, you may omit parts of the byte sequences as needed.
(If providing the log is difficult, please let us know.)
Location of the debug log for the installer version: %LOCALAPPDATA%\teraterm5\ZMODEM.LOG

Reference:
A normal transfer would produce a log similar to the example below.

2A 2A 18 42 30 31 30 30 30 30 30 30 30 33 39 61     **.B01000000039a
33 32 0D 8A 11                                      32...
ZShHdr: ZRINIT

<<< Received
2A 18 41 04 00 00 00 00 89 06 7A 69 70 00 32 31     *.A.......zip.21
34 35 30 34 20 31 35 30 33 30 36 32 32 34 30 30     4504 15030622400
20 31 30 30 37 35 35 20 30 20 31 20 32 31 34 35      100755 0 1 2145
30 34 00 18 6B 66 98 11                             04..kf..
ZParseHdr: RxType ZFILE 

Sending >>>
2A 2A 18 42 30 39 30 30 30 30 30 30 30 30 61 38     **.B0900000000a8
37 63 0D 8A 11                                      7c...
ZShHdr: ZRPOS

<<< Received
2A 18 41 0A 00 00 00 00 46 AE 7F 45 4C 46 02 01     *.A.....F..ELF..
(--Omitted--)
00 00 00 00 00 00 00 00 00 00 18 68 20 64 2A 18     ...........h d*.
41 0B E8 45 03 00 4E D8                             A..E..N.
ZParseHdr: RxType ZDATA ZParseHdr: RxType ZEOF 

Sending >>>
2A 2A 18 42 30 31 30 30 30 30 30 30 30 33 39 61     **.B01000000039a
33 32 0D 8A 11                                      32...
ZShHdr: ZRINIT

<<< Received
0D 2A 2A 18 42 30 38 30 30 30 30 30 30 30 30 30     .**.B08000000000
32 32 64 0D 8A                                      22d..
ZParseHdr: RxType ZFIN 

Sending >>>
2A 2A 18 42 30 38 30 30 30 30 30 30 30 30 30 32     **.B080000000002
32 64 0D 8A                                         2d..
ZShHdr: ZFIN

<<< Received
4F 4F                                               OO

It stuck randomly. Most of the time, it gets stuck in the beginning and sometimes, around 20% in progress. I attached two videos which show the Z modem transmission in two different versions. Hopefully, this can clarify the issues. thanks.
https://youtu.be/5ylJGXANZAo
https://youtu.be/yxCFPgZcW4o

同じ認識で、5.5.1で直した修正が関係する? というつもりでした。

シリアルで接続するlinuxは手もとになくて試すことができないです。
再現できないか調べてみます。

Thank you for the information.

It appears that this issue occurs when using a USB CDC-ACM connection.
In the case of UART, the device-specific driver handles the data, but for USB CDC-ACM, the Windows built-in CDC driver (usbser.sys) is used instead.
usbser.sys has a large internal receive buffer and tends to deliver a large amount of data to Tera Term at once (i.e., burst/aggregated delivery).
On the other hand, Tera Term changed its internal behavior in #894 by increasing the receive buffer size and separating the receive and transmit threads.

The current ZMODEM receive implementation appears to assume that incoming data is smaller than or equal to one frame. Due to the larger buffer introduced in #894 and the burst delivery behavior of USB CDC-ACM, it is possible that ZMODEM is failing to correctly handle frame boundaries.

I will check whether ttpfile/zmodem.c can properly handle multiple consecutive frames in a single read.
(It is likely that this behavior is specific to USB CDC-ACM, so reproducing the issue with UART or com0com may be difficult.)

@mata7648

@mata7648
We have two requests:

As mentioned above, please provide the ZMODEM debug log so we can check the communication status.
Please provide a screenshot of the screen shown when COM12 is selected in “Setup > Serial Port” so we can check the COM port information.

Thanks,

To support USB CDC-ACM, I have reviewed and optimized Tera Term’s data receiving process and COM port transmission process, making them more lightweight. (PR #1345)
Could you try the binary available at the following URL?
https://github.com/TeraTermProject/teraterm/actions/runs/27352877625

For reference, the zmodem transfer speeds over a TCP (SSH) connection in my environment are as follows:

TCP (SSH)	5.5.0 (x64)	5.6.1 (x64)	5.7.0dev (x64)
zmodem receive	2.26 MB/s	2.50 MB/s	23.57 MB/s
zmodem send	274.27 KB/s	333.84 KB/s	398.43 KB/s

Hi, I have downloaded and tried the version and z modem transmisson works fine. The speed is about 7Mb/s. Great job! Thanks

Hi, thank you for checking the operation.
I’m glad to hear it’s faster than before.

EV_ERR時の処理を追加、CloseHandle()の前にSetupComm()を呼ぶよう修正 #1299

変更履歴を修正 #1299

TeraTermProject#894 bd1b0c0 シリアルポートの受信処理を別スレッドにする処理を元に戻した TeraTermPro…

USB CDC-ACM のバースト送信向けに受信バッファ(InBuffSize, CommInQueSize)のサイズを64KBに変更した T…

InBuffのmemmoveが減るよう修正した(スライディング化)、受信イベントでEV_ERRを拾うよう修正した TeraTermProj…

COMポートへの送信処理で必要な場合のみ ClearCommError() を呼ぶよう修正した、ResetEvent()を呼ぶようにした T…

負荷を下げるため、zmodemの進捗ダイアログの更新間隔を10回/秒に変更した TeraTermProject#1299

xmodemの進捗ダイアログの転送時間を、転送開始時刻からの経過時間が表示されるよう修正した TeraTermProject#1299

下記の不具合修正 (PR #1375)のため、再オープンします。
・zmodemによる転送が0.1秒未満で終わった場合に、進捗ダイアログが更新されない
・zmodemによる転送中にキャンセルボタンを押した際、転送中のデータが画面に表示される

Merge pull request #1375 from TeraTermProject/fix/#1299-zmodem_USB_CD…

Merge pull request #1376 from TeraTermProject/mfc/#1274_2

下記の不具合修正 (PR #1375)のため、再オープンします。
・zmodemによる転送が0.1秒未満で終わった場合に、進捗ダイアログが更新されない
・zmodemによる転送中にキャンセルボタンを押した際、転送中のデータが画面に表示される

main と stable_5_6 にマージさせて頂きました。

zmodemによる転送が0.1秒未満で終わった場合に、進捗ダイアログが更新されない不具合を修正した TeraTermProject#1299

zmodemによる転送中にキャンセルボタンを押した際に転送中のデータが画面に表示されないよう、キャンセルボタン押下から0.5秒経過後にzm…

Navigation Menu

Repository navigation

The z modem file receiving seems broken with 5.6..1 release #1299

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The z modem file receiving seems broken with 5.6..1 release #1299

Description

Activity

zmatsuo commented on May 9, 2026

mata7648 commented on May 9, 2026

zmatsuo commented on May 10, 2026

nmaya commented on May 13, 2026

hkanou commented on May 13, 2026

mata7648 commented on May 13, 2026

zmatsuo commented on May 14, 2026

hkanou commented on May 14, 2026

nmaya commented on May 16, 2026

hkanou commented on Jun 11, 2026

mata7648 commented on Jun 12, 2026

hkanou commented on Jun 13, 2026

12 remaining items

hkanou commented on Jun 23, 2026

hkanou commented on Jun 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions