WinGate Forums

by **bztips** » Oct 19 04 9:15 am

We're using the latest version of Wingate (6.0.3); we seem to be having problems with clients trying to downloading large files (eg. 20 meg+) from various websites. I can always download these files with no problem from the Wingate server machine itself, but not from a client behind Wingate. Small file downloads from the same sites seem to be downloaded ok, even to client machines.

With the large files, users are reporting that they never get to the popup asking where the file is to be saved; instead, the Internet Explorer progress bar at the bottom of the webpage they're on gets only part-way to completion, and then just hangs. I've played with the session timeout settings -- has no impact on the results.

Any ideas?

TIA.
/Bill

by **Pascal** » Oct 19 04 9:34 am

Few thoughts:

1. Are you running any data scanning plugins?
2. Do you have drip feeding turned on for the WWW Proxy Service?

Try turning drip-feeding on; if it's not on at the moment.

by **bztips** » Oct 19 04 9:48 am

What the heck is drip-feeding, and how do I turn it on?

Sorry for the ignorance.

/Bill

by **Pascal** » Oct 19 04 9:53 am

Go to the WWW Proxy Service; switch to the "Plugins" tab - at the bottom there is a tick box with a size next to it.

That's drip-feeding. That allows the system to feed data through to the browser while buffering it for a scan. (PureSight or AntiVirus)

by **bztips** » Oct 19 04 10:08 am

Thanks. That did the trick! Funny how I never noticed that checkbox before.

/Bill

by **Alexmillo** » Oct 22 04 8:37 am

I have the same problem, and maybe this is the solution.
But I don't understand if drip-feeding box must be checked only if I use a data scanning plugin or must be checked anyway.

by **Pascal** » Oct 22 04 10:29 am

Drip feeding is only necessary if you have any enabled plugins.

by **Alexmillo** » Oct 23 04 8:38 am

So, I'm experiencing the same problem, can't download large files from the clients (but no problems doing it from the server) and have no plugins installed.

What can I do ??

by **Pascal** » Oct 23 04 10:14 am

How are you connecting through WinGate? NAT/WGIC/Proxy?
Do you have intercepts on?
Which version of WinGate are you using?

How are you downloading the files? Are you using a FTP client or is by clicking on a link in your browser? If browser, which browser are you using?

by **Alexmillo** » Oct 23 04 9:21 pm

I'm using the last version of Wingate 6.0.3 build 1005 and the clients use NAT. No proxies are configured.

What do you mean for "intercepts" ? (sorry for the ignorance :) )

I've experienced these problems the first time when I tried to download XP SP2 from microsoft, clicking on the link in the browser, but not only with microsoft: i've tried without success to dowload Nvidia graphics drivers also, and some other software
The browser in use is IE 6.0 on all the clients.

by **Alexmillo** » Oct 23 04 11:23 pm

I tried to check the drip-feeding box, but I still can't dowload large files.

I made the test trying to dowload XP SP2 from Microsoft again.

by **Pascal** » Oct 24 04 12:12 am

Intercepts are the new "Transparent Redirection". If, on a proxy connection, you go to the "Sessions" tab you should see "Intercepts".

It basically allows a proxy to intercept NAT traffic, so you can redirect it through the proxy while using NAT.

by **Nev** » Oct 24 04 1:48 am

Alexmillo wrote:I tried to check the drip-feeding box, but I still can't dowload large files.

I made the test trying to dowload XP SP2 from Microsoft again.

Hi,

What happens if you use a 'download manager' such as Get Right on the client to handle the delivery of larger files such as SP2?

Report back how it goes!

Nev.

by **Alexmillo** » Oct 24 04 4:42 am

Replying to Pascal, Transparent proxy (intercept) is off

Now I'm going to try with a download manager and let you know.

by **Alexmillo** » Oct 24 04 10:26 am

I've tried with GetRight, and I managed to download the whole file, but it resumed the dl seven times.

by **Pascal** » Oct 24 04 10:59 am

Alright, if that is off you are not using WinGate's proxies at all - so ticking "Drip Feeding" etc. is not having any effect. If you're using NAT all that WinGate is doing is sending packets on for you.

Which is very very interesting that you needed to resume the download so many times. What type of Internet connection do you have? If it is a DHCP allocated IP (Public) how long is it's lease set for?

by **Alexmillo** » Oct 25 04 1:05 am

I have a DSL connection, and I have a static public IP, so I presume that my IP is not leased.
The clients are not using DHCP but have a fixed IP too.

I tried also dowloading from the wingate server and it works fine every time, while the clients fail.

I'm using wingate since version 4, and this problem did not bother me before version 6.

by **Pascal** » Oct 26 04 10:32 am

Are you running the latest build of WinGate 6.0.3?

by **Alexmillo** » Oct 27 04 9:34 pm

I'm running Wingate 6.0.3 build 1005

by **Pascal** » Oct 27 04 10:29 pm

Thanks, our driver guru just wanted to check that - because an earlier release of the driver had a problem with hash entries timing out.

by **Alexmillo** » Oct 29 04 12:02 am

Thank you !!

I hope this can be fixed in the next release :)

Bye

by **Pascal** » Oct 29 04 8:02 am

A previous release had that problem. We've already fixed it in 6.0.3.

by **Alexmillo** » Oct 29 04 9:52 pm

So, how can my problem be fixed ?

by **Alexmillo** » Nov 05 04 11:17 am

So, have you any ideas on how can I get rid of this VERY ANNOYING matter ????

by **Pascal** » Nov 05 04 11:28 am

Not quite yet. Am working with somebody else as well who is seeing a similar problem, trying to narrow it down.

Once they redirected traffic through the WWW Proxy, it went away. One thing that might potentially help would be to temporarily disable timeouts for NAT. (Create a port range for the LAN -> Internet side, and override the timeouts for it)

by **Pascal** » Nov 05 04 11:50 am

Hi Alex,

This will most likely be driver / driver interaction / hardware related. I'm acting as a bit of an intermediary between you and the driver dev team at the moment, but once we have sufficient information they'll probably step in.

The first thing is - would it be possible to do a packet capture while this is happening? You can use any application like ComView, NetMon, etc. to get this capture from the WinGate Server.

The idea is to capture a snapshot of a download like that hanging, so we can analyse the traffic and see who/what/why the download was terminated. The other forum post which looks to be on the same lines is this one: http://forums.qbik.com/viewtopic.php?t=3049.

I'll post back to this one however when we have updates.

by **jtwombly** » Nov 11 04 10:06 am

I hope I'm not completely off base here but...

Looking at the problem downloading sp2 from microsoft.

I had a problem where some of my computers got the blaster or korgo virus. After I fixed the computers they would work fine on the internet, but would not run the sp2 update from microsoft.

On those xp clients I had to run the following command:

proxycfg -p www.xxx.yyy.zzz:pp

where pp is the www proxy port.
sp2 is what it it is.

by **Alexmillo** » Dec 02 04 9:58 am

Dear Pascal,

finally, I managed to capture the packets during a hanged download.
I don't know if all the informations inside the capture are related to this matter, because I've seen callings to and from ip addresses that were not "in use" during the download (I mean that all network related applications were disabled on these PCs), in fact while the dowload proceeded well only the ip addresses "in use" are shown, while when the download hanged many other addresses came out.

Anyway, tell me where I can send the file with the packets.

Bye

by **Pascal** » Dec 02 04 10:01 am

Send it direct to me, please - pascalv at qbik dot com. (Address is in my profile, too)

by **Pascal** » Dec 03 04 4:38 pm

Okay. Talked to Genie. That packet capture is very very interesting. If you look through it you will see that the third to last packet exchanged between the two servers is the RST. It has a special ID (2020) which indicates it was crafted by WinGate.

Taking those rather weird dates into account, the time difference is roughly two minutes. Which, is the amount of time that is allocated to a NAT connection for a timeout.

So, basically what happens is that WinGate did not receive / see a packet from the remote server within two minutes, and then reset the connection.

So that's first off. Secondly, looking towards the start of the packet capture when the connection was established. The TCP Window is extremely small according to Gene. It could indicate that there was communication difficulties between the two servers.

How much that helps I'm not sure, but it's what we can glean from the packet capture. There are a few things though:

Are you using Bandwidth throttling?
It's taken a while to get this capture - is it a regular, repeatable scenario (As in, if you wait an hour, or try it again a few days later - does it succeed)

Just trying to establish why there would be a two minute period where no more data was received on the external interface.

WinGate Forums

large download hang

large download hang

Who is online