SCP download to Windows always stops after 500,000,000 byte

When downloading large amount of data from a Linux PC to a Windows PC the process always stops after downloading 476 MB (500,000,000 byte).

Short description:
* my current WinSCP Version is 5.1.5 (Build 3261), but have had the same kind of problem w/ previous versions as well - apparently this is version independent
* my PC now runs Windows 7, 64Bit, but I've experienced the same problems earlier when I had Windows XP. A friend of mine downloads to a Mac PC w/o any problems
* the protocol which I use is SCP
* the setup is GUI, Explorer version
* the problem is, that download always stops after 476MB of downloaded data
* this happens independent from filesize - even in the middle of a file. Filesizes frequently being used are 7MB, 14MB, 35MB, or so. However, as soon as the total amount of 476MB is reached, the download stops and has to be started again manually. This is boring, as I often have to download two digit Gbyte amounts of data
* thinking about it I found out that 476*1024*1024 is 500,000,000 byte - so it looks as if being a specific (hopefully configurable) parameter - inside Windows ???

Looking forward if anyone can help me to nail it down. Many thx in advance ...

Thanks for your report. What does "stops" exactly mean? Timeout? Crash? Something else?

martin wrote:

Thanks for your report. What does "stops" exactly mean? Timeout? Crash? Something else?

'Stop' means, that there is an error message which states, that the remote entity (Linux machine w/ all my files to be copied) did not respond during the last xy seconds. I have another bunch of files to work on during the next 2 days - will look for error message details and post them by end of this week.
What I have tried so far (and did not help) was to increase the time WinSCP waits for a response, but this only results in the situation, that I have to wait even longer, once the connection is lost to be re-connected. So this isn't really the solution. I still believe that there is any kind of parameter within Windows ...

Do you get the same problem with other SCP clients? E.g. pscp.

martin wrote:

Do you get the same problem with other SCP clients? E.g. pscp.

Hi Martin,

thx for asking - I forgot to mention that I had the same problem w/ other tools (tried 2 or 3). This should finally prove that WinSCP is not to be blamed. My hope was / is, that someone recognizes the magic figure of 500.000.000 that immediately strikes the eye. BTW - the error messages are:
1) 'Keine Rückmeldung' = 'no feedback / response' and then, a bit later
2) 'Der entfernte Rechner sendet seit mehr als 60 Sekunden keine Daten mehr' = 'the remote computer hasn't sent data for more than 60 seconds'
Changing the configurable timeout in WinSCP didn't help - must really be inside Windows ...
I really appreciate any tiny hint that guides me in the right direction ;o)

BR, Olaf

Isn't it rather some server-side restriction?
Were it network-level problem, it would not stop on exactly same size each time. It's encrypted connection with lot of packet overhead (with deliberately random size), so Windows nor any other router or anything cannot see that 500M bytes were transferred. Only the server sees that.

martin wrote:

Isn't it rather some server-side restriction?
Were it network-level problem, it would not stop on exactly same size each time. It's encrypted connection with lot of packet overhead (with deliberately random size), so Windows nor any other router or anything cannot see that 500M bytes were transferred. Only the server sees that.

Thx for the very quick response. I would exclude the network too, as this happens also when connecting my Win 7/64 laptop via patch cable directly to the Linux box. Encryption is not used and the traffic which is subject to WinSCP transfer is stored VoIP traces, consisting of very few SIP and tons of RTP packets. This means, that any party involved (incl. my brand new Win 7/64 laptop) should have precise knowledge about the amount data being transferred ... Hope this helps to find a solution ...

BR, Olaf