The SSH tunnel is set to use local port 8080 redirect to port 80 on the remote Fedora system on port 80.
After running the svn up over the SSH tunnel, most items are updated but 3 external items fail with the error: "svn: warning: W730054: Error running context: An existing connection was forcibly closed by the remote host." Then after running "svn up -r BASE" over the VPN I receive "svn: E730054: Error running context: An existing connection was forcibly closed by the remote host." Running "svn ls -r BASE --depth=empty" gives me an empty response. Paths: Doesn't work: http://server/root/folderA/folder1/folderi/folderone Works: http://server/root/folderA/folder1/folderi/folderone/foldertwo -----Original Message----- From: Daniel Shahaf <d...@daniel.shahaf.name> Sent: Friday, March 5, 2021 11:52 AM To: Renzo Rosales <rrosa...@zentekds.com> Cc: users@subversion.apache.org Subject: Re: Connection was forcibly closed 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 Email as a communication tool is quite similar to a POST CARD. Short, public and not certified in any way. As such, we cannot assure you that the information you receive from us by Email is accurate, complete in every respect or even FROM whom you believe it to be from. In addition, as senders of Email we cannot be certain that it is "You" (the "you" to whom this Email was addressed) that is reading this. Therefore, we offer NO ASSURANCE about the relevance or validity of information contained herein or the confidentiality and privacy of that information. We encourage you to TALK to us directly if you have any questions or comments.
