2

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.

0

4 Answers 4

1
+50

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

7
  • Don't know why I didn't think of that. I'll get Wireshark on it hopefully tonight. Commented Dec 9, 2010 at 8:56
  • It's just my demeanor... I think of reaching for the sniffer first, usually. Hope you find something. Commented Dec 9, 2010 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? Commented Dec 9, 2010 at 21:19
  • @Chowlett: I dropped on an edit w/ what I'd do next. Commented Dec 10, 2010 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? Commented Dec 11, 2010 at 7:19
0

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.

3
  • Process Explorer showed the server listening on 0.0.0.0, which (if memory serves) is the Wildcard address. To be sure, I set it to listen on 192.168.1.64 (the machine's IP as revealed by ipconfig). No better. Commented Dec 9, 2010 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? Commented Dec 10, 2010 at 18:53
  • To my surprise, I find I'm not running a firewall - even the Windows one is off. Commented Dec 11, 2010 at 7:19
0

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

1
  • Confirmed - as above - that svnserve is listening on 3690. Commented Dec 11, 2010 at 7:20
0

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?

1
  • I'll drop on an edit explaining the behavior. Commented Dec 13, 2010 at 17:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.