Renzo Rosales wrote on Fri, Mar 05, 2021 at 14:53:02 +0000: > 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.
In the Putty case, what URL scheme do they use over the port forward? > 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? Run `svn up` over SSH port forwarding then `svn up -r BASE` over the VPN. That should be a no-op update. Does it fail the same way? What about, say, `svn ls -r BASE --depth=empty`? (That's a network operation) Check not just the httpd error log but also the system one, in case it's a packet filter or firewall that killed the connection (notwithstanding the rule you've reviewed). Also, naturally, what's the common thread to the paths that fail, and to the paths that don't. > Would a packet capture help me identify what is going on? If so, what should > I look for in the capture? Well, there might be a clue in there. Look for whether it was a FIN or a RST, and what happened immediately before it — e.g., silence (suggesting some sort of timeout), or client→server data, or server→client data. Cheers, Daniel
