NAT Sessions overloaded by uTorrent

[cmorbutt]

I am using uTorrent 1.71 Beta.

My downloads and uploads are fine, but whenever i turn on uTorrent, the number of NAT sessions in my router will slowly increase until it hits the maximum (1500 sessions). After that, everything becomes slow and web surfing is unstable (pages dont always load).

Shouldn't the number of NAT sessions correspond to the number of connections specified in uTorrent? Why does uTorrent need to make so many NAT sessions? How can i limit the number of NAT sessions created by uTorrent?

Color of the network status light in µTorrent's status bar (at the bottom of the µTorrent main window)

green

What the port checker from the Speed Guide writes

Port is open

What the Speed Guide shows your settings to be (press Ctrl+G in µTorrent)

200 global, 70 per torrent, 3 upload slots per torrent, 3 max active

Operating system installed (Windows XP, 2000, ME, 98, 95, NT? Something else?)

Windows XP SP2 - Patched TCP file to 50 connections

Security software installed (firewall, antivirus, antispyware, antiadware)

AntiVir Personal Edition Classic

Exact router model(s), and exact modem model

Prolink Hurricane 9300G

ISP (Internet Service Provider) being used

ISP - TM Net

Country - Malaysia

Connection type (DSL, cable, dial-up), and the results obtained from the speed test (when running the Speed Guide), for both download AND upload. Be sure that you aren't using your connection for any other reason besides testing, while testing. That means no downloading, no IMing, no µTorrent running, no browser activity (other than the testing), etc. Additionally, no other computer on your network (if any) should be using the connection.

Service - Streamyx 1MB ADSL - tested 800kbps

SLOW/INTERRUPTED INTERNET CONNECTION OR OFFLINE TRACKERS while µTorrent is running

Disable IP resolving in the Peers tab

Try disabling DHT (Can be found in Preferences > BitTorrent)

Try disabling UPnP (Can be found in Preferences > Connection)

Try lowering maximum global number of connections to 200? 100? 50? (Can be found in Preferences > BitTorrent)

Lower net.max_halfopen to 4 (Can be found in Preferences > Advanced)

Patched TCPIP.sys (Windows XP w/ SP2, Windows 2003 w/ SP1, or newer)? Windows Vista users can try this out, but no guarantees are made. Users not on Windows XP w/ SP2, Windows 2003 w/ SP1, Windows Vista, or newer can skip this step.

Did all of the above

Connect your computer directly to the modem to make sure the problem is not caused by the router

My router is also the modem.

Restart your computer, modem, and router after performing any of the above

Did this too.

[Ultima]

µTorrent doesn't need to keep increasing the number of sessions. If your session table isn't getting cleared, then it's your router's fault. My 2wire HomePortal 100 only handles 256 connections -- I still manage to use µTorrent on *2 computers* without issue.

[cmorbutt]

Damn ... The sessions summary for my router are as follows:

TCP : 1500 sessions, Default Timeout 1800 Seconds

UDP : 0 sessions, Default Timeout 120 Seconds

Others : 0 sessions, Default Timeout 60 Seconds

Total : 1500 sessions

What are the time outs for the sessions on your router?

I will be trying to find out more info from my Router's website/tech support but if anyone has any information regarding my router, any help would be greatly appreciated.

Router Details:

Brand - ProLink

Model - Hurricane 9300G

Hardware Version - Argon 432 ADSL-A/2/WG v1.00

Software Version - 5.07

Website - http://www.prolink2u.com/

I found an interesting article on the web:

http://www.tools.ietf.org/html/draft-sivakumar-behave-nat-tcp-req-00

3.3 Timeouts

NATs maintain different types of timeouts for the TCP sessions.

These timeouts apply to the different states of the TCP state

machine.

* The NAT's SYN timer has a relatively short timeout, and helps to

protect the NAT (and, potentially, the hosts behind the NAT) from SYN

flood attacks. The SYN timeout starts when the NAT observes the

first SYN on a new session, and is cancelled when the NAT receives an

ACK for that SYN from the opposite endpoint, indicating that

legitimate two-way communication is taking place.

* The NAT's session timer is a relatively long timeout, and ensures

that the NAT is eventually able to delete database entries for

formerly-active TCP sessions on which both endpoints have silently

ceased communication without either closing or resetting the

connection. The NAT's session timer starts when the TCP session

enters the active, "fully-open" state (typically at the same time its

SYN timer is cancelled), and the session timer MUST be reset whenever

the NAT observes an outbound packet from the internal realm to the

external realm. Inbound packets SHOULD NOT cause the NAT to reset

its session timer.

Sivakumar, et al. Expires August 1, 2005 [Page 4]

Internet-Draft NAT Behavioral Requirements for TCP January 2005

When the NAT's session timer expires, it SHOULD NOT immediately

delete its database entry for the session, since TCP sessions are

legitimately allowed to go idle for arbitrary lengths of time with no

exchanged traffic. Instead, the NAT SHOULD enter a special "probe"

state, in which it sends TCP keep-alive packets to the internal

endpoint, using the technique described in section 4.2.3.6 of [HOST],

in order to detect whether the internal endpoint still considers the

connection to be open. If the NAT receives an ACK or other traffic

from the internal endpoint, it resets the session timer and re-enters

the "active" state. If the NAT receives a RST from the internal

endpoint, it enters the "closed" state and starts the close timer as

described below. If the NAT receives no response from the internal

endpoint after sending several keep-alive packets, the NAT assumes

that the internal endpoint is dead and again enters the "closed"

state.

* The NAT's close timer is a relatively short timeout that ensures

that the ACKs for the final FINs on a gracefully-closed TCP session

have a chance to propagate in both directions, and also to allow time

for either endpoint to re-open a recently closed or reset TCP session

if desired. The NAT starts the close timer after it observes a FIN

packet in each direction, or after it observes an RST from either

endpoint. If a new SYN packet arrives from either endpoint before

the close timer expires, the NAT re-enters the active, "half-open"

state & re-starts the SYN timer as described above. Otherwise, once

the close timer expires the NAT is free to delete its database entry

and release all resources allocated to the session.

The following requirements apply to the NAT's timeouts:

A NAT MUST have a SYN timer so that the box is not prone to SYN

attacks. The SYN timeout value MUST be configurable, and SHOULD

default to at least 30 seconds and no more than 60 seconds.

A NAT MUST have a session timeout. The NAT's session timeout MUST be

configurable. The session timeout MUST by default be at least 60

minutes if the NAT uses TCP keep-alives to probe the session after

the session timeout expires, and the session timeout MUST by default

be atleast 120 minutes if the NAT just silently deletes the database

entry for the session after the session timeout expires.

A NAT MUST have a close timeout. NAT MAY have separate timeouts for

session close due to FIN versus RST. NAT's close timeouts MUST be at

least 2xMSL, or 60 seconds.

Found another article that is a little clearer:

http://www.brynosaurus.com/pub/net/internet-drafts/draft-sivakumar-behave-nat-tcp-req-01.txt

3.2 Timeouts for TCP NAT Sessions

As may be noted from [TCP], an end-to-end TCP session in its

lifetime goes through three phases, namely Connecting, Established,

and Closing. Each end-to-end TCP session is managed through a

separate NAT Session within NAT. The NAT Session must be capable of

identifying the current phase of the end-to-end TCP session it

represents and use an idle timeout period that is appropriate for

the current phase.

Connecting Phase: An end-to-end TCP session is said to enter the

Connecting Phase when either of the endpoints sends the first SYN

for the TCP session and exit the phase upon completion of 3-way SYN

handshake. The idle timeout used by the NAT Session during this

phase is called the SYN timeout. SYN timeout needs to be relatively

short, so NAT can protect itself (and, potentially, the hosts behind

it) from SYN flood attacks. A NAT session is freed when the SYN

timeout expires.

Established Phase: An end-to-end TCP session is said to enter the

Established Phase upon completion of 3-way handshake and exit the

phase upon seeing the first FIN or RST for the session. The idle

timeout used by the NAT during this phase of the end-to-end TCP

session is called the Session timeout. Session timeout needs to be

relatively long, so the NAT Session can retain state of the

end-to-end TCP Session within itself even after long periods of

inactivity in the session. Long periods of inactivity is not

uncommon with applications such as telnet and ftp. When Session

timer expires, the corresponding NAT Session may be freed (or) the

NAT Session may assume the TCP connection to have transitioned

into the Closing phase.

Closing Phase: An end-to-end TCP session is said to enter the

Closing Phase when either of the endpoitns sends the first FIN

or RST for the session. Alternately, the NAT Session may deem the

TCP session to have entered this phase when the TCP Session timer

expires. The idle timeout used by the NAT Session during this phase

is called the Close timeout. Close timeout is relatively short to

ensure that the ACKs for the final FINs on a gracefully-closed TCP

session had a chance to propagate in both directions, and to allow

time for either endpoint to re-open a recently closed or reset TCP

session if desired. A NAT device MAY opt to have different Close

timeouts depending upon whether the Closing phase is triggered by

FIN or not. Once the Close timer expires, the NAT Session will be

freed.

Srisuresh, et al. [Page 4]

Internet-Draft NAT Behavioral Requirements for TCP March 2005

The following requirements apply to the NAT's timeouts:

REQ-2: A NAT device MUST be capable of identifying the current phase

of an end-to-end TCP session and use different idle timeout periods

for each phase of the TCP Session. The timeouts used for each phase

SHOULD be admin configurable. The recommended value for SYN timeout

is 30 seconds. The recommended value for TCP session timeout is 30

minutes. Lastly, the recommended value for close timeout is 2 x MSL

(Maximum Segment Lifetime) or 4 minutes.

[Ultima]

I just got a WRT54GL today, so I don't have my old router on hand to check (though I don't recall it ever allowing me to configure the timeout period). In short, I don't know what the timeout period was for my old router.

For the WRT54GL (with the Tomato firmware installed), though, the timeouts look not all too dissimilar from your timeouts, and everything runs fine (I rarely hit more than 400 connections before the idle connections timeout).

[cmorbutt]

Tomato firmware? Is there a website with custom/hack firmware for routers? I wonder if they have a compatible firmware for my router. hmmm

I wonder why my sessions dont time out properly. If i turn off uTorrent, the number of sessions eventually drop to double digits. Its weird. I dont ever remember having this issue with this router before. Could it be corrupted firmware/hardware?

[Ultima]

http://www.polarcloud.com/tomato

Unfortunately, the Tomato firmware is only for the WRT54G* routers and just a few others, so it won't help you.

I'm not sure what to say about the connections not timing out... Corrupted firmware is possible, but improbable. Damaged hardware... I'd say the router's more likely to just not work if it were damaged than just the timeout feature being b0rked... :/

[cmorbutt]

Yeah, i'm just grasping at straws myself. Every other feature of the router works perfectly. Its quite a feature packed router and its default admin screens are pretty flexible with the configurations.

I sent an email to their tech support. Hopefully they can come back with something helpful. Its frustrating having so many sessions that clog up my router.

Could having multiple trackers be an issue? I am currently trying to download 3 torrents and each of those torrents have 5+ trackers listed. :/

[Switeck]

Your ISP I'm pretty sure is one of those really anti-BitTorrent ones. It probably breaks BT connections silently, resulting in your router "clogging up" with dead connections probably in under an hour.

If you get TCP view, you can see realtime just how much connection 'churn' you have ...with new connections being made in green and old ones being closed in red.

[cmorbutt]

That makes sense i guess. I've downloaded TCP View and ill take a look at what happens.

If i use forced encryption and disable incoming legacy connections, that should solve the problem, right?

[Switeck]

I don't know, there's so many hostile ways ISPs screw over BitTorrent that there's not a 1-size-fits-all solution.

Some ISPs do more than 1 method to mess up BitTorrent...they really hate their customers!

(Rogers ISP in Canada comes to mind.)

[cmorbutt]

You hit the nail right on the head. It was my damn ISP.

i've done the following:

- Disable incoming legacy connections

- Forced Encrpyption

- Disable DHT

- Blocked UDP Ports

TCP connections have dropped back to normal. No wonder things started becoming screwed up only recently. Stupid ISP.

Thanks for all the help guys. Will keep you guys updated if anything else comes up

Update:

Damnit! Spoke too soon. It didn't work. The NAT sessions maxed out again after a while. Going nuts trying everything. Deleted my settings.dat and now my webui doesn't work! :mad: