Dial-Up Users Receiving Incomplete Zip Files From HTTPS

[KPRO]

I'm a service engineer at wits-end with a particular problem and hope you can help me.

We have a percentage (about 20%) of dial-up customers experiencing a problem from incomplete zip files downloaded from our server. The zip files are received at about 80-97% complete but the status bar on the receivers end indicates 100% complete. In one case, the status bar indicated about 2 minutes left in the download and then suddenly moved all the way over to incated it was "Complete". The zip file was several thousand bytes shy of complete.

The zip files contain JPG images and range in size from 500KB to 40MB. The problem began to occur in mid-April of this year and seems to reoccur with the same dial-up customers. However, the problem is random and the customers may attempt the download 2-3 times and then suddenly the file downloads complete without a problem. The problem is never noticed until there is an attempt to open the file. Then it is noticed to be corrupted.

The downloads are on "https" and there is a proxy server. The customers are on various ISP's and operating systems and browsers. The problem occurs in no particular time zone and at all times of the day and night. The problem does not occur with customers using high-speed connections such as DSL and cable. Some of the issues already investigated are:

- Old modem drivers
- Proxy time-outs
- Browser settings
- Anti-Virus software
- Bandwidth problems

This problem does not affect all of our dial-up customers, only about 20% and it does not affect them 100% of the time. If the files are moved out from behind the proxy and off the secure protocol, the problem stops. However, this is not an option. Help!

 

[bcastner]

Ask the 20% if they have PC-Illan installed.
The active scanning feature is a known issue for this problem.

 

[KPRO]

Thanks, however the vast majority are running Norton as opposed to PC-cillin. We've tried having them disable Norton prior to the download without success.

 

[bcastner]

Norton does not show the issue.

Have them test their client MTU values, and if using a router the MTU settings on the router.

The only sane way is to test. I use the BroadBandReports.com test site, and the utility you can download there "DrTCP" to set client MTU and RWIN values:

http://www.dslreports.com/tweaks

 

[KPRO]

Thanks, I'll check out the site and do some nosing around.

DrTCP would definately help me on my end with my computer, but getting the computer-challenged to comply with the request to download it and test with it is going to be the real challenge of my career.

I certainly agree with you when you say testing is the only sane way to go, but I can't help but have my doubts about this path as it appears to be focused on the symtom rather than the cause.

Although we may find MTU values can be raised on some customer computers, it's not feasible to attempt this on the entire range of inflicted users. First, many are quite litterally computer illiterate. Second, no configurations changed on their end to cause this problem as it suddenly appeared in mid-April. I truly believe the answer lies elsewhere.

However, I will try the DrTCP on one or two of the more savvy users and see what we can see. Meanwhile, give this issue some more thought and let me know what you come up with. Appreciate it.

 

[bcastner]

Once you discover the proper MTU, you can "push" the value through a .reg file at logon or for other users as an email attachment.