"connection timed out" problem

I am having a problem with "connection timed out" and it's driving me nutz! I tried asking over in the w2k group but didn't get much help. So I thought I might try the brains that reside here.

It's a new win2k setup with dialup access to the net.

It affects all my programs that access the net - netscape, firefox, thunderbird, xnews, mailwasher....most of which I used on my old system with no problems.

It sometimes acts like it's just too many connections. On my older system, I could load a set of 10 browser tabs at once. Yes, it was slow, but it loaded. Now, some of the sites come back timed out, and those that do load may be missing several images.

Alternatively there are times when I'm simply downloading one file (getright or firefox) and I go to load a simple webpage and I get timed out. The timeout happens in seconds, usually instantly.

Another weird example is loading a website that has advertising. While the page loads, one or more of the ads will show the browsers "connection timed out" error while the rest of the page is still loading. This happens if all I am doing is loading just that one page.

I've used ethereal to examine traffic and I'm noticing two things.

One is that when this happens there's a lot of "ICMP destination unreachable". This always comes on the heals of a "DNS query response" and is being sent by my machine to the DNS server. I mean, it's at the same time to the microsecond. When things run successfully, I may see one or two of these. But when things fail, they come in droves.

Second, using the above example of downloading a file and then trying to load a webpage, it appears the request doesn't even go out. The GET commands never show up in the packets. The web page times out instantly.

I was having problems with my modem anyway, so I changed to my old tried and true USR 56k sportster. No change. (other than the problem the 'new' modem was having - dropped connections from connecting too fast for the noise level on the line)

I have tried different modem drivers. No change. (btw, the modem is known good, having been used on several computers previously)

I did find I forgot to set my DNS servers, but setting this had no effect.

I thought it might be my antivirus, so I uninstalled it. No change.

I thought it might be my firewall (Kerio 4.0). I reluctantly disabled it for a minute and still had the problem.

I've even looked around the registry but nothing obvious seemed to pop up.

All my googling keeps coming up with solutions to specific programs. This is affecting everything, so it's got to be something system level. Heck, it even affects PINGing from a command prompt.

I'm just plain baffled. There's very little here that's new. The modem, OS, and most of the software were used on the old machine. Normally I know what I am doing or can figure it out. This one has had me stumped for weeks now.

Any ideas would be much appreciated.

Brian

Reply to
Skywise
Loading thread data ...

Disabling doesn't disable the driver invocation, you really need to uninstall it. And better not reinstall that crap or any alternative crap.

A broken thing breaks randomly.

Reply to
Sebastian Gottschalk

Sebastian Gottschalk wrote in news:4966nbFn7ooeU1 @news.dfncis.de:

Are you saying that Kerio is crap?

And by "alternative crap" do you mean firewalls in general?

Sorry, your post is most unhelpful. I need solutions to a problem. Not personal opinions about which firewalls are crap and which are gold.

Brian

Reply to
Skywise

The clue is shown - don't know why no one is wagging the finger at it.

OK - let's stop RIGHT THERE. The normal sequence is you send a UDP query to "a" name server - usually the first one listed in "ipconfig /all". The source port number on _your_ system will be some number above 1025, and the destination port number on the server will be 53. Anywhere from a few milliseconds to ten or twenty seconds later, that server should respond from it's UDP 53 to the UDP port number you used to initiate the exchange. If the first server listed did not respond in a short period (the UNIX standard is five seconds), your system may send a similar query from a different port number to the "second" name server listed repeating the try. If there is a third name server listed (generally the maximum allowed), a query may go out to it five seconds after the one to the second server. All of this assumes there is a network path to those name servers.

What appears to be happening here is that you have some firewall function running that is blocking these responses, and telling the name server to go fsck off. This could be because you have an explicit rule somewhere that identifies the name servers as bad guys. A more common problem with the typical "personal firewall" is that it's set with tight timing - such that if the response from the name server is delayed for more than a small amount of time (perhaps a second or two), the "personal firewall" forgets about the request, and assumes the response when it finally comes is unsolicited. There might be a tuning parameter in the firewall - I wouldn't know as I don't use windoze, never mind these so-called "personal firewalls".

Yes - because your O/S doesn't know where to send the GET command - it can't find the IP address of the remote web server. (Hostnames are for the convenience of humans - computers use IP addresses.)

Not a hardware problem.

Real modems don't use drivers - but this isn't a modem problem.

Sounds as if your ISP is setting them for you over the modem line using RFC2153.

Unlikely in the extreme

None the less, that's probably the problem.

I don't do windoze. However, are you also using some OTHER anti-malware such as anti-trojans, anti-spyware, etc - all the extra crap I don't need to worry about?

It's actually only at the network level - but that is so blurred in windoze you can't tell the difference.

Old guy

Reply to
Moe Trin

snipped-for-privacy@painkiller.example.tld (Moe Trin) wrote in news: snipped-for-privacy@compton.phx.az.us:

No. The most I ever do is firewall and A/V. And right now, the A/V is gone.

I've used this firewall on other machines with no problem. Being on a new machine there's not many rules setup yet. I've looked aroudn in it's settings but didn't notice anything that might do this.

I suppose it could just be a flakey install, to which reinstalling may fix.

Thanks for the input.

Brian

Reply to
Skywise

Yes.

so-called "personal firewalls"

I told you the solution. Kerio and many other PFWs are well known to omit such an errornous behaviour even when disabled. Uninstallation usually solves the problem.

This is not about opinions, these are just simple facts.

Reply to
Sebastian Gottschalk

Sebastian Gottschalk wrote in news:498i3lFmdccfU2 @news.dfncis.de:

Ok...I'll add my own facts. I just uninstalled the firewall and risked going online without it. No change. So at least in my case, the PFW is not the problem. Next idea?

Brian

Reply to
Skywise

Skywise wrote in news: snipped-for-privacy@corp.supernews.com:

OK...uninstalled the firewall and went online. Still had the same problems.

I'm really thinking there's some sort of "system level" problem. Something in Windows' networking settings. Oh, and in case it wasn't clear before, this is a dial up connection.

Brian

Reply to
Skywise

Why should that be a risk?

Better said: If your security depends on that packet filter, your concept has a bring problem that cannot be solved by that packet filter. Host security is important as well.

Did you check whether the driver was actually uninstalled? I've seen these uninstallers fail too often.

At least you can exclude this common source of error now.

Next checks:

- flushing the dnscache (ipconfig /flushdns)

- net stop DnsCache & net start DnsCache

- did you change some of the values in HKLM\\SYSTEM\\CCS\\Services\\TcpIp\\Parameters by a tuning tool or alike?

- does netstat or TcpView omit something about how long Windows is waiting for the DNS reply?

Reply to
Sebastian Gottschalk

Yeah, I'm a *nix network administrator - I work with this stuff all the time. Hope it made sense to you.

None the less, your description of the failure does indicate a firewall problem of some kind. Re- the description I gave up-thread: Your system asked the DNS server to translate name to IP. Note the exact time this occurs. Then note the exact time that that server replies (match up port numbers to see which reply is which). Then note the exact time of the ICMP Port Unreachable. If you can see inside that ICMP packet, it has the addresses and port numbers (it actually has at least the IP header of 20+ bytes and the first 8 bytes of the datagram which would in this case be the entire UDP header). What I'm guessing is that the name server is slow (say more than a second - perhaps more than five seconds), and the firewall code is rejecting it.

I don't do windoze, but my understanding is that should have made things work. Reinstall the firewall - I don't want you getting cracked because it's missing now.

I'm making an assumption by your use of ethereal that you would have noticed that the packets are actually using the right interface. Some of the anti-malware stuff has been known to stick hostnames into the hosts file (I dunno - c:\\windoze\\hosts or c:\\winnt\\system32\\drivers\\hosts) with a

127.0.0.1 address to block access to those remote systems.

OK - a dialup means you'll get a new IP address every time you dial in, so your posting the output of "ipconfig /all" isn't going to expose you to anything - you won't be using that address for a while. What I'd be looking at is that the name servers (at least one, maybe up to three IP addresses) are real name servers. (I just hope your ISP isn't using RFC1918 addresses, as noone but them can make sense of them in that case.) As far as the difference between dialup verses cable or a hardwired Ethernet in the office

- the name server assignment mechanism _may_ be slightly different, but once you have the addresses where your O/S can use them (either by setting them manually or through some automagic means) there is absolutely no differences.

Old guy

Reply to
Moe Trin

Sebastian Gottschalk wrote in news:498r39FnmdujU1 @news.dfncis.de:

I can retry the test and check for that.

These didn't seem to have any effect.

No tuning tools. But one thing I ran across while trying to solve this problem was to add the DWORD "MTU" (maximum transmission unit) and set it to 576 as recommended for dial up connections. ISTR needing to do this some years ago on a previous computer. But, it didn't have any effect on my current problem.

In searching for info on this key's definition, I've run across some other interesting keys that may be relevant. From the info I'm finding on the MS knowledge base, it appears these keys are not at their default values, or missing altogether. Specifically,

under HKLM\\SYSTEM\\CCS\\Services\\TcpIp\\Parameters TcpMaxConnectRetransmissions is set to 0, default is 2 TcpMaxDataRetransmissions is missing InitialRtt is also missing

under HKLM\\SYSTEM\\CCS\\Services\\TcpIp\\Parameters\\Interfaces\\{id} TCPInitialRtt is missing

Are you familiar with any of these?

Oh, and in case it's important, this is a W2KPro SP4 setup.

I've just downloaded TCPView....what exactly should I be looking for?

BTW, thanks for the help. I actually enjoy this kind of trouleshooting as I always learn something new. And I'm one of those who learns by "I wonder what would happen if I...." :)

Brian

Reply to
Skywise

snipped-for-privacy@painkiller.example.tld (Moe Trin) wrote in news: snipped-for-privacy@compton.phx.az.us:

After reading your dissertation earlier I looked closely at some captured packets. I understood what you were describing and could easily see how it was working.

Here's a summarized example from a typical capture showing just the DNS stuff:

time source ip port dest. ip port proto info

18:36:27.953125 66.159.232.77 1272 66.51.205.100 53 DNS
formatting link
18:36:28.953125 66.159.232.77 1272 66.51.206.100 53 DNS
formatting link
18:36:29.546875 66.51.205.100 53 66.159.232.77 1272 DNS 128.95.166.129 18:36:30.437500 66.51.206.100 53 66.159.232.77 1272 DNS 128.95.166.129 18:36:30.437500 66.159.232.77 53 66.51.206.100 1272 ICMP Unreachable

In typing this out, I see that my system goes to the first DNS, then

1 second later goes to the second. I get the reply to the first DNS less than two seconds after the request, and the second replay is also received less than two seconds after the request, but is immediately folowed with the "destination unreachable".

Should not the system be waiting longer than 1 second before going to the second DNS? This may be related to some non-default and missing registry keys that I mentioned in my post to Sebastion.

My hosts file only contains one entry,

127.0.0.1 localhost

Windows 2000 IP Configuration

Host Name . . . . . . . . . . . . : heart-of-gold-6 Primary DNS Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Broadcast IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

Media State . . . . . . . . . . . : Cable Disconnected Description . . . . . . . . . . . : Linksys LNE100TX(v5) Fast Ethernet Adapter Physical Address. . . . . . . . . : 00-04-5A-72-72-90

PPP adapter DSL Extreme - Cypress:

Connection-specific DNS Suffix . : Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface Physical Address. . . . . . . . . : 00-53-45-00-00-00 DHCP Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 66.159.232.77 Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : 66.159.232.77 DNS Servers . . . . . . . . . . . : 66.51.205.100 66.51.206.100 NetBIOS over Tcpip. . . . . . . . : Disabled

The DNS servers were set by me in TCP/IP setup and are those specified by my ISP.

BTW, have you been following my convo with Sebastian?

Brian

Reply to
Skywise

Skywise wrote in news:122ujs4erqgrd68 @corp.supernews.com:

Replying to myself...

I reset the above key to the default value and things have improved. Still not as good as my previous system, but still, much better.

Brian

Reply to
Skywise

default is 5, my recommendation is 3, but only set to 0 could cause serious problems

no problem

no problem either

System:0 (TIME_WAIT) svchost:some high port (dnscache service going nuts?) anything:domain (some other app stealing your DNS replies)

BTW, what about stopping the DnsCache service? In contrast to the description, DNS resolving works without it.

Reply to
Sebastian Gottschalk

;-)

DNS is like a lot of networking, fairly simple once you know what you are looking at.

OK - quick check here:

[compton ~]$ host 66.51.205.100 66.51.206.100 Using domain server 66.51.206.100: 100.205.51.66.IN-ADDR.ARPA domain name pointer dns1.dslextreme.com [compton ~]$ host 66.51.206.100 66.51.205.100 Using domain server 66.51.205.100: 100.206.51.66.IN-ADDR.ARPA domain name pointer dns2.dslextreme.com [compton ~]$

Those are working names servers, and the responses are nice and quick. This is not surprising given that they each should know the data that I'm asking for.

Yeah, microsoft and it's slip-shod networking concepts. A better design that's been used by other O/S since the late 1980s is to separate those two queries so that they originate on different ports - example 1272 and

1273 rather than both on the same one. What's happening here is that the first reply is accepted, and now that we have our answer, we're closing the port - and your O/S, NOT THE FIREWALL is doing the ICMP Unreachable. The way everyone else does it is that the queries originate from different ports, and the first reply would reach the first port, while the second would be sent to the second port without being effected by the first. It would be a separate transaction (or conversation). Within the resolver (that's actually what is asking the DNS servers), the second reply would be ignored.

Well.... RFC1034 allows the queries to be in parallel, and doesn't specify the time between the queries, although paragraph 5.3.3 warns against "to aggressive a retransmission" but doesn't put a specific number on it. Paragraph 5.1 states that replies can take "from milliseconds to several seconds", and I actually remember seeing some site in South Bumfsck take about five seconds to resolve. That could have been the result of a Denial of Service attack, but it _does_ happen. In the cut you show, this appears to be a host in the LA Basin asking servers in the same general area about a host near Seattle. The answer is actually a CNAME (nic-name), but a query here is taking around a third of a second. This probably suggests your ISP nameservers are loaded somewhat, and the pipes they are using are slow. Not much you can do about that.

As I mention, I don't do windoze, but I would hope there is a tweak or adjustment that would increase the retransmission time. One second is way to short. That might be OK on a LAN, but is going to run into problems on the Internet.

OK - that was a slim chance anyway.

Ah, the usual microsoft lies - but other than that I don't see anything out of place here.

They look fine. From out here, I'm referred to two other servers (ns1.dslextreme.com at 66.51.199.60 and ns2.dslextreme.com at 66.51.206.102) but it's fairly common for ISPs to have separate nameservers for customers verses those used by the world. One of my ISPs actually goes so far as to use RFC1918 addresses (192.168.2.xx) for the customers to keep the general public from hogging the bandwidth.

Up to my post last night, there wasn't anything useful to me. Looking at this post, this _suggests_ that you have some form of windoze setup problems rather than a firewall problem. In the packet capture above, you do receive the answer from the first name server, and that _should_ allow your application to request service from the remote server. It might be slower than desired (by a second or two), but everything should work.

As mentioned, I really don't do windoze. I stopped using microsoft in

1992, before they invented networking (or what-ever) so the internals and registry tweaks are totally lost on me. I do see that you found the retransmission key and that seems to be improving things. For what it's worth, the industry standard as found in the C resolver library header files is [compton ~]$ grep RES_TIMEOUT /usr/include/resolv.h #define RES_TIMEOUT 5 /* min. seconds between retries */ [compton ~]$

No, I don't have that variable memorized (though I knew it's value), and that's the default which is rarely changed.

Ah, in your 04:13:56 reply (Message-ID: of 75 lines), you state:

An MTU of 576 was set back in the old days of 19200 BPS modems to allow a command echo at a reasonable rate - think "telnet" where what you typed as commands were actually echoed back to your screen from the remote server. The "reasonable time" is around a quarter second. Your modem is undoubtedly faster than 19.2, and most ppp implementations default to an MTU of 1500. Setting the MTU (actually the MRU - Received) can cause problems where ICMP is blocked between you and the server. See RFC2923 - briefly, the server tries to send large (1500 byte) packets with a Don't Fragment flag set in the headers (for speed). When that packet reaches a pipe with a smaller MTU, the router tries to send back an error message to the server (ICMP Type 3 Code 4 - "ten pounds don't fit in a five pound bag"). If that error message gets dropped, the server never gets the word to reduce the packet size, and the connection is broken.

Old guy

Reply to
Moe Trin

Sebastian Gottschalk wrote in news:499vkdFnm76uU1 @news.dfncis.de:

I'm at 2 right now and it's helped. I'll try 3 at my next reboot.

Actually, today, I have had NO problems at all. I wonder if this one setting was the cause of all my problems.

BTW, is there a way to read the registry from another install? That is, I have as a secondary drive a working W2k install from my older machine that died. I'd be curious to see what it's setting for this value was.

TIME_WAIT only appears briefly when I'm actually doing stuff.

There's only one svchost listed, and it's listening to my own machine.

I'll try this on a future reboot as well.

I only try one thing at a time to keep from confounding myself.

Brian

Reply to
Skywise

snipped-for-privacy@painkiller.example.tld (Moe Trin) wrote in news: snipped-for-privacy@compton.phx.az.us:

So, do you recommend getting rid of this setting? I do have a 56k modem. Would have DSL if I wasn't so far from the switch.

As an aside, I went back to my older modem as I can use a command string to set its max connect speed. My newer modem is missing those commands and therefore it connects too fast for the line noise, and therefore it kept dropping connections.

If it weren't for my days BBSing I wouldn't have even known about those settings.

Brian

Reply to
Skywise

directly: Copy over the approciate files in Recovery Console indirectly, for copying entries: navigate to HKLM or HKU, File, Load Hive, [select the registry file], Name: [whatever], OK. This will mount the according hive in a subkey, just like the standard hives are (f.e. SYSTEM hive is mounted at HKLM\\SYSTEM)

No need to reboot for that.

Reply to
Sebastian Gottschalk

I would, yes. We've come a long way since these protocols were introduced and I've actually got a very respected college text book (TCP/IP Illustrated Volume 1 by W. Richard Stevens, ISBN 0-201-63346-9 from Addison Wesley) that talks about setting it to 296 to cater for the 9600 BPS modems. In fact, I've been using the default (1500) for at least 8 years without problems. And, I have seen a LOT of complaints about PMTU Discovery problems (the RFC2923 document I referred to).

I dunno - it reaches out pretty far now.

Did you mention... no. You might do a google search for the specific modem - and look through the archives of comp.dcom.modems to see if anyone has a hint about tweaking it.

Yeah, even Hayes doesn't follow the Hayes command standards, and when you get to the extended commands, all bets are off.

Old guy

Reply to
Moe Trin

The worst thing about Windows is that by default PMTUD is enabled, but blackhole router detection is disabled. Enabling it solves a lot of PMTUD related problems.

Usually the initial connection negotiates the line parameters pretty well, so you should normally not encounter any drops through noticeably decreasing line quality. Actually 56K is even more robust in this way.

Reply to
Sebastian Gottschalk

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.