I have seen this happen, and I have one possible reason about this behavior (connecting for some time than impossible to connect) if:
- this does not come from your ISP: your connection is still working
- you can still browse the web and send emails or discuss on IRC
- all connection attempts fail
- you use an external DSL modem with connection sharing (embedding a Ethernet adapter or hub, or a WiFi adapter)
or a router with NAT, or connect via a PC acting as a connection sharing gateway
- you are running Windows XP SP2
Windows XP SP2 also monitors the number of target (non local) IP addresses that can be reached by TCP connections: this is monitored by the OS's IP driver, within its internal routing device as a feature of its builtin firewall. This mostly concerns users of Windows XP Home and Pro editions, but not the Server editions... I don't know if this is a default tuning that can be changed. But the only solution is to terminate the process (exit LimeWire completely, including its Java VM and the taskbar icon), wait for about one minute and restart.
Windows XP SP2 has put severe limitations on the number of DNS resolution requests that can be resolved by a client process (this is used as a tool to limit the broad connectivity of a possibly installed virus trying to send spam at large speed to lots of destination hosts). The impact is that the number of DNS resolutions per timeframe is limited, and above this limit, these requests will fail, and the limit will be automatically lowered. This limit cannot be reached when running LimeWire at startup, but cn be reached after about 2 hours of successfull connection, because the connected hosts that stay online for more than 1 minute will have their IP resolved by LimeWire into hostnames. However, if your servent has run successfully for more than 1 hour, it may become a Ultrapeer candidate, and then then will start accepting remote leaf connections. The problem is that the rate of incomming connection attempts cannot be controled, and remote leaf nodes will frequently connect and disconnect.
In the past, all connected hosts were resolved to hostnames, but now this resolution will not happen before at least 1 minute of successfull connection. Given that a typical Ultrapeer will accept about 30 leaf nodes, this has the effect of putting a maximum to the number of DNS resolutions performed by LimeWire.
LimeWire has also been modified to not resolve IP to hostnames if the Connection pane is not visible.
Another problem is that Java, used in LimeWire, incorrectly implements the DNS specification, caching *for ever* the DNS results (Sun says this is part of an anti-spoofing security feature, but this is not satisfactory, and contradicts the RFCs. The impact is that the builtin Java DNS client will store obsolete records, and this includes many records related to IP or hostnames that are dynamically assigned to termporarily connected hosts, such as most connections provided by ISPs and used by home users.
Tip: LimeWire has recently been modified to not use the Java builtin DNS client, which also uses internally the local DN client provided by the OS, and it now includes a separate implementation of a conforming caching DNS client (where records will expire according to DNS protocol requirements). One problem is that Windows XP SP2 will not let LimeWire create itself connections to external DNS servers, unless the builtin XP firewall is configured to let LimeWire perform such Internet accesses (the DNS is a critical shared resource of the Internet).
But your ISP may also have set severe limitations to the number of DNS requests that can be satisfied by its customers. This is because the DNS server that your ISP connection uses is typically shared by all customers of that ISP, and the ISP's DNS server needs to be able to serve all customers equally and is necessarily limited. Some ISPs are also using this feature to detect automatically the customers that are infected by DDoS-like worms, or running P2P clients: when this limit is reached, the customer connection is reconfigured to limit more severely the number of DNS requests that can be satisifed. This has the benefit that the ISP can effectively reduce the success of DDoS worms or spamwares, and this also saves lots of bandwidth used by these worms. But some ISPs are logging those customers and will list them for analysis by external tools (including providing the list to third parties that have contracted with the ISP to monitor the legality of files shared on P2P networks). These logs can also be kept for legal purpose, but this is not possible legally in all countries. Apparently, such logging is now required in US and in all 25 countries in the E.U. that have applied the European directives.
If this is the case for you, there are two solutions:
(1) install a local caching DNS server with large enough caches, then connect this local DNS server to the ISP's server, configuring it so that it will make sure not to make too frequent resolution requests to the ISP, then configure your host to use this local DNS server instead. This is complicate for most users.
(2) close the "Connections" pane in LimeWire: LimeWire will not attempt to resolve all remote IP addresses to hostnames. But LimeWire will still need to connect sometimes to Gwebcaches, using the URLs that need to be resolved with DNS: this event will occur much more rarely now than with past versions, since now LimeWire prefers a much better alternative with UDP host caches. (If your servent was connected successfully for more than 1 hour and has become an Ultrapeer, LimeWire will not need to perform any access to GWebcaches, as its local pool of known remote hosts will be constantly filled with fresh addresses, and should not be exhausted.)
But the problem may be elsewhere: if you have a local firewall software (not the builtin Windows XP firewall), this firewall may be configured to resolve ALL incoming TCP connections for logging purpose. Consider changing the setting of this local firewall so that it will not perform this costly resolution. Such function is normally performed in offline mode when parsing webserver logs, or should be enabled ONLY if you have a *true* local DNS server with enough caching (the builtin DNS client in Windows XP has a cache but it is too much limited to work correctly for applications that will connect with lots of distinct Internet hosts).
Same thing if you have an external router: some routers will also attempt to perform DNS resolution for ANY application running on LAN, and will immediately try to cache locally the result of this resolution. This occurs if the builtin DNS proxy is enabled in the router, and your hosts on the LAN are configured to use the DNS server address of the router. The problem is that most builtin DNS procies in hardware routers have too much limited memory to cache enough DNS records, and so these records must be discarded with a LRU strategy, long before the recommanded caching time indicated by the remote DN server (which should be about 24 hours for permanent web servers, or about 1 hour for DNS resolutions of ISP-provided hosts with dynamic IP).
The solution is then to disable this DNS proxy in your router, and configure the router's builtin DHCP server so that it will not distribute its own address for the DNS, but the address of your ISP's DNS server. This hardware router's builtin DNS proxy may also be configured to work in non caching mode (if this setting is possible), so that your hosts on the LAN will continue to use it in "plug'n play" mode using the router's address provided by its builtin DHCP server.
If your router does not have DHCP, or if you can't change its settings, you'll need to manually configure your local host to not use the DNS server address provided by DHCP, but to configure manually your host with the IP address of your ISP's DNS server(s). This should also sove the problem caused by a local firewall software that monitors and resolveds all the Internet connections performed by your local applications, to detect and block known malicious hosts in their "blacklist".
But the most tricky cases come if you are running your servent on a host connected via a shared enterprise or university network: whatever you can do in your host, they control and monitor your activity, and provide you a limited access to the Internet, and should have given to you a usage policy that you must respect. LimeWire cannot do anything for these cases if your connection fails because of this external monitoring, for networks accesses that you don't own yourself... Some solutions may be possible sometimes, for example by using some other publicly accessible DNS servers available on the Internet (but you should care about the fact that those external DNS servers may not be trustful, and may redirect your internet accesses to advertizers, or modified versions of wellknown search engines like Google...). I won't recommand using such untrustable third party services, even if they are, illegitimately, called "internet accelerators"...
Note that some ISPs propose you such "internet accelerators" as a builtin feature: they will act as "transparent" proxies and will deliver you cached webpages (for faster accesses) with compressed data (useful for slow modem connections):
- AOL modem accesses for example causes such troubles, and the best you can do if you use P2P applications is to avoid AOL and seek for another ISP.
- Wanadoo's optional (subscribed and payed option) "internet accelerator" feature causes such troubles. The utility of such subscription is very questionable, given the interoperability problems it can cause, even if it successfully accelerate your experience for classical web browsing.
Finally, there's a problem that is specific to Windows XP SP2: it sometimes does not detect that the Internet connection has been shutdown and restarted on your external router, and its TCP/IP internal stack continues to use obsolete information, or sometimes Windows XP continues to use obsolete DHCP leases that have expired in the DHCP server of your router. The symptoms is that you can't perform any web activity (getting emails, browsing the web, all fails with "host not found" errors).
Sometimes this can be solved by disabling the NIC interface and reenabling it. But this sometimes fails too: the dialog box that appears when "repairing" the connection never terminates, and can't be closed even if you press the "Cancel" button (using the "Repair connection" fails for obscure reasons, as the local DHCP client in Windows XP is blocked in an internal thread waiting for some unknown event that will never occur). Even if you unplug the Ethernet cable, Windows XP will not detect this event, and the connection will remain "active" and the network icon in the status bar will not show the red-cross.
The only solution is to reboot; this looks like a bug in Windows XP SP2's builtin firewall, caused by mutual dependencies of various internal network services, causing some deadlocks when one of these service should be unlocked to fail immediately... This bug may also come from your antivirus tool that does not monitor some Windows XP events informing it that the IP connection state was reset: check that your antivirus tool is updated to work correctly with Windows XP SP2 builtin firewall (this builtin firewall informs applications via some intenal hooks that your antivirus still does not implement, or via new UPnP or SNMP events that your antivirus still does not implement, or that can only be caught if the antivirus is configured and updated with the privileges of a local administrator account).
One solution, if you already have a third-party firewall solution, is to disable the Windows XP builtin firewall, and its related features (the new "Security Center" that displays a yellow or red shild icon, and that performs automatic Windows Updates, when you are online). Get sure then to perform Windows Updates regularly (most of them are published on Tuesday by Microsoft, so if you check them once a week on Wednesday, you should be OK with security patches). |