Celestial Software

I'm trying to transfer files between my Win98 machine and my Unix account (FreeBSD 4.5) using your ZTERM function and the lsz/lrz package (variants of sz/rz) on the remote host.

I can download files to my computer just fine. I type lsz filename.ext on the FreeBSD machine and up pops the transfer dialog (BTW, the progress bar needs to be fixed a little I think).

Uploading is a problem. If I initiate from the remote site (with lrz), it says 'lrz waiting to receive', the ZModem Send box opens, and an 'Open' window pops up, and I can select the file I want to upload. I click on Open, and the ZModem send progress bar zips across the screen to the end, clears, and restarts, and hangs at:

Packets Received: 7 Sent: 77
Errors: 2
Bytes Transferred: 1024
Status: Sending File Data

It hangs for a few seconds, then goes away, but lrz is still waiting for data. I can't interrupt it, and if I just close the connection and reopen, AbsoluteTelnet tries to continue sending data, which is now being plugged into the command line (bad), so I have to kill the window.

Any suggestions? I've tried X/Y/Zterm all with no success (lrz is supposedly compatible with them all).

Thanks,

- Vanhoose

Vanhoose,

The problems you describe are known issues in version 1.80 and below. They stem from improper output flow control in the SSH protocol, which has now been fixed in the 1.81 release (which just came out today, BTW.) You can get it here:

download here

Okay, it looks like I'm still having a problem, but at least AbsoluteTelnet is trapping the error. Now when I run lrz and select the file (in this case, as a test, Absolute.exe the installer), I get so far as:

Packets received: 3 Sent: 65
Errors: 0
Bytes Transferred: 29,696
Status: Sending File Data

when I get an error box pop up:

send failed
Winsock error: Action Would Block

Any suggestions? Some of the Winsock pages I've looked at say it's a temporary resource allocation problem (e.g., http://www.sockets.com/err_lst1.htm#WSAEWOULDBLOCK).

I can tell you that the remote site has security turned way up, and I have a firewall on my end through which AbsoluteTelnet has been the only ssh client capable of penetrating successfully. Thanks for any help you can give.

Just a few questions.....

1. Are you using SSH1 or SSH2???

2. Are you using dialup or high speed access?

SSH2 over a full T1.

- Van

I'll have to research this a bit more. While I do that, can you try the same thing with the SSH1 module?

thanks!!!

Unfortunately, the server only supports ssh2. I could ask the admin to enable ssh1, but he might not go for it...

- Van

Can you tell me which firewall you are using?? What problems have you had with other SSH clients?

I can't tell you right now what the firewall is. I don't have a clue, and neither do my IT guys--apparently the firewall is administered out of Minneapolis--we're in Boston. They're checking, though, and I'll let you know what the find.

Here's what's running on the FreeBSD 4.5 server...

/usr/sbin/inetd -wW (TCP Wrapping)
/usr/local/sbin/sshd (OpenSSH-based as I understand it)

Other clients? My first client was Vandyke's SecureCRT. That worked from my old job, and still works fine at home, but simply won't connect period here.

I evaluated F-Secure's SSH client, and was able to connect, but couldn't upload OR download using ZMODEM, and their sftp client didn't work either.

Here's the note I wrote F-Secure's helpdesk:

{BEGIN NOTE}

I am evaluating both F-Secure's and Van Dyke's SSH clients for Windows.
I have already bought VanDyke's SecureCRT for home, but it simply
doesn't work from my (new) office, thanks to a quirky firewall
configuration. So I tried F-Secure, and it worked first try!

The only difficulty I'm having is in transferring files. SecureCRT
supports X/Y/ZMODEM transfer, which F-Secure doesn't (apparently). So I
tried your FTP Windows interface. If I try the plain FTP protocol, I t
ted. (My destination machine is a FreeBSD 4.3 machine running a TCP
wrapper. My IP is dynamic, and the admin doesn't want to add a range of
machines to his allow list, so I need to use SSH.) When I select SSH as
the protocol, I get an "invalid packet received error." I get the same
error when I try scp2 to do the same thing on the command line (see
below). ##
scp2: warning: ssh_packet_wrapper_input: invalid packet received: len
1380270408 closing the offending input channel.

The connection then is closed. Could you offer me any help with this?
It's a definitey buy if I can get file transfer to work, otherwise I'll
keep looking...

{END NOTE}

The tech support guy wanted me to reconfigure things on the server, which wasn't an option really, so I moved on to you... :-)

The program takes measures to avoid WSAEWOULDBLOCK conditions, but I've been reading about a bug in Win9x code that can cause additional problems. I've implemented a workaround that may just do the trick, but I'll need you to test it, as I cannot recreate the error condition.

You can download it here: http://www.celestialsoftware.net/telnet/AbsoluteTelnetBeta.exe

Let me know how it works!!!

We're making progress! I am able to send ASCII .txt files just fine. However, errors pile up while transferring binary files (e.g., .exe, .jpg, .doc, etc.). I tried the -b (binary) flag for lrz, but it still didn't work. Something I'm doing wrong perhaps?

- Van

Ok, to sum up....

1. The buffering problem is fixed in 1.81
2. The WOULDBLOCK problem is fixed in 1.82 rc1 (I was able to find an old Win95 machine to reproduce the problem and verify the fix)
3. You're still having problems sending binary files because errors are produced, eventually causing the transfer to fail.

Errors should not normally occur, because TCP/IP (by definition) is supposed to correct any errors that occur between sender and receiver. This is, of course, different from a zmodem transfer across a raw modem connection where line conditions can cause errors in the transmission.

Errors in the transfer (especially when isolated to binary files) usually means there is something between the sender and receiver that is trying to do ascii translation on the data in transit. Thus, the receiver is not receiving exactly what the sender intended.

This is a little harder for me to diagnose because I'd have to replicate your environment in order to trigger the problem. Perhaps you can arrange for me to have a guest login to do a little testing???

Other than that, try isolating the problem by removing some of the variables. For example:

1. Try to send a file to a machine on your side of the firewall
2. Try sending a file to a machine with another version of lrz (or the standard rz/sz package)
3. See if receiving a large binary file works, while sending does not

You see??

Keep me posted...

Brian,

Thanks for all the help so far. I can receive (i.e., lsz from the server) large binaries just fine; it's just the sending that I have trouble with.

As far as sz/lz go, they're not part of FreeBSD's standard distribution. The only thing available is the lrzsz-0.12.20 port.

As far as testing it on a local machine, my office is depressingly void of anything Unix. :-(

For the time being, I'm going to work on the assumption of either operator error or something a little buggy on the lrzsz port side. If I can't come up with anything, I'll get back to you and see about setting up a guest login at least on the server side so you can test it with lrzsz a bit more.

Thanks!

Can give me the usage statment from your lrz command? This can be retrieved most likely by typing 'lrz --help' or 'lrz -?' at the command line.

Do you have access to any non-BSD UNIX machines that you could try?

No. But my admin does. Maybe I can ask him to help out with this. I'll send him the latest beta and see if he has a few minutes to try both file transfer functions on a BSD and non-BSD machine from his PC.

- Van

UPDATE: Even though the errors pile up when I run the 'lrz -be' command on some binaries, it appears that the transfers actually work (once I saw the errors, I was cancelling without trying to transfer the whole file)! The transfer window reports about one error per packet, BUT, whatever the error is, it doesn't actually seem to affect the integrity of the file.

SO, it looks like the latest RC works fine, perhaps it's just too sensitive in it's error reporting?

I'm still working on my admin to do some testing and set you up with a test account, nevertheless...

- Van

So, do the transfers actually work with both the -b flag and the -be??? I'll research the error reporting.

Apparently the -e flag is what saves the day... Though again, for me at least AbsoluteTelnet is still reporting the errors...



[ February 13, 2002, 05:24 PM: Message edited by: vanhoose ]

Ok, I think I've got it. The program was counting certain timing conditions as errors, when really they were not. This explains why the file was still getting through even though every packet sent generated an error. The only thing counted as errors now is when the server requests a resend of data due to an error in transit.

Still, I'd like to know why the -e is required. I suppose this can be due to interference from the tty (which the -e was designed to work around).

You can get the latest here:

http://www.celestialsoftware.net/telnet/AbsoluteTelnetBeta.exe

Brian

The errors are no longer being reported. Thanks for all your help. This is a great app!

- Van