Subversion times out when checking in several files

[k h <xe...@googlemail.com>]

I have a subversion repository that has worked fine for years. When I now
try to check in several changed files, it times out (apparently when the
network connection gives up after several minutes). I can check in some of
the files individually, including every single one in a subset that failed
when done at once. svnadmin verify passes. I am using a direct connection to
the server (i.e. svn://, not svn+ssh:// ). The message is

Transmitting file data ..................svn: Commit failed (details
follow):
svn: Can't write to connection: Connection timed out

I tried starting the server as svnserve -r /home/svn/SVN/repos --foreground
-X in the hope it would say something helpful, but it doesn't (it just sits
there as if it never received the connection at all). It still carries out
simple checkins correctly (and terminates after every one).

The client is 1.4.6 (default on Ubuntu Hardy) and the server is 1.5.4
(default on Ubuntu Jaunty).  It runs over a slowish VPN which does not
appear to molest TCP connections much if at all.

What might I be doing wrong, and where do I start debugging the problem?
Many thanks for any help.

Re: Subversion times out when checking in several files

[Les Mikesell <le...@gmail.com>]

k h wrote:
> 
> 
>     I'd suspect the VPN first.  They normally encapsulate packets,
>     reducing the maximum size for the original data which must then be
>     fragmented if it was already at the maximum packet size. If the
>     sender sets the DF (don't fragment) bit, which is often done
>     unnecessarily, it will fail and have to try to determine the largest
>     packet size that will go through.  And this will fail if
>     intermediate firewalls block the required ICMP packats as they
>     usually do in situations where VPNs are needed.  You could try
>     setting the MTU lower on the client to work around the problem.
> 
> 
> Many thanks. It appears that was the problem. I was inclined to blame 
> the horrible Cisco AnyConnect VPN myself, but i) icmp echo-requests get 
> through fine, and ii) ssh/www/samba work apparently correctly over it. 
> (It would still be horrible even if it turns out to be some firewall's 
> fault :-) )
> 
> For others, the command to try under Linux is something like sudo 
> ifconfig eth0 mtu 300, You should probably use a higher value than 300 
> once it works (1200?).
> 
> Once again, many thanks for your help.

The ethernet max is 1500 and VPN encapsulation might by 40 bytes, so 1460 is 
probably good.   If the vpn endpoint is software on the same machine, I'd expect 
the correct value to be picked up from the interface itself.  If it is 
elsewhere, the firewalling must permit the ICMP 'fragmentation needed' message 
from the 'outside' interface of the router that can't pass it on (and you are 
testing only echo-request/reply messages, probably with the tunnel interface).

But, there is still the question of why a subversion client sets the DF bit on 
traffic that wouldn't be hurt by IP fragmentation/reassembly in the first place.

-- 
   Les Mikesell
    lesmikesell@gmail.com

Re: Subversion times out when checking in several files

[k h <xe...@googlemail.com>]

>
> I'd suspect the VPN first.  They normally encapsulate packets, reducing the
> maximum size for the original data which must then be fragmented if it was
> already at the maximum packet size. If the sender sets the DF (don't
> fragment) bit, which is often done unnecessarily, it will fail and have to
> try to determine the largest packet size that will go through.  And this
> will fail if intermediate firewalls block the required ICMP packats as they
> usually do in situations where VPNs are needed.  You could try setting the
> MTU lower on the client to work around the problem.
>

Many thanks. It appears that was the problem. I was inclined to blame the
horrible Cisco AnyConnect VPN myself, but i) icmp echo-requests get through
fine, and ii) ssh/www/samba work apparently correctly over it. (It would
still be horrible even if it turns out to be some firewall's fault :-) )

For others, the command to try under Linux is something like sudo ifconfig
eth0 mtu 300, You should probably use a higher value than 300 once it works
(1200?).

Once again, many thanks for your help.

Re: Subversion times out when checking in several files

[Les Mikesell <le...@gmail.com>]

k h wrote:
> I have a subversion repository that has worked fine for years. When I 
> now try to check in several changed files, it times out (apparently when 
> the network connection gives up after several minutes). I can check in 
> some of the files individually, including every single one in a subset 
> that failed when done at once. svnadmin verify passes. I am using a 
> direct connection to the server (i.e. svn://, not svn+ssh:// ). The 
> message is
> 
> Transmitting file data ..................svn: Commit failed (details 
> follow):
> svn: Can't write to connection: Connection timed out
> 
> I tried starting the server as svnserve -r /home/svn/SVN/repos 
> --foreground -X in the hope it would say something helpful, but it 
> doesn't (it just sits there as if it never received the connection at 
> all). It still carries out simple checkins correctly (and terminates 
> after every one).
> 
> The client is 1.4.6 (default on Ubuntu Hardy) and the server is 1.5.4 
> (default on Ubuntu Jaunty).  It runs over a slowish VPN which does not 
> appear to molest TCP connections much if at all.
> 
> What might I be doing wrong, and where do I start debugging the problem? 
> Many thanks for any help.


I'd suspect the VPN first.  They normally encapsulate packets, reducing the 
maximum size for the original data which must then be fragmented if it was 
already at the maximum packet size. If the sender sets the DF (don't fragment) 
bit, which is often done unnecessarily, it will fail and have to try to 
determine the largest packet size that will go through.  And this will fail if 
intermediate firewalls block the required ICMP packats as they usually do in 
situations where VPNs are needed.  You could try setting the MTU lower on the 
client to work around the problem.

-- 
   Les Mikesell
    lesmikesell@gmail.com