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:
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., [url= http://www.sockets.com/err_lst1.htm#WSAEWOULDBLOCK). ]http://www.sockets.com/err_lst1.htm#WSAEWOULDBLOCK).[/url]
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:
https://www.celestialsoftware.net/beta-testing/
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.
$ lrz --help
lrz version 0.12.20
Usage: lrz [options] [filename.if.xmodem]
Receive files with ZMODEM/YMODEM/XMODEM protocol
(X) = option applies to XMODEM only
(Y) = option applies to YMODEM only
(Z) = option applies to ZMODEM only
-+, --append append to existing files
-a, --ascii ASCII transfer (change CR/LF to LF)
-b, --binary binary transfer
-B, --bufsize N buffer N bytes (N==auto: buffer whole file)
-c, --with-crc Use 16 bit CRC (X)
-C, --allow-remote-commands allow execution of remote commands (Z)
-D, --null write all received data to /dev/null
--delay-startup N sleep N seconds before doing anything
-e, --escape Escape control characters (Z)
-E, --rename rename any files already existing
--errors N generate CRC error every N bytes (debugging)
-h, --help Help, print this usage message
-m, --min-bps N stop transmission if BPS below N
-M, --min-bps-time N for at least N seconds (default: 120)
-O, --disable-timeouts disable timeout code, wait forever for data
--o-sync open output file(s) in synchronous write mode
-p, --protect protect existing files
-q, --quiet quiet, no progress reports
-r, --resume try to resume interrupted file transfer (Z)
-R, --restricted restricted, more secure mode
-s, --stop-at {HH:MM|+N} stop transmission at HH:MM or in N seconds
-S, --timesync request remote time (twice: set local time)
--syslog[=off] turn syslog on or off, if possible
-t, --timeout N set timeout to N tenths of a second
-u, --keep-uppercase keep upper case filenames
-U, --unrestrict disable restricted mode (if allowed to)
-v, --verbose be verbose, provide debugging information
-w, --windowsize N Window is N bytes (Z)
-X --xmodem use XMODEM protocol
-y, --overwrite Yes, clobber existing file if any
--ymodem use YMODEM protocol
-Z, --zmodem use ZMODEM protocol
short options use the same arguments as the long ones
