cmorbutt Posted May 23, 2007 Report Share Posted May 23, 2007 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)greenWhat the port checker from the Speed Guide writesPort is openWhat 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 activeOperating system installed (Windows XP, 2000, ME, 98, 95, NT? Something else?)Windows XP SP2 - Patched TCP file to 50 connectionsSecurity software installed (firewall, antivirus, antispyware, antiadware)AntiVir Personal Edition ClassicExact router model(s), and exact modem modelProlink Hurricane 9300GISP (Internet Service Provider) being usedISP - TM NetCountry - MalaysiaConnection 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 800kbpsSLOW/INTERRUPTED INTERNET CONNECTION OR OFFLINE TRACKERS while µTorrent is runningDisable IP resolving in the Peers tabTry 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 aboveConnect your computer directly to the modem to make sure the problem is not caused by the routerMy router is also the modem.Restart your computer, modem, and router after performing any of the aboveDid this too. Link to comment Share on other sites More sharing options...
Ultima Posted May 23, 2007 Report Share Posted May 23, 2007 µ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. Link to comment Share on other sites More sharing options...
cmorbutt Posted May 24, 2007 Author Report Share Posted May 24, 2007 Damn ... The sessions summary for my router are as follows: TCP : 1500 sessions, Default Timeout 1800 Seconds UDP : 0 sessions, Default Timeout 120 SecondsOthers : 0 sessions, Default Timeout 60 Seconds Total : 1500 sessionsWhat 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 - ProLinkModel - 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-003.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.txt3.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. Link to comment Share on other sites More sharing options...
Ultima Posted May 24, 2007 Report Share Posted May 24, 2007 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). Link to comment Share on other sites More sharing options...
cmorbutt Posted May 24, 2007 Author Report Share Posted May 24, 2007 Tomato firmware? Is there a website with custom/hack firmware for routers? I wonder if they have a compatible firmware for my router. hmmmI 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? Link to comment Share on other sites More sharing options...
Ultima Posted May 24, 2007 Report Share Posted May 24, 2007 http://www.polarcloud.com/tomatoUnfortunately, 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... :/ Link to comment Share on other sites More sharing options...
cmorbutt Posted May 24, 2007 Author Report Share Posted May 24, 2007 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. :/ Link to comment Share on other sites More sharing options...
Switeck Posted May 24, 2007 Report Share Posted May 24, 2007 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. Link to comment Share on other sites More sharing options...
cmorbutt Posted May 24, 2007 Author Report Share Posted May 24, 2007 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? Link to comment Share on other sites More sharing options...
Switeck Posted May 24, 2007 Report Share Posted May 24, 2007 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.) Link to comment Share on other sites More sharing options...
cmorbutt Posted May 24, 2007 Author Report Share Posted May 24, 2007 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 PortsTCP 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 upUpdate: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: Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.