Download failed at 75% may be ftp problem on wingate

[ragefury14]

Hello, each i'll try to download on a ftp website, the download failed arround 75%. When I try to download directly on the wingate computer, it working well. This problems occurs since i'd install the 5.2.2 version. I use Nat and the transparant redirection. But i'll try to donwload without this option but it's not working. Is it a ftp problem?

Someones help me

[neil]

Do you have the AV installed for WinGate?! If so could you disable it for FTP and try downloading something and see if it works correctly?! also can you download through www normally?

Regards

Neil

[saubrey]

A few of us have complained about this same issue with 5.2.2 over the last few weeks. Please check the logs...all cases are similar. The problem is not with AV. It seems to be a problem with www/ftp proxy caching...although still no official word from Qbik on the root cause (and a fix) for this issue.

[cjtrevor]

I am having same problem at the office network.

This is a real major problem as some critical information can no longer be downloaded.

Will a fix be issued soon or is there a way of getting a previous version that works 100%?

[rayden5_]

This also happenes to me. So I wonder if there any News about this isue and maybe some fix ?

ray

[cjtrevor]

Can anyone from Qbik please comment on this problem?

We pay good money for the licence and this is causing our office real problems in not being able to now access documents that our critical to the running of our business.

A prompt solution is required if we are to continue with this product.

[pecos]

I've just had the same thing happen; the download stops at 75% every time. I don't have antivirus installed.

(For the longest time I couldn't get ftp to work at all because I had the browser's ftp proxy set to port 21 instead of 80.)

[fpuded]

Hi there,

the problem is not caused by a AV Scanner, the problem is caused by a fault in the actual Wingate Version! We do several test's here...
Funny thing when you have to download a very big file and it breaks everytime after 75 %.. you contact then the owner of the FTP-Server and told them that the file on his server must be damaged. It is a great thing when you find out then that this was caused by the Wingate Proxy!

Could be happen, yes ... but it is not so good when Qbik ignore that. It seems so many users of the new Wingate have it.. so it must be possibel for Qbik to find out why and to explain it. For the moment the new Wingate Version is not very usefull... every FTP Download will stop after 75 % only http download is possibel...great thing!

Qbik- Time to wake up! Otherwithse it will be very bad for further bussines, bad support is a thing what most IT-Experts doesn't need!

By

Frank

[maznos]

from my personal tests i figured out a simple 2 solutions
1. use ftp gateway (need ftp client)
2. use sockscap and enjoy proxyless connections to what ever

thats what i use for my systems
Thanx


Mazen
Yemen

[Pascal]

This is intriguing. If you are not using any plugins, there should be no buffering on the FTP proxy. Normally, when you are using plugins, the data is buffered up to a point, then drip-fed through to the client in small chunks while the appropriate scanning is happening on it. The arbitrary limit when we start drip-feeding is 75% of the download size.

Is this with connections through the FTP proxy OR through the HTTP proxy ? Is it possible for someone to post a portion of the appropriate log file, please ?

[Pascal]

Alright, found the problem and fixed it. This is the case if you are using IE through an HTTP specified proxy. It only seems to occur with versions of IE prior to 6.0 (6 tries port 21 for FTP proxying)

So there are several alternatives available:

1. Wait for WinGate 5.2.3 which will include the fix (And is due out soon)
2. Remove the FTP proxy entry from your proxy configuration and let it NA
T directly (Temporarily, until fix becomes available)
3. Configure it to use port 21 for the FTP proxy (And thus bypass FTP through HTTP)

[cjtrevor]

We are using IE 6.0 on Win XP prof SP1 and get the fault. Our IE settings on the workstation computers are set to "use proxy server" of the wingate server machine, all port 80.

I will set the ftp to use port 21 when I get into the office and see if that fixes it.

Do you have an estimated date for the 5.2.3 release please?

[Pascal]

We are using IE 6.0 on Win XP prof SP1 and get the fault. Our IE settings on the workstation computers are set to "use proxy server" of the wingate server machine, all port 80.

I will set the ftp to use port 21 when I get into the office and see if that fixes it.

Do you have an estimated date for the 5.2.3 release please?

That's interesting. Using IE5.5 it shows up as a HTTP request in GateKeeper. When we switch to IE6 it shows up as a FTP request (Despite setting it to port 80 in the Proxy Setup)

What does it show up as in your configuration ?

Release date is not 100% confirmed at the moment, I'm hoping for as soon as possible, we've basically completed everything we want in this release.

[cjtrevor]

Can you please tell me where I need to look to find this , or is there a way of logging and then how to access this to let you see it?

Its 10pm sunday here in the uk but if you can let me know what info you need and where i find it i'll happily find it for you as soon as i am in the office tomorrow as we really need this sorting asap!

Don't know if this makes any difference to the way you're testing - our workstation computers have no "gateway" defined and no access to the internet. Except for the fact that IE is configured on each machine with the "use proxy server" 192.168.0.101 (wingate machine) port 80. No wingate etc software on the client machines, just proxy connections as set in IE.

We get the same problem on our Win98 machines and our Win XP prof machines which have all the latest windows update patches installed.

[Pascal]

Its 10pm sunday here in the uk but if you can let me know what info you need and where i find it i'll happily find it for you as soon as i am in the office tomorrow as we really need this sorting asap!

The easiest way to do this is to simply watch activity in GateKeeper when the connection is being made. If it is using FTP through the HTTP Proxy, it will show up with the stock-standard web-page icon (Document with a planet over it). If it is going through the FTP Proxy it will show with an icon that looks like a Folder with a 3.5" disk over it.

An alternative is to use the LogFile Server in WinGate (If you have it bound externally) and to retrieve the WWW and FTP log files that way. That way you can check which one is getting the traffic.

Your configuration sounds the same as what I had here, I don't see a problem with that. Our initial run on IE6.0 had <WinGateIP>:80 specified for the proxy server. On the WinGate machine it showed up as an FTP Session (Port 21) rather than Port 80 as we'd have expected. If you disable the FTP proxy in WinGate, it will use Port 80 but gave us a warning that you wouldn't be able to upload files, etc.

It might be that further configuration is required in IE6 to get it into a working state.

[cjtrevor]

I've got a feeling from memory that the ftp proxy is disabled on the wingate machine.

Will check tomorrow and reply then. However its was only since installing the upgrade to 5.2.2 that this problem started, before then was fine and we haven't changed anything on the wingate machine inbetween.

[Pascal]

I've got a feeling from memory that the ftp proxy is disabled on the wingate machine.

Will check tomorrow and reply then. However its was only since installing the upgrade to 5.2.2 that this problem started, before then was fine and we haven't changed anything on the wingate machine inbetween.

Yup. I'll be online tonight as well, and monitoring the forum (Alternatively, contact me directly on the email address listed on my profile) so we can sort this out for you ASAP.

[pecos]

I get this behavior with Opera 7.22 on the server machine.

With ftp proxy set to port 21, transfers do not occur at all. With the port set to 80 transfers show up as http traffic and stop at 75%. With the ftp port unchecked in the browser preferences, transfers succeed but they don't show up in Gatekeeper at all.

--Tom

[Pascal]

I get this behavior with Opera 7.22 on the server machine.

With ftp proxy set to port 21, transfers do not occur at all. With the port set to 80 transfers show up as http traffic and stop at 75%. With the ftp port unchecked in the browser preferences, transfers succeed but they don't show up in Gatekeeper at all.

--Tom

Okay, we're having the same problem with Opera. Do you have ENS installed ? If you do, it sounds as if (With the ftp port unchecked) you are getting the traffic going out through NAT. If that is the case, you could always enable Transparent Redirection (FTP Proxy Service -> Sessions - >Redirect ENS/WGIC Sessions) which will push it through the proxy.

[rayden5_]

Hi,

if I understand it corectly it should only happen with IE Version sess than 6.0 ? we are testing this on 5.5 an it happens (as expected), but it only happens with IE 6.0.2800, so I wonder if I got something wrong ?

also i have the sam eexperince like many others: When using FTP-Proxy on Port 21, instead of HTTP port 80 for my FTP-Transfers, I dont get the file at all I only got this "220 WinGate FTP-Proxy Ready" Message.

We dont have ENS installed, neither actived Firewall or AV PLugin (WinGate just pass through all data to our hardware ROuter/Firewall).

Is there a way how I can get FTP working until new Version comes out ?

Thx
ray

[Pascal]

http://forums.qbik.com/viewtopic.php?t=838&highlight=220+wingate

That forum post has some suggestions for the 220 WinGate Engine Ready message. Unfortunately, for anything that attempts an FTP download through the HTTP proxy it will be broken at the moment. The easiest way is to bypass that proxy and use the FTP one. Adrien also suggested using the SOCKS proxy ...

One rather radical suggestion might be to install one of the plugins with a trial license, but that might be more pain than it is worth if your setup does not require it.

I am not 100% sure which version of IE 6.0 we used to test in the QA lab, I can check for you tomorrow to confirm.

Unconfirmed release date for 5.2.3 is sometime this week, but that is NOT a definite decision yet.

As a side thought, if you are not using any plugins, are you using Policies / Authentication at all ? Otherwise, you might as well use NAT and ignore the proxies completely ...

[cjtrevor]

ok here is what I have found this morning -

- on the wingate machine ftp proxy is enabled (always has been)

- with all proxy set to the same settings in IE to port 80, the ftp file request is shown in the gatekeeper console as the normal http symbol and the file is corrupt, can't be opened by acrobat reader.

- with IE proxy setting changed so ftp is set to port 21 i get the message "220 WinGate Engine FTP Gateway ready" on the client computer when I try to access the file.

any suggestions please?

our IE6 is ver 6.0.2800.1106

if this will be definitely fixed in an update later this week then it may be easier to wait but we really would like assurance that this will definitely be fixed asap.

[Pascal]

if this will be definitely fixed in an update later this week then it may be easier to wait but we really would like assurance that this will definitely be fixed asap.

It is definately fixed.

[cjtrevor]

ok, look forward to the update! any chance you could do me a favour and email me when it's available for download?

thanks for looking at this.

[Pascal]

ok, look forward to the update! any chance you could do me a favour and email me when it's available for download?

thanks for looking at this.

Yup, I'll post to this topic as well.

[e.schwartz]

Still desperatly waiting for a fix! Any news about this???? When will the new version be available? Is it possible to roll back to version 4 without losing the settings?

[Warren]

Hi ALL,

Some days back, I responded to the following subject "220 WinGate FTP-Proxy Ready", as I was having the same difficulty. I now notice that his has appeared again in this subject. The previous discussion related to ftp/http file transfer and I presume that the above messages are related in some way. For background, the following is the link to the previous subject: http://forums.qbik.com/viewtopic.php?t=838

The problem that I and other were trying to resolve, was the downloading of files through http sites. In my case, I was attempting to download updated WinXP Pro Drivers from the HP Drive Download site. Well in the end, the fixes that were discussed worked and I duely got two driver files downloaded. However when I went to open them, a Windows? message appeared saying that the files were damages. As they were Zip files, I tried looking at them in WinZip and the various compacted files were there, but again WinZip reported the .exe? file as being damage.

I then tried downloading the same two files from the WinGate Server; as against a Client. Same result. I could expect that some sites have damaged file, but, to me it seems strange that a reputable site such as HP would have two damaged files. "Maybe it has something to do with them having aquired Compaq - cross contamination or something. Sorry HP just joking. "I apologise". I know that all you are trying to do is keep up with the competition."

So the question is: Does this problem with the damaged files have anything to do with the above discussion, or is it something else.

Any comments and suggestions would be appreciated.

Regards, Warren

[nicolas]

Hello,
I have the same problem. When I download in my browser a file through ftp, my download failed.
In fact the problem is due to Puresight. When I disabled the plug-in Puresight, I can download my file through ftp in my Web browser.
If you choose to change the proxy port in your web browser to use your ftp proxy, the server respond : "220 WinGate FTP-Proxy Ready".
So the onmy solution I have found is to use FTP client to download the file without to use the web browser.
Anyone comments about puresight would be appreciated.
Thanks.
Nicolas.

Hi ALL,

Some days back, I responded to the following subject "220 WinGate FTP-Proxy Ready", as I was having the same difficulty. I now notice that his has appeared again in this subject. The previous discussion related to ftp/http file transfer and I presume that the above messages are related in some way. For background, the following is the link to the previous subject: http://forums.qbik.com/viewtopic.php?t=838

The problem that I and other were trying to resolve, was the downloading of files through http sites. In my case, I was attempting to download updated WinXP Pro Drivers from the HP Drive Download site. Well in the end, the fixes that were discussed worked and I duely got two driver files downloaded. However when I went to open them, a Windows? message appeared saying that the files were damages. As they were Zip files, I tried looking at them in WinZip and the various compacted files were there, but again WinZip reported the .exe? file as being damage.

I then tried downloading the same two files from the WinGate Server; as against a Client. Same result. I could expect that some sites have damaged file, but, to me it seems strange that a reputable site such as HP would have two damaged files. "Maybe it has something to do with them having aquired Compaq - cross contamination or something. Sorry HP just joking. "I apologise". I know that all you are trying to do is keep up with the competition."

So the question is: Does this problem with the damaged files have anything to do with the above discussion, or is it something else.

Any comments and suggestions would be appreciated.

Regards, Warren