(If I am in the wrong forum, please direct me accordingly.) I run Absolute Telnet 3.85 on Windows 98. (I cannot afford to upgrade either.) I establish a dialup PPP connection to my ISP, which runs netBSD servers, and "A.T." into my shell account using SSH-2 and XTERM emulation. From time to time I want to transfer files between my shell account and my Win98 box. Just this evening I had no problem transferring straight text files in both directions with Ascii Zmodem transfer. However, I am not able to download a binary file from the shell host to the Win box. On the shell host, I cd to the directory where the file resides. Then I enter (no quotes) 'sz -b sample.jpg' for a 252830-byte JPEG file. The A.T. Zmodem receive message box opens, and the "progress meter" shows file transfer. But as soon as it appears that the transfer is complete, I get the error message "Transfer failed!" and there is no file on the local machine. This happens every time I try it. I know that the JPEG file is good, because I can open it with a web browser (Opera, in my case). See <broken link removed> .   Any ideas on why Ascii transfers succeed and binary transfers fail? Thanks. [size=1][ November 02, 2006, 12:32 AM: Message edited by: Brian T. Pence ][/size]

Paul, Can you test with 5.06 to see if it makes a difference? A number of changes have been made to the file transfer since 3.85.

<old link removed> Please download version 5.06 or newer.

Brian

I downloaded it but have not installed it. Will I be charged if I install it? My year of free upgrades has come and gone. You are entitled to the fruits of your labor, but I genuinely am in a money pinch just now. (I think A.T. is a great product, and your support shines. I have been using it for several years now and have pitched it on my ISP's in-house newsgroup.)

If I install the later version, will my *.TNT files still be valid? They are what I use to access my ISP's servers so that all my settings are rolled in. Do I just install the later version right over the top of what I have?

I forgot to mention that the problem with binary file transfers only arose after I switched to using SSH-2, if that is significant. Most of the transfers I do are Ascii.

You can install 5 on top of what you have or in a separate directory.

You can always install the older version after you're done testing. TNT files will not be affectedd, but make a copy of them if you're worried about that.

Just a short time ago I finally had a chance to install version 5.06. The installation went fine, but it turns out not to be usable, at least as things are now set up.

I started v. 5.06 and went to open one of my .tnt files. Very quickly I got an error message: "Connect to panix2.panix.com failed. Winsock Error: the namelen argument is incorrect." (My ISP has five shell servers. I commonly login to one of them specifically for SSH-2. However, I have SSH-2 .tnt files set up for all five.)

So v. 5.06 is not working. I reinstalled v. 3.85 back over the top, and I am able to login again just as before. When I did the installation, I forgot to install 5.06 in a separate directory, so it and the reinstallation of 3.85 went into the same directory.

I do have a problem with this machine, something having to do with name resolution, that affects three different web browsers as well as A.T. Sometimes things will hang for almost a minute and then break loose on their own. However, I got this winsock error message almot immediately, and I tried it a couple of times.

[size=1][ November 03, 2006, 06:08 PM: Message edited by: Paul O. Bartlett ][/size]

Winsock Error: the namelen argument is incorrect

You're the second person to report this. May have something to do with the new IPV6 code in version 5 not working properly under Win98. In Win98, it is supposed to gracefully degrade to IPV4-only because Win98 does not support IPV6. I'll have a look.

I do have a problem with this machine, something having to do with name resolution

I've heard of this happening on Win9x with dialup accounts. I'm not sure why it happens, but it is not A.T. specific, so I'm not going to be much help resolving that. In any case, it is not related to the problem above.

I'll have to work out the "namelen argument is incorrect" issue and get back to you to test the real original problem of zmodem transfer.

Brian

Thanks for the quick response. I tried 3.85 with another binary file, this time a PDF, and the transfer still fails. There should be a way to convert a binary file to Ascii encoding so that I could download two files. Something about base64 or some such. I need a temporary workaround. It may be Monday before I get to it, though.

You could use uuencode/uudecode, but you'd have to be able to uudecode on the Windows side.

Or, you could just wait till I have this figured out. I'm working on it tonight.

Brian

Alright, Paul. I've got this fixed. You should be able to connect using SSH2 on Win98 now. Now, if you could test the zmodem, I'd be grateful.

<old link removed> Please download version 5.09 or newer.

Brian

I downloaded it, but I am working this weekend, so I will probably not get to it until Monday. I will keep you posted.

STATUS REPORT:

The attempt to use 5.09 was only partially successful. I was able at least to login to my remote shell account, but I was not able to download files.

I have a PDF file, 774352 bytes. I UUENCODEd it to 1066922 bytes. When I tried a 'sz -b xxx' for the PDF, the download started, but after a while the progress meter and bytes received field "stuck" and did not increase. I noticed that there was a bytes received received field, but in the panel the bytes transmitted (so I am guessing) field was truncated in the display and hard to read. Anyway, eventually the transfer ended, as shown by the little icon in the system tray for a dialup connection, but there was no message of successful or failed completion. When I looked in Windows Explorer, there was no file in the directory.

When I tried to start the download, A.T. complained that "C:\\Download", my download directory, did not exist, even though it has existed for years. I clicked on the directory in the message box, but A.T. did not seem to accept it, but eventually started the -- failing -- download.

Next I tried 'sz -a' with the UUENCODEd file. Same complaint from A.T. that the C:\\Download directory does not exist, even though it does. Eventually the download started. It failed, although I did not get a message one way or the other, as just about then my firewall put up an alert about an intrusion attempt. (I have been getting a lot of those lately.)

Another item. Both 3.85, my current version, and 5.09 both say from time to time that my panix2.tnt has been modifed, even though it hasn't. I don't know what they are complaining about. When I go to close A.T., I have to tell it not to save any -- nonexistent -- changes.

Are you using the US-English version of Win98 or one localized in another language?

Do you have access to a Win2000 or XP box somewhere where you can test sending from the same host to a different client?

What type of host are you using?

What version of sz?

Any chance you could give me a temporary login to that machine so I can test this myself? It may be something host specific that I am not able to reproduce here.

Brian

1. US-English, no localization.

2. No. An old, decrepit computer running Windows 98 is all I have and have access to. If this old machine ever breaks down, I am out of luck. (Some of us are behind the technology curve and can't do anything about it. We're lucky to have anything at all.)

3. NetBSD 3.1_RC3, according to the login of the shell host. I don't know what kind of front end servers are involved.

4. 'sz --version' shows "sz (lrzsz) 0.12.20". It is whatever is supplied by my ISP. I never previously had a problem transferring files. I don't know what changed, as not long ago I was able to transfer even binary or large Ascii files with A.T. v3.85.

5. So far as I understand, I cannot give you temporary login without giving you total access to my account with my userid and login password, and that would violate my subscription agreement with my ISP, if I recall correctly. My ISP is a commercial enterprise in New York City, and they run a tight ship. Bend the rules and you're out on your ear.

A bit more. I can upload and download Ascii files in the 10's of KB size range with no trouble. But I am wondering if there is a filesize problem involved. I tried to upload a 379KB ZIPfile and ran into trouble. For a long time after the transfer started the dial-up networking icons in the system tray flashed on and off back and forth, but eventually the message box disappeared, and all I got was "square box" characters at the shell prompt, and it took 14000 ^C's to break things loose. An attempt to upload an 87KB ZIPfile also failed with the same problem.

ADDITIONAL INFORMATION

Usually I use A.T. in SSH-2 mode for the security. However, not long ago I decided to try an experiment. Rather than login to my shell host with SSH-2, I tried straight TELNET. Now I got some different results.

I was able to download large files with Zmodem in both Ascii (almost 1MB) and binary (>700KB) modes correctly. One was a PDF (binary) and the other was a UUENCODE (Ascii) of that same file. Both were received on my Win98 machine correctly. The Ascii file UUDECODEd correctly, and both versions of the PDF were good. So there is a first impression that somehow SSH-2 as such may be involved.

There is still the erroneous message about the download directory being missing, even though it isn't. I have to go through the directory browse and select it, and even then the download process still squawks. I have to go through that a time or two and then Cancel, and the download starts. I don't know what is going on here.

HOWEVER, I cannot upload successfully in TELNET mode, either Ascii or binary. I start 'rz -a' on the shell host. Then I get the usual browse box to select the file. I select the file, and the browse box pops up again. I select the file a second time, and then the upload supposedly starts. But within just a second or two the Zmodem progress window closes, some gibberish shows up on the shell host, and I have to ^C out to interrupt.