#90 CRC error with XModem download on Windows

[Anonymous]

On Windows I am seeing SyncTerm return a CRC error when attempting to download a text file.
This was documented here, as I thought it was due to the XModem sender originally:
https://github.com/exsilium/xmodem.js/issues/6

However, I have independently confirmed the bytes that SyncTerm is complaining about have the correct CRC. I am attaching the file that I am getting this error with. It is complaining about block 51.

Block 51's Hex dump looks like this:
6c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f75210d0a49206c6f766520796f752149206c6f766520

and should result in: 0xFFCB

Here is the error dump from SyncTerm.
I would highly recommend logging the CRC as I set the verbosity to DEBUG mode.

Xfer Debug: Requesting data block 51
Xfer Warning: Block 51: CRC ERROR
Xfer Error: Too many errors (10)
Xfer Debug: file_bytes=2147483647
Xfer Debug: file_bytes_left=2147477247
Xfer Debug: filelength=6400
Xfer Error: File Transfer Cancelled

Note: When working with someone from the xmodem sender project, this file sent correctly for them using SyncTerm 1.1 on MacOS. He did notice that the EOF character was changed. This last comment does not appear to be related, but something to look into.

Thank you!

[Stephen James Hurd]

I would need to understand a lot more information about what is going on in the connection, what server is being used, etc. A wireshark capture would likely be useful as well.

[Anonymous]

The server is custom, one that I wrote in NodeJS using an XModem library called XModem-JS.
I provide a very simple code snippet in this report that represents all it takes to spin up a service and send a file when you connect: https://github.com/exsilium/xmodem.js/issues/6

Just npm install xmodem.js, then run that small xmodem sender demo with the attached file. When you connect with SyncTerm, just setup an X download and it will start sending.

As a feature, logging the failed CRC when in DEBUG mode might be really useful. I will look into the wireshark capture.

[Stephen James Hurd]

Running with the current git build of SyncTERM, I don't see the CRC error, but I'm running using FreeBSD. It may be worth checking to ensure the file is being read in binary mode since the file uses \r\n line endings which can get mangled on Windows.

[Anonymous]

Thank you Stephen. A few things of note. I ran this by someone running SyncTerm on MacOS and they also got it working. I think this is an issue with the Windows build. I checked the server snippet and I am using fs.readFileSync without any options which should read the file as binary straight into a Buffer. Lastly, I ran wire shark. Here is the Hex Stream of the failed call:

18000000600b6b180099068000000000000000000000000000000001000000000000000000000000000000011f90ce2e6cd29519785d9820501820f7179900000133cc6c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f752149206c6f766520796f75210d0a49206c6f766520796f752149206c6f766520ffcb

I was able to confirm that the \r\n were correctly encoded and that we are sending the correct CRC: FFCB. There appears to be some issue with the Windows build of SyncTerm that is not correctly handling certain characters when it tries to build its CRC. When I removed the \r\n from the text file it did send correctly. But since it appears like I am sending the payload correctly with the correct CRC, it looks like the issue may be with the SyncTerm parsing those characters. I am using build 1.1, but tried the latest 1.2b build as well on Windows with no luck.

[Stephen James Hurd]

Binary mode is selected by passing options to the open() function, not to the read... if you could attach the complete pcap for the session, it would be much more helpful than a hex stream.

That said, the fact that the error occurs in a packet containing 0xFF implicates telnet mode.

[Anonymous]

Thank you. I have attached the full pcap file obtained using the node src linked above.
As a note, I also tried to issue: IAC WILL TRANSMIT-BINARY
That did not have an effect.

[Stephen James Hurd]

Ok, yeah, this looks like SyncTERM is configured for telnet, not raw... if that's the case, any 0xFF byte needs to be escaped, and sent as two bytes (ie: 0xFF,0xFF). You can see that in frames 212 and 213, when parsed as telnet, the checksum (0xFF,0xCB) is parsed as telnet option 203 instead of as data.

If SyncTERM is not configured for telnet mode, something weird is enabling it, since there's the DO/WILL exchange at the start (frames 4 and 6).

[Anonymous]

Thank you, Stephen. For whatever reason I had assumed that when an xmodem transmission was initiated, the client would know it was being sent file data and would not try to interpret any part of that file payload as a command. Is there any way to tell SynchTerm to switch to RAW just for the transmission, and then back to TELNET once the file transmission is over? I assume the answer is no... I am just worried about the extra overhead of searching each Buffer for 0xFF and then, if found, rebuilding it with escape characters. It just seems like a lot when the client should already be aware of what is happening. I totally get it if that is part of the spec and everyone is having to do this. Thank you again. - Brandon

[Stephen James Hurd]

Unfortunately no, 0xFF is the telnet "Interpret as Command" byte, and is the only reserved byte... so the mode wouldn't have a way to end without it being treated special.

Usually you would use a separate telnet server that takes care of this for you, it's only when you're handling the socket yourself that you need to implement the telnet protocol... but everyone who directly uses a telnet socket has to do this.