Wireshark-users: Re: [Wireshark-users] Diagnosing disconnect exactly every 10 minutes in online g
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Sake Blok <sake@xxxxxxxxxx>
Date: Sat, 11 Sep 2010 19:39:15 +0200
On 11 sep 2010, at 00:02, Austin Kretzer wrote:

> Anyway, here is the new .pcap file. I also posted on the same link as before if any of you want to read up on the forum post. 
> 
> http://www.mediafire.com/?p5yzw34kbr3z3p6

I took a look at the tracefile. It seems that communication between your game client and the game server consist of the following:

1)  A session to 202.67.52.11 port 54996 in which the client looks for software updates (look at the session when you do "decode as.." and then choose HTTP).

2)  Two SSL sessions to 219.117.154.110 port 443 . Probably to check your credentials and see your entitlements.

3)  A short session to 202.67.50.8 port 54994. There is the text "Test Ticket Data" in the session, so this might be a test login, before the actual login is done.

4) Two sessions to 202.67.48.224 port 54992. One looks like a keep-alive session, as there is one 40 byte payload being sent every 45 seconds. The other one is transferring data continuously, so that one looks like your game session.

Then suddenly the "keep-alive" session gets a TCP/RST from the server. This means the server no longer wants to communicate. I checked the IP TTL and it is the same as other packets in that direction. This means the RST most likely came from the server,  instead of an intermediate device (like the NAT router, ISP firewall, Game-server Firewall etc). The server might send a TCP/RST when it receives out-of-state data. On your side of the connection, this is not the case. But maybe after the router has performed NAT on the packet, it did not do the recalculation of the TCP header right.

Then after another 41 seconds, the other "live" session is torn down by the server, this time in a normal manner (TCP/FIN instead of TCP/RST).

Just before the TCP/RST on the "keep-alive" session, there was some UPnP communication between your client and the Netgear router. This is the only thing that sticks out in the trace. You might want to disable UPnP on your router to see whether that makes a difference. Or you might want to check if there is an update for the router software.

Cheers,


Sake