Disney's 0-timer fix?!?

[Growlur]

Was checking my netstat connections to be sure I'd complete shut off my P2P connections, and just happened to notice:

TCP hippos:4026 199.181.133.82:http TIME_WAIT
TCP hippos:4028 199.181.133.82:http TIME_WAIT
TCP hippos:4029 199.181.133.82:http TIME_WAIT
TCP hippos:4030 199.181.133.82:http TIME_WAIT
TCP hippos:4034 63.70.44.93:https TIME_WAIT
TCP hippos:4035 63.70.44.93:http ESTABLISHE
TCP hippos:4036 63.70.44.93:http ESTABLISHE
TCP hippos:4037 199.181.133.82:http TIME_WAIT
TCP hippos:4039 199.181.133.82:http TIME_WAIT
TCP hippos:4040 199.181.135.29:http TIME_WAIT
TCP hippos:4041 199.181.133.82:http TIME_WAIT
TCP hippos:4042 199.181.133.82:http TIME_WAIT
TCP hippos:4045 199.181.133.82:http TIME_WAIT
TCP hippos:4046 199.181.133.82:http TIME_WAIT
TCP hippos:4047 199.181.133.82:http TIME_WAIT
TCP hippos:4048 199.181.133.82:http TIME_WAIT
TCP hippos:4049 199.181.133.82:http TIME_WAIT
TCP hippos:4050 199.181.133.82:http TIME_WAIT
TCP hippos:4051 199.181.133.82:http TIME_WAIT
TCP hippos:4052 199.181.133.82:http TIME_WAIT
TCP hippos:4053 199.181.133.82:http TIME_WAIT
TCP hippos:4054 199.181.133.82:http TIME_WAIT
TCP hippos:4058 199.181.133.82:https TIME_WAIT
TCP hippos:4061 199.181.133.82:https TIME_WAIT
TCP hippos:4063 199.181.133.82:https TIME_WAIT
TCP hippos:4064 199.181.133.82:https TIME_WAIT
TCP hippos:4065 199.181.133.82:https TIME_WAIT
TCP hippos:4066 199.181.133.82:https TIME_WAIT
TCP hippos:4067 199.181.133.82:https TIME_WAIT
TCP hippos:4068 199.181.133.82:https TIME_WAIT
TCP hippos:4069 199.181.133.82:https TIME_WAIT
TCP hippos:4070 199.181.133.82:https TIME_WAIT
TCP hippos:4071 199.181.133.82:https TIME_WAIT
TCP hippos:4072 199.181.133.82:https TIME_WAIT
TCP hippos:4073 199.181.133.82:https TIME_WAIT
TCP hippos:4074 199.181.133.82:https TIME_WAIT
TCP hippos:4075 199.181.133.82:https TIME_WAIT
TCP hippos:4076 199.181.133.82:https TIME_WAIT
TCP hippos:4077 199.181.133.82:https TIME_WAIT
TCP hippos:4078 199.181.133.82:https TIME_WAIT
TCP hippos:4079 199.181.133.82:https TIME_WAIT
TCP hippos:4080 199.181.133.82:https TIME_WAIT
TCP hippos:4081 199.181.133.82:https TIME_WAIT
TCP hippos:4082 199.181.133.82:https TIME_WAIT
TCP hippos:4084 199.181.133.82:https TIME_WAIT
TCP hippos:4089 199.181.135.29:http TIME_WAIT
TCP hippos:4090 199.181.133.82:http TIME_WAIT
TCP hippos:4091 199.181.133.82:http TIME_WAIT
TCP hippos:4093 199.181.133.82:http TIME_WAIT
TCP hippos:4094 199.181.133.82:http TIME_WAIT
TCP hippos:4097 199.181.133.82:http TIME_WAIT
TCP hippos:4098 199.181.133.82:http TIME_WAIT
TCP hippos:4099 199.181.133.82:http TIME_WAIT
TCP hippos:4102 199.181.133.82:http TIME_WAIT
TCP hippos:4103 199.181.133.82:http TIME_WAIT
TCP hippos:4104 199.181.133.82:http TIME_WAIT
TCP hippos:4105 199.181.133.82:http TIME_WAIT
TCP hippos:4106 199.181.133.82:http TIME_WAIT
TCP hippos:4107 199.181.133.82:http TIME_WAIT
TCP hippos:4108 199.181.133.82:http TIME_WAIT
TCP hippos:4109 199.181.133.82:http TIME_WAIT
TCP hippos:4110 199.181.133.82:http TIME_WAIT
TCP hippos:4111 199.181.133.82:http TIME_WAIT
TCP hippos:4112 199.181.133.82:http TIME_WAIT
TCP hippos:4113 199.181.133.82:http TIME_WAIT
TCP hippos:4114 199.181.133.82:http TIME_WAIT
TCP hippos:4115 199.181.133.82:http TIME_WAIT
TCP hippos:4120 199.181.133.82:http TIME_WAIT
TCP hippos:4121 199.181.133.82:http TIME_WAIT
TCP hippos:4122 199.181.133.82:http CLOSE_WAIT

Naturally, I was a bit concerned that this IP was port scanning me to find a way in, so I thought I'd run a report on the IP and:

Report for 199.181.133.82

Analysis: '199.181.133.82' was found in 10 hops (TTL=246).

----------------------------------------------------------------------------------------------------------------------------------------------------------
| Hop | %Loss | IP Address | Node Name | Location | Tzone | ms | Graph | Network |
----------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | | 161.58.180.113 | win10115.iad.dn.net | Dulles, VA, USA | -05:00 | | | Verio, Inc. VRIO-161-058 |
| 1 | | 161.58.176.129 | - | ... | | 0 | x | Verio, Inc. VRIO-161-058 |
| 2 | | 161.58.156.140 | - | ... | | 0 | x | Verio, Inc. VRIO-161-058 |
| 3 | | 129.250.28.206 | xe-1-2-0-3.r20.asbnva01.us.bb.verio.net | Ashburn, VA, USA | -05:00 | 0 | x | Verio, Inc. VRIO-129-250 |
| 4 | | 129.250.2.35 | p64-0-0-0.r21.asbnva01.us.bb.verio.net | Ashburn, VA, USA | -05:00 | 0 | x | Verio, Inc. VRIO-129-250 |
| 5 | | 129.250.5.98 | p16-0-1-1.r21.nycmny01.us.bb.verio.net | New York, NY, USA | -05:00 | 0 | x- | Verio, Inc. VRIO-129-250 |
| 6 | | 129.250.4.107 | p16-1-1-2.r20.sttlwa01.us.bb.verio.net | Seattle, WA, USA | -08:00 | 78 | x | Verio, Inc. VRIO-129-250 |
| 7 | | 129.250.28.10 | ge-0-1-0.r05.sttlwa01.us.ra.verio.net | Seattle, WA, USA | -08:00 | 78 | x | Verio, Inc. VRIO-129-250 |
| 8 | | 198.104.203.86 | ge-1-1-0.a05.sttlwa01.us.ce.verio.net | Seattle, WA, USA | -08:00 | 78 | x | Verio, Inc. VRIO-198-104 |
| 9 | | 10.193.255.19 | - | ... | | 79 | x-- | (private use) |
| 10 | | 199.181.133.82 | - | ... | | 78 | x | The Disney Channel DISNEY-CBLK |
----------------------------------------------------------------------------------------------------------------------------------------------------------

This is Disney's idea of a fix for the 0 timer bug? Opening 100-200 ports? I'm betting that Zone Alarm freaks out from this behavior, because 99.9% of programs use two to three ports tops.

[Super Flappy]

That doesn't look good at all. By the way, you might want to snag a copy of TCPView (a much friendlier version of netstat from www.sysinternals.com) for a real-time view of the status of your ports.

[drwr]

Those are outbound connections, not inbound. And TIME_WAIT indicates the connections have already been closed and are just waiting to be removed from the queue.

It's saying you recently (i.e. within the past 2 minutes) opened and closed several connections to port 80 ("http") on that IP address.

Looks to me like you'd just been doing some web surfing.

[Growlur]

Originally posted by drwr
Those are outbound connections, not inbound. And TIME_WAIT indicates the connections have already been closed and are just waiting to be removed from the queue.

It's saying you recently (i.e. within the past 2 minutes) opened and closed several connections to port 80 ("http") on that IP address.

Looks to me like you'd just been doing some web surfing.

Those are not on port 80. They are on port 4000ish, which are the ports the game typically uses.

Counter-Strike servers use 27015. That's it. That's why I wondered why I'm sending from six billion different ports.

And doing some web surfing from the same ip? over and over again? to the point where I've got a netstat the size of Cleveland?

[SuperRufflepuff]

My guess is that they're trying to work around some bug in Python by closing corrupted socket connections after a certain timeout and opening new ones. Looks like they just need to tune the timeout a bit.

You should probably send a bug report.

[drwr]

The port 4000ish numbers you are seeing are the outbound port numbers on the local side. Every outgoing TCP connection has a local port number which is unrelated to the port number it is connecting to, and is generally assigned sequentially by the OS.

When you retrieve a web page, each embedded image on that page is typically retrieved via a separate connection. Even if the image is found in the cache, IE may still make and break a quick connection to the server for each image to verify that the cache isn't stale (depending on your cache settings and browser version--some older versions of IE won't turn this "feature" off no matter what your cache settings are).

Use IE to navigate to any web page, especially one that has a lot of little embedded images, and you'll see a similar spammage of recently-closed connections in your netstat output.

The Toontown web pages have a lot of little embedded images. Plus you have to go through two or three of these pages in order to get logged on. This netstat output is therefore a perfectly natural thing to see after logging in to Toontown through the web interface.

If you wait a few minutes after logging in, however, and give all these TIME_WAIT connections a chance to clear out, you'll only see one connection active, on port 6667, which is the Toontown game port.

Toontown only keeps that one connection open on port 6667 while you are playing the game; all that other stuff is opened by IE as you navigate through the web pages.

[Growlur]

Originally posted by drwr
Toontown only keeps that one connection open on port 6667 while you are playing the game; all that other stuff is opened by IE as you navigate through the web pages.

My apologies, you are absolutely correct.

My netstat after playing for about an hour:

TCP hippos:4406 199.181.133.82:6667 ESTABLISHED

(well, other stuff too, but that's none of your business )

[Super Flappy]

Cool! Thanks for the explanation, drwr.

I found an article which explains TIME_WAIT and, for the techno-geeks in the audience, tosses in a State/Transition diagram for TCP. Yee haw!

You'll find it here: http://tangentsoft.net/wskfaq/articl...gging-tcp.html

For what it's worth, TIME-WAIT on my XP machine's stack appears to be 120 seconds.

[Adam]

I have Zone Alarm PRO & it's OK