Svn – Problem accessing (previously working) personal subversion repository. Kaspersky suspected

connectionsvnwindows-vista

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 127.0.0.1 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.

Best Answer

(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).

Edit:

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.)

Edit:

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.