Forum

Downloads work fine...
 
Notifications
Clear all

Downloads work fine, uploads choke

0 Posts
2 Users
0 Reactions
263 Views
(@vanhoose)
Eminent Member
Joined: 55 years ago
Posts: 17
Topic starter  

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


   
ReplyQuote
(@bpence)
Member Admin
Joined: 8 months ago
Posts: 1374
 

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

This post was modified 2 months ago by bpence

   
ReplyQuote
(@vanhoose)
Eminent Member
Joined: 55 years ago
Posts: 17
Topic starter  

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.


   
ReplyQuote
(@bpence)
Member Admin
Joined: 8 months ago
Posts: 1374
 

Just a few questions.....

1. Are you using SSH1 or SSH2???

2. Are you using dialup or high speed access?


   
ReplyQuote
(@vanhoose)
Eminent Member
Joined: 55 years ago
Posts: 17
Topic starter  

SSH2 over a full T1.

- Van


   
ReplyQuote
(@bpence)
Member Admin
Joined: 8 months ago
Posts: 1374
 

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

thanks!!!


   
ReplyQuote
(@vanhoose)
Eminent Member
Joined: 55 years ago
Posts: 17
Topic starter  

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

- Van


   
ReplyQuote
(@bpence)
Member Admin
Joined: 8 months ago
Posts: 1374
 

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


   
ReplyQuote
(@vanhoose)
Eminent Member
Joined: 55 years ago
Posts: 17
Topic starter  

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... 🙂


   
ReplyQuote
(@bpence)
Member Admin
Joined: 8 months ago
Posts: 1374
 

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!!!

This post was modified 2 months ago by bpence

   
ReplyQuote
(@vanhoose)
Eminent Member
Joined: 55 years ago
Posts: 17
Topic starter  

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


   
ReplyQuote
(@bpence)
Member Admin
Joined: 8 months ago
Posts: 1374
 

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...


   
ReplyQuote
(@vanhoose)
Eminent Member
Joined: 55 years ago
Posts: 17
Topic starter  

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!


   
ReplyQuote
(@bpence)
Member Admin
Joined: 8 months ago
Posts: 1374
 

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.


   
ReplyQuote
(@vanhoose)
Eminent Member
Joined: 55 years ago
Posts: 17
Topic starter  
$ 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

   
ReplyQuote
Page 1 / 2
Share: