SecureCRT v6.5.1 ZModem does not seem to support segmented streaming

[sami]

Hello,

I am using your trial version of SecureCRT v6.5.1, I need it to be able to transfer files to devices using ZModem only.
The devices are able to receive up to 2KB at a time.

This means that at file transfer initialization the devices specify within the ZRINIT frame the buffer length (i.e. segments of 2x1024 bytes) it can handle at a time and the sender should wait for ZACK before sending the next segment.

ZModem implementation in SecureCRT seems to overlook this field in the ZRINIT and send large segments.

Can you please tell me how I can configure it to work according to requirements?

BTW, I was able to use other software that do handle this correctly, however I liked how easy and stable SecureCRT with SSH is and would like for our customers to use tools with such ease.

Thanks,
Sami Salloum

[rtb]

Hi Sami,

After some research, the Zmodem implementation in SecureCRT does not currently support segmented streaming. I have created a feature request in our SecureCRT development database to add this ability. Should a future release of SecureCRT have this capability, we will post to this forum thread.

If you would like to be notified directly, please complete and submit the form at the following location:

Submit Feature Request

In the meantime, you may be able to work around the limitation in SecureCRT by using an option that forces 1024 byte frames when using Zmodem. You will not be able to use the entire capacity of the buffer on the device, but you should be able to use half of it.

It is necessary to enable the following line in the session's .ini file:

D:"Force 1024 for ZModem"=00000000

Changing the line to end in "1" will enable the option.

To edit a session's .ini file:

1. Close all instances of SecureCRT before making changes to .ini configuration files. If changes are made to a .ini configuration file while SecureCRT is running, the changes made via your editor may be "undone" when SecureCRT closes (and saves it's current configuration -- which doesn't have your manual changes).
   
2. Edit the session's .ini file (located in the Sessions subfolder of SecureCRT's configuration folder location indicated by the "Configuration folder" field in the 'General' category of the Global Options dialog. Add/modify lines as instructed.
   
3. Save the session's .ini file and start SecureCRT.

Note: If you have a /f in the target of the shortcut used to launch SecureCRT, then the path to the Config folder will be different than the path in step 2 above.

Does this option allow you to use Zmodem in SecureCRT to transfer files to the devices successfully?

[sami]

Hi Todd,

First, thanks a lot for your super fast reply.

Unfortunately this didn't do the trick, Although I have managed to transfer files under 2KB, but anything above fails and same behaviour even if I don't update the session's ini.

Any other suggestions?

Many thanks,
Sami

[rtb]

Hi Sami,

I am glad we could at least respond quickly.

If forcing SecureCRT to use 1024 bytes did not resolve the issue, then I can only suggest that you wait to see if we post to this thread indicating that a new version of SecureCRT supports segmented streaming. I cannot guarantee that this feature will be implemented, but we will post here if it is. You can also submit the form I mentioned in my previous post to have us notify you directly if this feature is ever implemented. Thanks for evaluating SecureCRT.

[sami]

Hi Todd,

After further checks, it seems that the CANOVIO bit in the ZRINIT header is ignored and automatically assumed to be 1.

Can you please check this?

Thanks,
Sami

[rtb]

Hi Sami,

Thanks for your inquiry.

I am researching whether this is something that we currently support, or if I would need to make a feature request for you. I will post what I find about the CANOVIO bit as soon as I have some additional information.

[sami]

Hello again,

I would like to tell you what I'm actually trying to do, perhaps this way you might think of a different approach or suggest a possible solution with the current SecureCRT version.

I am using a SSH2 client with ZModem file transfer support to send a file to a device that has very little RAM, and cannot perform overlapped IO, meaning that it can receive a certain amount of buffer (2K) and has to write it immediately before another chunk is received.

In order to do that, the sender must be able to wait for an ACK before sending any more data.

Now by your suggestion to set D:"Force 1024 for ZModem"=00000001 should solve one part of the problem which is each packet is larger than 1K.

The second part of the problem is that full streaming allows to send many 1K sub-packets without waiting for the receiver to respond.

If there is a way to force SecureCRT to use ZCRCW sub-packets (which require the sender to wait for an ACK) instead of sending ZCRCG or ZCRCQ, I believe it should solve the problem.

I am convinced that ZCRCW sub-packets is implemented in SecureCRT, because ZModem sends such a packet immediately after a ZFILE header always.

The question remains, is there a way to tell SecureCRT to use ZCRCW all the time (which is very OK by the protocol definition) ?

If not, do you have any other suggestions? Any help is highly appreciated!

Thanks in advance,
Sami

[sami]

Also would like to ask, if there is a way to disable the sender's timeout (while waiting for ACK from the receiver - when an ACK is expected) or lengthen the timeout?

Thanks,
Sami

[rtb]

Hi Sami,

We are continuing our research into what it is you are attempting to accomplish. Is the Zmodem implementation on the device a custom coded program?

Can you tell me what type of device you are using and who makes it?

[sami]

Hi Todd,

It’s a custom made porting of the ZModem protocol to an ATMEL ARM based microcontroller (device PN: AT91SAM9XE512 that has a total of 32KB RAM, a part of which is used for the application itself).

The files we are passing to it are ~300KB and the microcontroller application writes the received data to an ASIC a few kilobytes at a time as it receives them.

Now this data is passed to the microcontroller using RS232 at 9600bps baud.

I don't know how much this helps you, but again, if there were a way to force ZCRCW frames to be used all the time during a file transfer, this would definitely bring us to a solution or very close to one.

Thanks,
Sami

[rtb]

Hi Sami,

Thanks for the additional information. I will post to this thread as soon as I have an update regarding this issue.

[rtb]

Hi All,

Just wanted to update this. SecureCRT currently doesn't honor the CANOVIO capability flag when sending files. As posted earlier, we will notify via this thread if this capability is added to a future SecureCRT Zmodem implementation.

If you would like to be notified directly, please complete and submit the form at the following location:

Submit Feature Request