Problems with FTP Proxy uploads

[olaf.krause]

I had a very strange problem:
tried to upload a 102kb xyz.php file to my homepage. Than I saw that after the transfer the file was 169kb big. After checking the content I saw that the file was cut in the middle (not exactly) and it startet again from the beginning. This was absolutely reproducable (I tried it 10 times).

After switching to NAT everything was OK. Any ideas?

Version 6.1.1 with newest KAV plugin.

[adrien]

Hi Olaf, we'll have to check this.

Doesn't sound good.

I'm wondering if for uploads the buffer handling for the KAV scanning is broken, and is re-appending the entire file when it is scanned.

Adrien

[olaf.krause]

did you find something - or cannot retest it with a debugversion or...

[Pascal]

Olaf, were you using the FTP proxy (With an FTP client) or was it FTP through HTTP? If an FTP client, which client were you using?

[olaf.krause]

Olaf, were you using the FTP proxy (With an FTP client) or was it FTP through HTTP? If an FTP client, which client were you using?

WS_FTP Professional 2006

[Pascal]

Hi Olaf,

I just got a response from our QA team:

Couldn't reproduce this in the lab. Tried the WS_FTP professional 2006 client with trial lic. through ftp proxy server on latest WG version with latest KAV plugin (OS 2k Advanced server). Uploaded files ranging from about 100k to 8M and each one completed successfully, with uploaded files that were identical in size to the originals (virus files were successfully caught and quarantined by KAV). More specific config info is required I guess (OS and WG).

So a few more questions then:

1. As per QA request, what OS are you using?
2. How do you have the client configured? Is it logging into the proxy or being intercepted?

[olaf.krause]

Hi Olaf,

So a few more questions then:

1. As per QA request, what OS are you using?
2. How do you have the client configured? Is it logging into the proxy or being intercepted?

just retested it. Still has the problem.

1a. Client Windows XP Pro SP2
1b. Wingate runs on Windows XP SP2 too (now). The first time I had the problem it was a windows 2003 server SP1. All OS are german.
2. Client (WS-FTP 2006) uses passive FTP via proxy. NOT intercepted. (internal user with no logon) port 8021.

The file is usercp_confirm.php from latest phpbb build (under include). I sent you my file + a screenshot of the ftp client.

logfile:
01/16/06 20:32:25 192.168.0.54 olaf.krause 0000003380 Requested: FTP: xyz on ftp.xyz.org:21, STOR usercp_confirm.php
01/16/06 20:35:28 192.168.0.54 olaf.krause 0000003380 Traffic 1284 104657 172226 1283 231s

[olaf.krause]

Hi Pascal & Team: any other info needed? Could you reproduce the problem?

[Pascal]

Not at the moment, no. We were hammering away at this one again today and hadn't managed to get a resolution by the time I left. Tom had managed to reproduce it once, but haven't been able to do so since. We're wondering if it might not be related to the particular server (We just setup one in house on one of our public IPs)

Also, we got stuck with WS FTP trying to configure it with the two different port combinations. The one in the screenshot you sent me appears to be a direct connection, rather than one directly through the FTP proxy.

Can you email me the configuration string (As a sample) along with your WinGate registry, please?

[olaf.krause]

Sent you some more infos explaining how ftp-client and proxy are configured.

[Pascal]

Thank you, have passed those on to Tom.

[Pascal]

Thanks. Tom has had mixed success with this issue. We're trying to reliable reproduce it so we can begin fixing it but so far it seems to be fairly hit and miss.

Friday we were using proxy settings. E.g. open <wg ip>, user <username>@<remotehost>, etc. and were unable to produce it at all. Today we tried intercepted connections (As per your setup) and managed to reproduce it.

Switched to proxy connections again to see if it was intercepts, but that failed on the first attempt. Deleted the file off the server and tried it again and it was fine. (Uploading correct size). Switched back to intercepts and it continued to be fine, couldn't reproduce the problem again. No matter if we were overwriting / deleting+storing the file.

So, like I said, inconsistent results in trying to get a useful set of data from these tests. Will keep on trying though.

[Pascal]

Alright, we've managed to work this out and have coded a fix for it. Currently there seems to be two workarounds which you can use while QA runs through this again.

1. In our testing the problem was 100% reproducable using WS FTP and that particular file. Using a different file it would occur 10% of the time. Using a different FTP client and it was unreproducable.

2. Disable KAV or setup a second proxy without KAV for only those uploads.

Once QA has verified the fixed EXE I can email you a copy so you can confirm that it resolves the problem for you.

[olaf.krause]

Alright, we've managed to work this out and have coded a fix for it. Currently there seems to be two workarounds which you can use while QA runs through this again.

1. In our testing the problem was 100% reproducable using WS FTP and that particular file. Using a different file it would occur 10% of the time. Using a different FTP client and it was unreproducable.

2. Disable KAV or setup a second proxy without KAV for only those uploads.

Once QA has verified the fixed EXE I can email you a copy so you can confirm that it resolves the problem for you.

OK I choosed the second option and wait for the binary to retest.

THX

[Nev]

I had a very strange problem:
Version 6.1.1 with newest KAV plugin.

Hi all,

Reporting two instances lately of WS-FTP proxy download failure.

First was a binary bios update utility, via Wingate proxy Win2k Pro SP4.

Second a UPS management utility, via Wingate proxy now Win2k3 SP1.

In each case the file was nearly double the size of the orginal.

In case two, the scanning plugin was taking 98% cpu utilisation and the whole system / client access virtually ceased, which surprised me on my new server ;-(

Am sure there is a solution in the new binary.

[Pascal]

Yup, will be. It's taking a while to test though because the change touched a subsystem used in a few places and we need to ensure that everything that relies on it still functions 100% in all cases.

Should be done early this week.

[olaf.krause]

How is testing going on? Can we expect a new bugfixed version in near future?

THX

[Pascal]

Just checking with QA to see how this is going. I believe the fix was confirmed and that it will be in the next release.