You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Renzo Rosales <rr...@zentekds.com> on 2021/03/05 14:53:02 UTC
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
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Mar 5, 2021 at 9:53 AM Renzo Rosales <rr...@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
RE: Connection was forcibly closed
Posted by Renzo Rosales <rr...@zentekds.com>.
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 <rr...@zentekds.com>
Sent: Friday, March 12, 2021 10:25 AM
To: Daniel Shahaf <d....@daniel.shahaf.name>
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 <d....@daniel.shahaf.name>
Sent: Friday, March 5, 2021 11:52 AM
To: Renzo Rosales <rr...@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.
Re: Connection was forcibly closed
Posted by Daniel Sahlberg <da...@gmail.com>.
Den fre 12 mars 2021 kl 16:25 skrev Renzo Rosales <rr...@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 <rr...@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.
>
RE: Connection was forcibly closed
Posted by Renzo Rosales <rr...@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."
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 <rr...@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.
Re: Connection was forcibly closed
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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