On Fri, Mar 5, 2021 at 9:53 AM Renzo Rosales <rrosa...@zentekds.com> wrote: > > We have a few remote users who are unable to run "svn up" to an internal > server in specific paths in a repository but can access others. The error is > "svn: E730054: Error running context: An existing connection was forcibly > closed by the remote host." The server is in the US and some of the users are > in Russia, they communicate with the server over a VPN not using NAT. If they > use Putty to create a SSH port forward to the server, they can run svn up > without error. > > > > The rule that allows traffic to traverse the VPN does not have any network > filtering in place. I know this server has an OS release and software dated > from 2011 and 2012 (details below), the httpd access logs don't show any > issues (HTTP code 200 and 207), the error log is bare and does not show a > relevant entry that shows why a sync was blocked or not permitted. > > > > What are some suggestions on where I can look to better troubleshoot the > issue? Would a packet capture help me identify what is going on? If so, what > should I look for in the capture?
Fedora 15? That is 10 years old. Don't even waste time trying to tune this, you need to update your base OS for any exposed server, and your exposed httpd and subversion. Don't waste your time tuning your obsolete versions until you've done the basic server updates. If you still have the problem after that, you should be able to get help tuning a version that is still supported. That said, HTTP and HTTPS connections are often "helped" by proxies that are not tuned for really bulky transmissions such as uploading oversized Subversion commits, especially because many proxy owners want to *block* their clients from uploading bulky content and actively hinder long connections. If you're faced with such proxy difficulties, use svn+SSH rather than HTTPS. Nico Kadel-Garcia
