8

While using uTorrent, DNS periodically stops responding.

The problem appears to not be related to too much bandwidth usage (as seen from the router to the computer), but may be related to some form of flood-protection provided by the router (more incoming connections to router than Windows will accept).

How do I get the network to work properly (while still being able to use uTorrent, of course)?

| improve this question | |
  • What tells you you cannot resolve domain names? Does nslookup google.com work? If not, how about nslookup google.com 8.8.8.8? Please add the output of those commands to your question. – Bob Jun 3 '12 at 11:03
  • @Bob ping couldn't resolve the name, I didn't know about nslookup command, I will check once it stops working, (un)fortunately it works now. Thanks! – Andrey Jun 3 '12 at 11:06
  • While you're at it, jot down the IP address of whichever site you're testing against and try pinging the IP address when it goes down (won't really matter, but doesn't hurt to check). – Bob Jun 3 '12 at 11:13
  • @Bob I did it, I knew IP of one site I visit. So it is totally DNS thing. – Andrey Jun 3 '12 at 15:22
  • @Bob could you take a look at updated question? – Andrey Jun 4 '12 at 18:02
13
+100

bittorent clients aggressively connect to peers ... and some routers interpret this as a syn-flood.

Open Connections

When uTorrent is loaded and uploads/downloads are paused (not stopped) it maintains open connections with your peers. Meanwhile legions of internet peers will still attempt to connect to you to find out if you have the bits they want.

Eventually you will reach the open connection limit imposed by your OS (in Windows 7 this is 10 connections) and connections from new clients will start queuing at your router.

Queued clients will check aggressively to see if a connection is free. This aggressive polling may be interpreted as a syn-flood attack by the router.

Solutions

  • lower your half-open connection limit in your bittorent software below the connection limit imposed by your OS
  • disable IP flood protection at your router/modem.

Bandwidth Saturation

In addition, with uTorrent (or any bulk traffic) connection running unrestricted, the upload (and possibly download) pipe reaches full usage, forcing some "upkeep" traffic to take a back seat, which ends up decreasing network usefulness.

Here is an example:

  1. High speed download (torrent or otherwise) saturates downstream link.
  2. User tries to browse to a site not recently visited. Computer generates a request for DNS info for desired site. "Upload" of request to DNS server succeeds (not challenged for upstream pipe access).
  3. DNS server responds (or tries to), but response gets hung up on trying to get to the user's machine because the download pipe is saturated with download content, and since something has to be dropped, and the download is aggressive about maintaining speed, the DNS response gets dropped (at some point before it gets to the local router).

The same thing can happen if upload is unrestricted. With upload saturated, packets known as TCP-ACK (which are sent as "Hey, I got packet xyz successfully" type responses) get hung up, making downloads grind to a halt, causing web browsing to become very patchy.

Solutions

  • Figure out what the maximum capabilities of your connection are (up and down, individually), and set the maximum speed of your bulk transfer clients to not use more than about 80% of that speed. This will leave "headroom" for things like DNS and TCP-ACK packets to bypass the bulk traffic and get dealt with quickly.
  • Use a router that can handle traffic shaping such that certain traffic (DNS, IMCP Ping, TCP-ACK) can be prioritized ahead of other forms of traffic, and some forms of traffic (torrent in particular) can be de-prioritized. This is my preferred method. This can give the added benefit of allowing the full up and down pipe to be usable for torrent traffic when higher priority traffic does not challenge it.
  • Use some combination of 1 and 2 to restrain "misbehaving" traffic.

If interested in more info about traffic shaping Linux/BSD distros, MonoWall and IPCop both have some good information.

| improve this answer | |
  • This is correct in general, but in this case it was not the issue. All uploads and downloads were paused. So uTorrent generated only its service traffic. The problem was that somehow uTorrent forced false positive alert on router's firewall. – Andrey Jun 11 '12 at 13:22
  • If uTorrent wasn't saturating the up or down pipe (or both), then it shouldn't have been causing any problems... unless uTorrent and the router by way of UPNP (which I would disable, personally) were misconfiguring the router. I have NEVER had UPNP me anything but a problem. – killermist Jun 11 '12 at 13:29
  • @JeremyW that's finally looks like answer. But lowering half-open connection limit didn't help, I set them to 10 but still DNS failed to work properly. – Andrey Jun 11 '12 at 13:58
  • @Andrey Or, maybe the solution is to go the other direction. If windows can handle the connections, increase them, so they aren't being trapped at the router, turning into backlogs. – killermist Jun 11 '12 at 14:42
  • @killermist while I agree with our edits, the question is no longer how can I have both uTorrent and DNS, because I gave an answer, question is more why it is so. – Andrey Jun 11 '12 at 15:55
5

When I have something like that, Wireshark is my best friend.

But first it's good to realize these three things:

  • The fact that ping is working does not mean that the DNS (or any other service) is working, and Vice-versa.

    That is because ping uses completely different protocol (ICMP, while DNS uses IP and a combination of UDP and TCP), on a completely different level of network model. Anything on the way, from your personal firewall through the number of routers to the actual host where the service is running can potentially be configured to throw away one of these but not the other (whether it be admin's paranoia or some failure case), although it normally rather happens to ICMP than others

  • Generally, it's also good to make clear whether it's your (DNS) requests or the replies that are getting lost.

    Well, the particular program you are using should make this clear for you but as a general rule, it's easier to see it yourself in the Wireshark GUI :)

  • As I have mentioned, DNS normally uses UDP as way to deliver the contents of request and response.

    In contrast of it's brother TCP, UDP is defined in a way that there is no guarrantee that the packet will be delivered at all, and there is nothing a router must (nor can) do to let you know about failure. (This is a sacrifice for the another feature of UDP: it's incredibly fast. Routers do not have to keep any information about sender nor order of packets, they just rapidly pass it on and forget. They can even quite safely give them higher priority than TCP.)

Usually first thing I'd do would be:

  1. Start Wireshark
  2. Click Capture Options
  3. For Capture filter, set host 1.2.3.4 to make sure you are only capturing traffic between you and 1.2.3.4
  4. Start capture
  5. Once you have all fired up this way try your commands

However, based on your last update: I don't know this piece of software, but I'd definitely suspect the uTorrent client. It's possible for an application to send too many UDP that e.g. some limit is reached on your home router and it starts to throw UDP packets away.

| improve this answer | |
  • When you have timeouts on requests I am not sure that Wireshark could help. From client side it looks like DNS server just ignores requests, but router drops either requests or responses because of some false positive alert on IP flood. – Andrey Jun 11 '12 at 12:40
  • @Andrey You're right that Wireshark won't tel you where the packet got lost: whether it was on the way there or on the way back. However, it can help to be sure that packets actually left your box, in case something really funky happens. (Like your personal firewall is paranoid or something else is mysteriously broken.) I always like to put these things ot of equation ASAP ;) – Alois Mahdal Jun 11 '12 at 12:47
3

I would try the DNS Benchmark tool from GRC. It tests the DNS servers that you're configured to use, as well as a lot of other DNS servers. Not only does it test their speed, but also their reliability. It's free and doesn't need to be installed (it is Windows only though). There's also a lot of good information about DNS on those pages too.

| improve this answer | |
  • I tried this app, results are strange, usually most of the DNS servers are not responding. Obviously it is impossible that all server out of a sudden stop working. Something is wrong between me and the servers, and I don't know what could it be. – Andrey Jun 10 '12 at 14:59
3

I would like to know in which part of the world you are situated, and it would help to have a tracert/traceroute result for google.com and for 8.8.8.8.

The problem could possible be caused by either your router or by your connection to Google's servers. The intermittent nature of your problem has the smell of bad connectivity, but there are simply too many factors when analyzing Internet connectivity problems to give you a straightaway answer.

Google's network can occasionally become over-burdened. I have daily cases where a request to google.com times out and needs to be restarted, and I do use its local server for my country. It's partly a matter of luck to which segment of Google's network the request is routed, and there may even be inefficiencies in Google's internal request-distribution algorithms.

It is probably the same way with Google's name-servers. Although Google has several of them, the request may be routed to a momentarily over-burdened internal server or network segment.

You have not mentioned in which part of the world you are situated. If you are not in the US, then each request may take a different route and may experience occasional problems or delays if dependent upon too many intermediate servers.

Not to mention any "optimizations" or possible deficiencies of your ISP, or any optimizations that Google may have done to partition the burden world-wide on its servers.

Using a far DNS server may penalize you in other ways. See :

Why using Google DNS / OpenDNS is a bad idea
Should I use my ISP's DNS, or Google's 8.8.8.8?

| improve this answer | |
2

I found solution, although I don't fully understand it, if anyone can explain it properly please post it as answer and I will give bounty to him, because other answers didn't help.

As I mentioned in question's appendix, uTorrent was related to problem, because closing uTorrent solved the problem. I decided to find out how to fix it without need of closing uTorrent. In this thread and this one (it was very relevant because people there have the same ISP and router) I found suggestions that I should disable IP flood protection on my router and it did the trick! The problem and solution were exotic, possibly specific to router Cisco EPC3925 or even to particular ISP (popular in Europe, that's why it was hard to google something in English).

| improve this answer | |
  • If you would have mentioned that this only happens when uTorrent is active, our answers would have been more relevant. – harrymc Jun 11 '12 at 5:37
  • @harrymc I didn't know that at the beginning, when asked a question. Once I found that it is uTorrent is causing troubles I immediately added it to question text. – Andrey Jun 11 '12 at 7:27

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.