I have a personal Subversion server, running just svn (not Apache) on the default port of my home computer, a Windows Vista Pro system. (The setup is more complex than that, due to a restrictive work firewall, but from examining my router logs I'm convinced requests are being forwarded to the correct port on the server machine). This repository has been working previously, but has recently stopped working - requests to it are timing out:

svn: Can't connect to host 'howlett.selfip.net': A connection attempt failed 
because the connected party did not properly respond after a period of time, 
or established connection failed because connected host has failed to respond. 

There are a number of possible reasons I can think of, but none is particularly satisfactory. First, we've recently moved and have changed from a wireless setup to a wired one between server and router. However, I think it has been working wired for a brief period, and (as noted) the router logs indicate requests are being forward.

Secondly, I have recently installed Kaspersky Anti-Virus 2011. This seems a more plausible culprit - it's closer in time to when I think the repo stopped working, and I have found results online for people having problems with Kaspersky 6. However, I have tried adding svn and svnserve to Kaspersky's exception list, and even disabling Kaspersky and rebooting with it set to not start, and the repo still doesn't respond.

Does anyone have any bright ideas what might be going wrong? Failing that, can anyone tell me how to get logs out of Subversion (client and/or server) and Kaspersky?

Edit: Further information - I can access the repository via on the server machine (but not via the router's IP from the server machine).

Edit 2: Network snooping reveals that packets are reaching the svn port on the expected IP address; and svnserve is definitely listening on that address (rather than just localhost).

Edit 3: Use of netcat confirms that packets are not being picked up by a listening service. I've also found Kaspersky's logs, and can't find any reference to traffic being blocked.


(For everybody who knows me, sing along if you know the words... )

Sniff the traffic coming into the Subversion server (use Wireshark or your favorite equivalent) and make sure that the connection attempt from the Internet is really making it to the Subversion server. If the traffic isn't showing up there then you've got a problem at your router / firewall device in forwarding the traffic to the Subversion server.

If you are seeing the traffic at the Subversion server then you need to start investigating why it isn't responding (assuming that it isn't).


I'd guess that you've got a firewall application blocking the connection, then. It looks like the --foreground option for svnserve doesn't actually generate any useful debugging output so I can't suggest you do that. You could stop svnserve and run something like netcat in listen mode (nc -l -p 3690) and attempt to connect and see if netcat shows any output. If it doesn't then the problem is very likely with a firewall application. (A Subversion client won't actually send any data if it connects to a listening netcat as it's waiting on a banner message from svnserve. If you type some gibberish at the netcat prompt after a client connects, though, the Subversion client should bomb out, at least telling you that the connection made it thru.)


Disabling / stopping the stock Windows Vista firewall service causes a very restrictive firewall policy to be applied. You can read an article about it from Microsoft to get more details, but the gist of the behavior is that during bootup this very restrictive policy applies until the firewall service gets up and running (to keep the machine protected during boot). In the event that you stop the firewall service the boot-time firewall policy applies and you end up with a very locked-down inbound traffic policy.

  • Don't know why I didn't think of that. I'll get Wireshark on it hopefully tonight. – Chowlett Dec 9 '10 at 8:56
  • It's just my demeanor... I think of reaching for the sniffer first, usually. Hope you find something. – Evan Anderson Dec 9 '10 at 10:54
  • Yup, thought so - packets are reaching the network interface "Transmission Control Protocol, Src Port: 47423 (47423), Dst Port: svn (3690), Seq: 0, Len: 0" - but these SYNs are never responded to. I... appear not to be running a software firewall, which surprises me, unless Kaspersky is acting as one. What's left? – Chowlett Dec 9 '10 at 21:19
  • @Chowlett: I dropped on an edit w/ what I'd do next. – Evan Anderson Dec 10 '10 at 17:49
  • Thanks. I get no output from netcat either, so something is swallowing the packets between the network card and a listening app. I'm not running a firewall (even Windows' own one is off). Any suggestions from here? – Chowlett Dec 11 '10 at 7:19

From your explanation, only 2 things come to mind: either the svnserve is only serving on localhost, or either, the firewall is blocking access to the externel ip-address. You can for example use "Process Explorer" (from SysInternals) to check on which address the svnserve process is listening.

  • Process Explorer showed the server listening on, which (if memory serves) is the Wildcard address. To be sure, I set it to listen on (the machine's IP as revealed by ipconfig). No better. – Chowlett Dec 9 '10 at 8:55
  • Then it seems there must be a firewall blocking the access. The thing I usually do then, is try telnet to the ip-address on the port and see if something answers. Can you completely disable the Windows firewall just for testing? – rvdginste Dec 10 '10 at 18:53
  • To my surprise, I find I'm not running a firewall - even the Windows one is off. – Chowlett Dec 11 '10 at 7:19

You can see if svnserve is bound to localhost or your external network interface with netstat -a | find "LISTEN"

If it isn't listening on (or the IP of your interface) you need to change the bind params so it actually allows someone outside the box to connect to it.

  • Confirmed - as above - that svnserve is listening on 3690. – Chowlett Dec 11 '10 at 7:20

I've fixed this.

Figuring I might as well get another set of logs, I turned on Windows Firewall (complete with an exception for svnserve), which had previously been off. Doing this made connections to the Subversion server work.

Quite why adding a layer of security and a potential blocking point made everything work, I don't really know - anyone have any ideas?

  • I'll drop on an edit explaining the behavior. – Evan Anderson Dec 13 '10 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.