Den fre 12 mars 2021 kl 16:25 skrev Renzo Rosales <rrosa...@zentekds.com>:
> 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." > How are the externals defined (ie, what is the content of svn:externals property)? Maybe they are setup in such a way that they don't go through the SSH tunnel? 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. > AFAIK, depth=empty only operate on the current dir, and if the problem occurs in a subdirectory, then it maybe you don't run into the error. > Paths: > Doesn't work: > http://server/root/folderA/folder1/folderi/folderone > > Works: > http://server/root/folderA/folder1/folderi/folderone/foldertwo Kind regards, Daniel Sahlberg > > > > > -----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. >
