Tera Term (I am running version 4.91) has a severe bug in Xmodem send when using a TCP/IP connection. It seems that every carriage return character (0x0d) is followed by a null character (0x00) on a TCP/IP connection. When simply conversing with a remote system at a command prompt, this has no effect whatsoever. However, it is devastating when attempting to use the Xmodem protocol. Xmodem is a binary protocol, and must be able to send and receive all characters 0x00 through 0xff. But Tera Term goes and sticks a 0x00 character after every 0x0d character. Needless to say this destroys the integrity of the Xmodem packet. Even if the data being sent does not contain any 0x0d characters, the Xmodem packet itself contains a binary block number, and Xmodem send is guaranteed to fail on block number 13 (binary 0x0d). The packet will be the wrong length, and the CRC or checksum will not validate.
I have observed this on both Telnet connections and on raw TCP/IP connections. I have tried with and without the Xmodem binary option (i.e. XmodemBin=on and XmodemBin=off in my INI file). Xmodem send always fails on block number 13, or on the first block that contains a 0x0d character in the data.
Oddly, this does not seem to affect Xmodem over serial port connections. Serial port connections work fine. But Xmodem over TCP/IP connections always fails.
I have verified the failure mode via Wireshark captures. I hope the developers can fix this bug.