Overcoming NAT dropouts with BitTorrent & TP-Link TD-W8960N

by Ivan Hamilton 7/5/2012 9:46:00 PM

ADSL Modem/Routers like the TP-Link TD-W8960N must maintain connection information between internet (WAN) and local (LAN) machines.

I'd been having issues with connections "freezing" after a minute or so:

  • MS-Outlook failing to send/receive 
  • MS-Access connections to a remote SQL database would give errors
  • Our VOIP phone would fail to ring on incoming calls
  • RDP connections

I could re-establish the connection, and everything would be fine... until some period of inactivity. This smelt like a network/firewall issue, and the only thing in common was our TP-Link TD-W8960N.

Many ADSL Modem/Routers run a cut-down version of Linux, and the TP-Link TD-W8960N is no exception. Handily, it provides telnet console access and includes BusyBox with sh. NAT services are provided by netfilter's iptables.

You can see the active & maximum number of connections tracked using:

cat /proc/sys/net/netfilter/nf_conntrack_count;cat /proc/sys/net/netfilter/nf_conntrack_max

For me, this returned 2024 & 2024. The router was tracking the maximum number of connections it could. This isn't as much of a problem as it sounds, since once two-way communication happens, connections are marked as ASSURED, and are retained over other connections when the table fills. This stops "active" connections being dropped to preserve connections that were never actually established.

The actual connections can be seen with:

cat /proc/net/nf_conntrack

When I did this I got quite the surprise - ALL of my connections were ASSURED. This means my Outlook, Access, VOIP, RDP connections were eligible to get dropped - and were after enough inactivity. Why? What were the other two thousand ASSURED connections? And why were they all in the TIME_WAIT state?

They were the continual stream of incoming (and quickly closed) BitTorrent connections. But why were they still being tracked?

When a TCP connection is closed down, the connection enters the TIME_WAIT state (which is per default set to 2 minutes). This is used so that all packets that have gotten out of order can still get through, even after the connection has already closed. This is used as a kind of buffer time so that packets that have gotten stuck in one or another congested router can still get to the other end. I was hosting torrents with DHT, and could get 15 connections a second (held for 2 minutes=1800).

2 minutes is complete overkill. If you don't see a packet within a couple of seconds, it's not coming. Also, the "connection" limit of 2024 is far too small (and the TD-W8960N appears to have plenty of free memory to store more connections).

Changing it... 

Luckily, it's very very easy to change. Telnet into your TD-W8960N, enter your username & password (default: admin/admin) and then issue the following commands:

echo "5" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
echo "16360" > /proc/sys/net/netfilter/nf_conntrack_max
That's it. Until the router restarts...

Making the change stick... 

I couldn't find a way to issue custom commands to the router on startup. So, instead I looked for a way to automate issuing the commands. What I needed was a simple tool that took text and sent it over the telnet session.

Enter netcat (or nc).

Get a native windows copy at http://www.rodneybeede.com/Compile_Netcat_on_Windows_using_MinGW.html and extract into a directory (such as "c:\Program Files\nc\") 

I created a script file (conntrack.txt) looking something like this:

echo "5" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
echo "16360" > /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count

And then created a windows task scheduled to run every 15 minutes (Starting in the nc directory "c:\Program Files\nc\")

c:\windows\system32\cmd.exe /c "nc 23 -i 1 -w 2 < conntrack.txt > conntrack.out.txt"

And that's it.

Every 15 minutes, it logs into the router and fixes the NAT settings. If the router restarts, it'll be fixed within 15 minutes.


Currently rated 2.1 by 10 people

  • Currently 2.1/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Related posts

Comments are closed

Powered by BlogEngine.NET
Original theme by Mads Kristensen

About the author

Name of author Ivan Hamilton
"My inner nerd can beat up your inner nerd."

E-mail me Send mail



<<  October 2021  >>

View posts in large calendar

Recent comments





    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    © Copyright 2021

    Sign in