Connection was forcibly closed
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 (Locklock) subversion 1.6.18 Apache 2.2.22 Renzo Rosales 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.
RE: Connection was forcibly closed
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 Sent: Friday, March 5, 2021 11:52 AM To: Renzo Rosales Cc: users@subversion.apache.org Subject: Re: Connection was forcibly closed Renzo Rosales wrote on Fri, Mar 05, 2021 at 14:53:02 +: > 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.
RE: Connection was forcibly closed
And these are the last few of a tcpdump run from the server side, 10.0.0.44 is the client in Russia and 192.168.2.41 is the server. Does this mean the client is sending the reset and closing the connection? 10:39:26.621041 IP 10.0.0.44.63556 > 192.168.2.41.80: Flags [.], ack 649, win 254, length 0 10:39:26.621047 IP 10.0.0.44.63557 > 192.168.2.41.80: Flags [S], seq 982372545, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 10:39:26.621631 IP 192.168.2.41.80 > 10.0.0.44.63557: Flags [S.], seq 3498329006, ack 982372546, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 10:39:26.780947 IP 10.0.0.44.63557 > 192.168.2.41.80: Flags [.], ack 1, win 256, length 0 10:39:26.782188 IP 10.0.0.44.63557 > 192.168.2.41.80: Flags [R.], seq 1, ack 1, win 0, length 0 -Original Message----- From: Renzo Rosales Sent: Friday, March 12, 2021 10:25 AM To: Daniel Shahaf Cc: users@subversion.apache.org Subject: RE: Connection was forcibly closed 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 Sent: Friday, March 5, 2021 11:52 AM To: Renzo Rosales Cc: users@subversion.apache.org Subject: Re: Connection was forcibly closed Renzo Rosales wrote on Fri, Mar 05, 2021 at 14:53:02 +: > 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.
