263 replies to this topic

[Razzez]

Press ctrl+C.



You have to manually stop the capturing with that keystroke. Basically you will see something that looks like this:



It's expected you only see the first line while it's runnning as the actual packets captured will be written in the file. As for the last 3 lines, those will appear when you terminate the program by pressing ctrl+C.

Ah that explains what I was missing. I thought you meant to do that to copy the information. Not stop it from running. I was using Ctrl+Pause to stop it

I'ts running now so once I get disconnect again I'll do Ctrl+C so I can see it this time.

Thanks again Javsy!

[Razzez]

Okay Javsy here's the first one I got so far:

D:\Downloads>windump  -i 1 -w rawfile.log net 128.241.92.98 and tcp port 4500
windump: listening on \Device\NPF_{F831F7C1-65B0-4591-A2F8-DD9855742023}
0 packets captured
396305 packets received by filter
0 packets dropped by kernel

[Axylus]

Okay Javsy here's the first one I got so far:

D:\Downloads>windump  -i 1 -w rawfile.log net 128.241.92.98 and tcp port 4500
windump: listening on \Device\NPF_{F831F7C1-65B0-4591-A2F8-DD9855742023}
0 packets captured
396305 packets received by filter
0 packets dropped by kernel

Where is the log?

By the way, before you post it, you should replace all occurrences of your IP address in it with the text "my-address", or something similarly appropriate, for the sake of security.

[Razzez]

Where is the log?

By the way, before you post it, you should replace all occurrences of your IP address in it with the text "my-address", or something similarly appropriate, for the sake of security.

I thought, from what I read, all that mattered was the last 3 lines showing the packet information. Which I got directly from the command prompt. I can get the log if needed also.

I'm not sure exactly what you mean by "replace all occurrences of your IP address in it with the text "my-address", or something similarly appropriate, for the sake of security".
If you mean change my IP address, as far as the last set of numbers, I already do that.

This is what showed for my second packet info:

D:\Downloads>windump  -i 1 -w rawfile.log net 128.241.92.98 and tcp port 4500
windump: listening on \Device\NPF_{F831F7C1-65B0-4591-A2F8-DD9855742023}
25 packets captured
366797 packets received by filter
0 packets dropped by kernel

Here's the log:

14:56:03.902444 IP (Terms of Service 0x0, ttl  48, id 64237, offset 0, flags [DF], proto: TCP (6), length: 52) .3431 > 128.241.92.98.4500: S, cksum 0xa52a (correct), 729014401:729014401(0) win 65535 <mss 1452,nop,wscale 3,nop,nop,sackOK>
14:56:03.946263 IP (Terms of Service 0x0, ttl 120, id 24057, offset 0, flags [DF], proto: TCP (6), length: 52) 128.241.92.98.4500 >.3431: S, cksum 0x3e2e (correct), 2579279137:2579279137(0) ack 729014402 win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
14:56:03.946310 IP (Terms of Service 0x0, ttl  48, id 64238, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1e2b (correct), ack 1 win 32982
14:56:03.951378 IP (Terms of Service 0x0, ttl  48, id 64239, offset 0, flags [DF], proto: TCP (6), length: 57) .3431 > 128.241.92.98.4500: P, cksum 0x829a (correct), 1:18(17) ack 1 win 32982
14:56:04.193673 IP (Terms of Service 0x0, ttl 120, id 24062, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.98.4500 > .3431: ., cksum 0x9dec (correct), ack 18 win 260
14:56:04.443284 IP (Terms of Service 0x0, ttl 120, id 24092, offset 0, flags [DF], proto: TCP (6), length: 44) 128.241.92.98.4500 > .3431: P, cksum 0x21f3 (correct), 1:5(4) ack 18 win 260
14:56:04.443346 IP (Terms of Service 0x0, ttl  48, id 64241, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1e16 (correct), ack 5 win 32982
14:56:04.488076 IP (Terms of Service 0x0, ttl 120, id 24094, offset 0, flags [DF], proto: TCP (6), length: 75) 128.241.92.98.4500 > .3431: P, cksum 0x3dfc (correct), 5:40(35) ack 18 win 260
14:56:04.488116 IP (Terms of Service 0x0, ttl  48, id 64243, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1df8 (correct), ack 40 win 32977
14:56:04.501914 IP (Terms of Service 0x0, ttl  48, id 64244, offset 0, flags [DF], proto: TCP (6), length: 42) .3431 > 128.241.92.98.4500: P, cksum 0x7ce4 (correct), 18:20(2) ack 40 win 32977
14:56:04.543289 IP (Terms of Service 0x0, ttl 120, id 24100, offset 0, flags [DF], proto: TCP (6), length: 476) 128.241.92.98.4500 > .3431: P 40:476(436) ack 20 win 260
14:56:04.543372 IP (Terms of Service 0x0, ttl  48, id 64245, offset 0, flags [DF], proto: TCP (6), length: 58) .3431 > 128.241.92.98.4500: P, cksum 0x7307 (correct), 20:38(18) ack 476 win 32923
14:56:04.586087 IP (Terms of Service 0x0, ttl 120, id 24103, offset 0, flags [DF], proto: TCP (6), length: 476) 128.241.92.98.4500 > .3431: P 476:912(436) ack 38 win 260
14:56:04.586162 IP (Terms of Service 0x0, ttl  48, id 64246, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1ae9 (correct), ack 912 win 32868
14:56:04.628692 IP (Terms of Service 0x0, ttl 120, id 24105, offset 0, flags [DF], proto: TCP (6), length: 480) 128.241.92.98.4500 > .3431: P 912:1352(440) ack 38 win 260
14:56:04.628757 IP (Terms of Service 0x0, ttl  48, id 64247, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1968 (correct), ack 1352 win 32813
14:56:05.252599 IP (Terms of Service 0x0, ttl  48, id 64254, offset 0, flags [DF], proto: TCP (6), length: 46) .3431 > 128.241.92.98.4500: P, cksum 0x166b (correct), 38:44(6) ack 1352 win 32813
14:56:05.293715 IP (Terms of Service 0x0, ttl 120, id 24116, offset 0, flags [DF], proto: TCP (6), length: 46) 128.241.92.98.4500 > .3431: P, cksum 0x958e (correct), 1352:1358(6) ack 44 win 260
14:56:05.293771 IP (Terms of Service 0x0, ttl  48, id 64255, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x195d (correct), ack 1358 win 32812
14:56:05.957828 IP (Terms of Service 0x0, ttl  48, id 64261, offset 0, flags [DF], proto: TCP (6), length: 43) .3431 > 128.241.92.98.4500: P, cksum 0xb351 (correct), 44:47(3) ack 1358 win 32812
14:56:06.001140 IP (Terms of Service 0x0, ttl 120, id 24153, offset 0, flags [DF], proto: TCP (6), length: 68) 128.241.92.98.4500 > .3431: P, cksum 0xc9e0 (correct), 1358:1386(28) ack 47 win 260
14:56:06.001197 IP (Terms of Service 0x0, ttl  48, id 64263, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1941 (correct), ack 1386 win 32809
14:56:06.366465 IP (Terms of Service 0x0, ttl  48, id 64265, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: F, cksum 0x1940 (correct), 47:47(0) ack 1386 win 32809
14:56:06.408760 IP (Terms of Service 0x0, ttl 120, id 24162, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.98.4500 > .3431: ., cksum 0x9865 (correct), ack 48 win 260
14:56:06.412870 IP (Terms of Service 0x0, ttl 120, id 24163, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.98.4500 > .3431: R, cksum 0x9965 (correct), 1386:1386(0) ack 48 win 0

Edited by Razzez, 25 April 2013 - 11:39 PM.

[renouille]

Spoiler

I thought, from what I read, all that mattered was the last 3 lines showing the packet information. Which I got directly from the command prompt. I can get the log if needed also.

I'm not sure exactly what you mean by "replace all occurrences of your IP address in it with the text "my-address", or something similarly appropriate, for the sake of security".
If you mean change my IP address, as far as the last set of numbers, I already do that.

This is what showed for my second packet info:

D:\Downloads>windump  -i 1 -w rawfile.log net 128.241.92.98 and tcp port 4500
windump: listening on \Device\NPF_{F831F7C1-65B0-4591-A2F8-DD9855742023}
25 packets captured
366797 packets received by filter
0 packets dropped by kernel

Here's the log:

14:56:03.902444 IP (Terms of Service 0x0, ttl  48, id 64237, offset 0, flags [DF], proto: TCP (6), length: 52) .3431 > 128.241.92.98.4500: S, cksum 0xa52a (correct), 729014401:729014401(0) win 65535 <mss 1452,nop,wscale 3,nop,nop,sackOK>
14:56:03.946263 IP (Terms of Service 0x0, ttl 120, id 24057, offset 0, flags [DF], proto: TCP (6), length: 52) 128.241.92.98.4500 >.3431: S, cksum 0x3e2e (correct), 2579279137:2579279137(0) ack 729014402 win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
14:56:03.946310 IP (Terms of Service 0x0, ttl  48, id 64238, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1e2b (correct), ack 1 win 32982
14:56:03.951378 IP (Terms of Service 0x0, ttl  48, id 64239, offset 0, flags [DF], proto: TCP (6), length: 57) .3431 > 128.241.92.98.4500: P, cksum 0x829a (correct), 1:18(17) ack 1 win 32982
14:56:04.193673 IP (Terms of Service 0x0, ttl 120, id 24062, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.98.4500 > .3431: ., cksum 0x9dec (correct), ack 18 win 260
14:56:04.443284 IP (Terms of Service 0x0, ttl 120, id 24092, offset 0, flags [DF], proto: TCP (6), length: 44) 128.241.92.98.4500 > .3431: P, cksum 0x21f3 (correct), 1:5(4) ack 18 win 260
14:56:04.443346 IP (Terms of Service 0x0, ttl  48, id 64241, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1e16 (correct), ack 5 win 32982
14:56:04.488076 IP (Terms of Service 0x0, ttl 120, id 24094, offset 0, flags [DF], proto: TCP (6), length: 75) 128.241.92.98.4500 > .3431: P, cksum 0x3dfc (correct), 5:40(35) ack 18 win 260
14:56:04.488116 IP (Terms of Service 0x0, ttl  48, id 64243, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1df8 (correct), ack 40 win 32977
14:56:04.501914 IP (Terms of Service 0x0, ttl  48, id 64244, offset 0, flags [DF], proto: TCP (6), length: 42) .3431 > 128.241.92.98.4500: P, cksum 0x7ce4 (correct), 18:20(2) ack 40 win 32977
14:56:04.543289 IP (Terms of Service 0x0, ttl 120, id 24100, offset 0, flags [DF], proto: TCP (6), length: 476) 128.241.92.98.4500 > .3431: P 40:476(436) ack 20 win 260
14:56:04.543372 IP (Terms of Service 0x0, ttl  48, id 64245, offset 0, flags [DF], proto: TCP (6), length: 58) .3431 > 128.241.92.98.4500: P, cksum 0x7307 (correct), 20:38(18) ack 476 win 32923
14:56:04.586087 IP (Terms of Service 0x0, ttl 120, id 24103, offset 0, flags [DF], proto: TCP (6), length: 476) 128.241.92.98.4500 > .3431: P 476:912(436) ack 38 win 260
14:56:04.586162 IP (Terms of Service 0x0, ttl  48, id 64246, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1ae9 (correct), ack 912 win 32868
14:56:04.628692 IP (Terms of Service 0x0, ttl 120, id 24105, offset 0, flags [DF], proto: TCP (6), length: 480) 128.241.92.98.4500 > .3431: P 912:1352(440) ack 38 win 260
14:56:04.628757 IP (Terms of Service 0x0, ttl  48, id 64247, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1968 (correct), ack 1352 win 32813
14:56:05.252599 IP (Terms of Service 0x0, ttl  48, id 64254, offset 0, flags [DF], proto: TCP (6), length: 46) .3431 > 128.241.92.98.4500: P, cksum 0x166b (correct), 38:44(6) ack 1352 win 32813
14:56:05.293715 IP (Terms of Service 0x0, ttl 120, id 24116, offset 0, flags [DF], proto: TCP (6), length: 46) 128.241.92.98.4500 > .3431: P, cksum 0x958e (correct), 1352:1358(6) ack 44 win 260
14:56:05.293771 IP (Terms of Service 0x0, ttl  48, id 64255, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x195d (correct), ack 1358 win 32812
14:56:05.957828 IP (Terms of Service 0x0, ttl  48, id 64261, offset 0, flags [DF], proto: TCP (6), length: 43) .3431 > 128.241.92.98.4500: P, cksum 0xb351 (correct), 44:47(3) ack 1358 win 32812
14:56:06.001140 IP (Terms of Service 0x0, ttl 120, id 24153, offset 0, flags [DF], proto: TCP (6), length: 68) 128.241.92.98.4500 > .3431: P, cksum 0xc9e0 (correct), 1358:1386(28) ack 47 win 260
14:56:06.001197 IP (Terms of Service 0x0, ttl  48, id 64263, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: ., cksum 0x1941 (correct), ack 1386 win 32809
14:56:06.366465 IP (Terms of Service 0x0, ttl  48, id 64265, offset 0, flags [DF], proto: TCP (6), length: 40) .3431 > 128.241.92.98.4500: F, cksum 0x1940 (correct), 47:47(0) ack 1386 win 32809
14:56:06.408760 IP (Terms of Service 0x0, ttl 120, id 24162, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.98.4500 > .3431: ., cksum 0x9865 (correct), ack 48 win 260
14:56:06.412870 IP (Terms of Service 0x0, ttl 120, id 24163, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.98.4500 > .3431: R, cksum 0x9965 (correct), 1386:1386(0) ack 48 win 0

That's the char server.

[Javsy]

I think it's time to review our TCP Flags lessons first
http://support.microsoft.com/kb/169292

On the sample logs I posted below, you will see the TCP flags as a single letter between the "source IP > destination IP" and the cksum

When you log on a map server, the connection is initiated sending SYN (S for Synchronize) flag from both sides.

18:32:07.999856 IP (Terms of Service 0x0, ttl 128, id 4694, offset 0, flags [DF], proto: TCP (6), length: 52) <myipaddress:port> > 128.241.92.101.4500: S, cksum 0x9e06 (correct), 1183101377:1183101377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
18:32:08.191188 IP (Terms of Service 0x0, ttl 111, id 7395, offset 0, flags [DF], proto: TCP (6), length: 52) 128.241.92.101.4500 > <myipaddress:port>: S, cksum 0x60ad (correct), 3021768997:3021768997(0) ack 1183101378 win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

Then while logged in, it uses PSH (P for push) flag while you're connected to the map server exchanging information.

18:32:08.191283 IP (Terms of Service 0x0, ttl 128, id 4696, offset 0, flags [DF], proto: TCP (6), length: 40) <myipaddress:port> > 128.241.92.101.4500: ., cksum 0x8157 (correct), ack 1 win 16425
18:32:09.015263 IP (Terms of Service 0x0, ttl 128, id 4701, offset 0, flags [DF], proto: TCP (6), length: 59) <myipaddress:port> > 128.241.92.101.4500: P, cksum 0xcffe (correct), 1:20(19) ack 1 win 16425
18:32:09.415956 IP (Terms of Service 0x0, ttl 112, id 8579, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.101.4500 > <myipaddress:port>: ., cksum 0xc06d (correct), ack 20 win 256
18:32:09.458417 IP (Terms of Service 0x0, ttl 112, id 8631, offset 0, flags [DF], proto: TCP (6), length: 46) 128.241.92.101.4500 > <myipaddress:port>: P, cksum 0x54bf (correct), 1:7(6) ack 20 win 256

And when you gracefully log out, you would be seeing a FIN (F for Finish) flag sent from your side followed by RST (R for Reset) Flags from each side to terminate the connection.

128.241.92.101.4500: F, cksum 0x79e4 (correct), 804:804(0) ack 14377 win 16096
18:12:45.088260 IP (Terms of Service 0x0, ttl 111, id 945, offset 0, flags [DF], proto: TCP (6), length: 127) 128.241.92.101.4500 > <myipaddress:port>: P 14377:14464(87) ack 805 win 253
18:12:45.088415 IP (Terms of Service 0x0, ttl 128, id 31138, offset 0, flags [DF], proto: TCP (6), length: 40) <myipaddress:port> > 128.241.92.101.4500: R, cksum 0xb869 (correct), 805:805(0) ack 14464 win 0
18:12:45.088760 IP (Terms of Service 0x0, ttl 111, id 946, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.101.4500 > <myipaddress:port>:R, cksum 0xb869 (correct), 14464:14464(0) ack 805 win 0

Let's focus on the FIN and RST flags for now. This will give you a good indication whether you have been disconnected or kicked out by the server on purpose. To explain it further:
1. if you only get a RST flag from server going to your IP address, it's a good indication that the server forced you to log off.
2. If you only get a RST flag to the server but you didn't received a RST back, it means that you initiated the log off. This might include network disconnection, logging off by pressing ALT+F4, and other abnormal ways you close out the game.
3. If you don't see any RST flags when you got disconnected, you might need to dig into it deeper as it's a pretty ambigous case

Based on the last few lines in the log you posted, it seems you closed the game gracefully (correct me if I'm wrong). But having this is a good start how to check it out and investigate your problem.

Edited by Javsy, 26 April 2013 - 02:05 AM.

[renouille]

Based on the last few lines in the log you posted, it seems you closed the game gracefully (correct me if I'm wrong). But having this is a good start how to check it out and investigate your problem.

He selected a character and got info from the char server (IP, map, etc.)
Then the client closed the connection to the char server (end of logged packets) and connected to the zone server.

[Javsy]

He selected a character and got info from the char server (IP, map, etc.)
Then the client closed the connection to the char server (end of logged packets) and connected to the zone server.

Oh right, I didn't knew he used the Chaos character server IP 128.241.92.98 (I just verified). My bad.

[Razzez]

I think it's time to review our TCP Flags lessons first
http://support.microsoft.com/kb/169292

On the sample logs I posted below, you will see the TCP flags as a single letter between the "source IP > destination IP" and the cksum

When you log on a map server, the connection is initiated sending SYN (S for Synchronize) flag from both sides.

18:32:07.999856 IP (Terms of Service 0x0, ttl 128, id 4694, offset 0, flags [DF], proto: TCP (6), length: 52) <myipaddress:port> > 128.241.92.101.4500: S, cksum 0x9e06 (correct), 1183101377:1183101377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
18:32:08.191188 IP (Terms of Service 0x0, ttl 111, id 7395, offset 0, flags [DF], proto: TCP (6), length: 52) 128.241.92.101.4500 > <myipaddress:port>: S, cksum 0x60ad (correct), 3021768997:3021768997(0) ack 1183101378 win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

Then while logged in, it uses PSH (P for push) flag while you're connected to the map server exchanging information.

18:32:08.191283 IP (Terms of Service 0x0, ttl 128, id 4696, offset 0, flags [DF], proto: TCP (6), length: 40) <myipaddress:port> > 128.241.92.101.4500: ., cksum 0x8157 (correct), ack 1 win 16425
18:32:09.015263 IP (Terms of Service 0x0, ttl 128, id 4701, offset 0, flags [DF], proto: TCP (6), length: 59) <myipaddress:port> > 128.241.92.101.4500: P, cksum 0xcffe (correct), 1:20(19) ack 1 win 16425
18:32:09.415956 IP (Terms of Service 0x0, ttl 112, id 8579, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.101.4500 > <myipaddress:port>: ., cksum 0xc06d (correct), ack 20 win 256
18:32:09.458417 IP (Terms of Service 0x0, ttl 112, id 8631, offset 0, flags [DF], proto: TCP (6), length: 46) 128.241.92.101.4500 > <myipaddress:port>: P, cksum 0x54bf (correct), 1:7(6) ack 20 win 256

And when you gracefully log out, you would be seeing a FIN (F for Finish) flag sent from your side followed by RST (R for Reset) Flags from each side to terminate the connection.

128.241.92.101.4500: F, cksum 0x79e4 (correct), 804:804(0) ack 14377 win 16096
18:12:45.088260 IP (Terms of Service 0x0, ttl 111, id 945, offset 0, flags [DF], proto: TCP (6), length: 127) 128.241.92.101.4500 > <myipaddress:port>: P 14377:14464(87) ack 805 win 253
18:12:45.088415 IP (Terms of Service 0x0, ttl 128, id 31138, offset 0, flags [DF], proto: TCP (6), length: 40) <myipaddress:port> > 128.241.92.101.4500: R, cksum 0xb869 (correct), 805:805(0) ack 14464 win 0
18:12:45.088760 IP (Terms of Service 0x0, ttl 111, id 946, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.101.4500 > <myipaddress:port>:R, cksum 0xb869 (correct), 14464:14464(0) ack 805 win 0

Let's focus on the FIN and RST flags for now. This will give you a good indication whether you have been disconnected or kicked out by the server on purpose. To explain it further:
1. if you only get a RST flag from server going to your IP address, it's a good indication that the server forced you to log off.
2. If you only get a RST flag to the server but you didn't received a RST back, it means that you initiated the log off. This might include network disconnection, logging off by pressing ALT+F4, and other abnormal ways you close out the game.
3. If you don't see any RST flags when you got disconnected, you might need to dig into it deeper as it's a pretty ambigous case

Based on the last few lines in the log you posted, it seems you closed the game gracefully (correct me if I'm wrong). But having this is a good start how to check it out and investigate your problem.

I posted the full & complete log. The only thing I did was edit out my IP address like you did except I didn't replace as you did with "myipaddess:port".

I have repeatedly said I am getting "TIME GAP ERRORS", which cause me to be disconnected, while I am afk & vending. So this means I am obviously not logging off myself. Even if I was logging off myself I wouldn't be reporting this as a problem, & wasting my time doing windumps or pasting that information, trying to get help with something that is a non-issue.

So to answer your question directly, I have never closed the game or logged off of it. Nothing I have posted should be showing that since I have only posted the d/c's as we have discussed. The ONLY time I ever close & restart the program is after maintenance or if I need to reboot my computer. My system stays on 24/7.

P.S. I do have 2 clients running & vending at the same time.

He selected a character and got info from the char server (IP, map, etc.)
Then the client closed the connection to the char server (end of logged packets) and connected to the zone server.

In the previous posts we have already discussed it doesn't matter which IP address is used as long as it's the one for RO's servers. The only difference is the last set of digits which means they are using the same gateway & the same server.

Rather then assume what I did you should ask like Javsy did since you are incorrect.

Edited by Razzez, 26 April 2013 - 02:27 AM.

[renouille]

In the previous posts we have already discussed it doesn't matter which IP address is used as long as it's the one for RO's servers. The only difference is the last set of digits which means they are using the same gateway & the same server.

There is no "one" IP for RO's servers. The char server has its own IP. Each zone server has its own IP. When you get "disconnected from server" while in game, you are connected to a zone server.

If you looked at my original command line arguments, you'd see that I gave an address range known to encompass all of RO's game servers, rather than a single IP. The advantage is that you don't have to edit the command line for different zones. The disadvantage is that the log can become confusing if you have multiple clients connected.

Rather then assume what I did you should ask like Javsy did since you are incorrect.

I don't have to ask about things that are in plain sight for anyone to see.

Fact #1: 128.241.92.98 is the address of the renewal char server
Fact #2: your log shows only communication with this server
Fact #3: the packet lengths in your log are consistent with communication with the current version of the char server, terminating with character selection followed by the expected response
Fact #4: your log begins with a successful connection
Fact #5: your log ends 2.5 seconds later with a connection shutdown initiated by the client, which is exactly what is supposed to happen after the events in #3

Feel free to dispute any of these, but I expect more than "you are incorrect."

Edited by renouille, 26 April 2013 - 02:42 AM.

[Javsy]

In the previous posts we have already discussed it doesn't matter which IP address is used as long as it's the one for RO's servers. The only difference is the last set of digits which means they are using the same gateway & the same server.

DEFINITELY WRONG. You did used the Chaos Character Server on your windump log.

I will point this out once again. You really need the correct IP address of the map server. Especially when doing windump, How do you think are you gonna capture the packets during time gap errors if your computer is not interacting with the IP address you set when you're getting disconnected on a different IP address? It's like you're recording a car accident with a cam for a local news but you're recording it at the wrong place. Get the idea?

Like on the last log you posted, it only captures the packets when you're in the character select screen. When you go to the map server, you're no longer connected to 128.241.92.98 as the packets are already going to the map server.

If you won't take our advise, then we can't help you.

Edited by Javsy, 26 April 2013 - 02:50 AM.

[Razzez]

Just so you would have a sample of the difference of a normal disconnect, versus a Time Gap Error, I just ran windump again & logged out from one of my clients while it was running.

I also did Eden's HQ instead since there was a question about the IP I used.

This is the information from it. From the sounds of things you don't need the full log just the end of it. Let me know if you need more though.

D:\Downloads>windump -i 1 -w rawfile.log net 128.241.92.112 and tcp port 4500
windump: listening on \Device\NPF_{F831F7C1-65B0-4591-A2F8-DD9855742023}
238 packets captured
329 packets received by filter
0 packets dropped by kernel

06:33:00.872107 IP (Terms of Service 0x0, ttl 120, id 25300, offset 0, flags [DF], proto: TCP (6), length: 49) 128.241.92.112.4500 > myipaddress:port: P, cksum 0x1756 (correct), 2984:2993(9) ack 13 win 257
06:33:00.872165 IP (Terms of Service 0x0, ttl  48, id 59619, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0xde80 (correct), ack 2993 win 32956
06:33:00.915175 IP (Terms of Service 0x0, ttl 120, id 25326, offset 0, flags [DF], proto: TCP (6), length: 74) 128.241.92.112.4500 > myipaddress:port: P, cksum 0x83e0 (correct), 2993:3027(34) ack 13 win 257
06:33:00.915226 IP (Terms of Service 0x0, ttl  48, id 59620, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0xde62 (correct), ack 3027 win 32952
06:33:00.963698 IP (Terms of Service 0x0, ttl  48, id 59625, offset 0, flags [DF], proto: TCP (6), length: 46) myipaddress:port > 128.241.92.112.4500: P, cksum 0x1853 (correct), 13:19(6) ack 3027 win 32952
06:33:01.016913 IP (Terms of Service 0x0, ttl 120, id 25373, offset 0, flags [DF], proto: TCP (6), length: 46) 128.241.92.112.4500 > myipaddress:port: P, cksum 0x80b9 (correct), 3027:3033(6) ack 19 win 257
06:33:01.016969 IP (Terms of Service 0x0, ttl  48, id 59626, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0xde57 (correct), ack 3033 win 32951
06:33:01.616935 IP (Terms of Service 0x0, ttl 120, id 25855, offset 0, flags [DF], proto: TCP (6), length: 49) 128.241.92.112.4500 > myipaddress:port: P, cksum 0xbf2b (correct), 3033:3042(9) ack 19 win 257
06:33:01.616984 IP (Terms of Service 0x0, ttl  48, id 59627, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0xde4f (correct), ack 3042 win 32950

[Javsy]

I don't see the normal disconnect was captured in the logs. Are you sure you're still capturing when you logged out? I don't see the FIN and RST flags captured.

[Razzez]

DEFINITELY WRONG. You did used the Chaos Character Server on your windump log.

I will point this out once again. You really need the correct IP address of the map server. Especially when doing windump, How do you think are you gonna capture the packets during time gap errors if your computer is not interacting with the IP address you set? Like on the last log you posted, it only captures the packets when you're in the character select screen. When you go to the map server, you're no longer connected to 128.241.92.98 as the packets are already going to the map server.

If you won't take our advise, then we can't help you.

I believe I have been taking your advice. I don't recall you telling me that I needed to use a specific IP Address. Only that you were using the Prontera Map IP which didn't apply to anything I was doing since I'm not in Prontera.

This is what I was talking about that was previously said:

I'm sorry to contradict you, but I don't think there is any benefit to using the addresses of specific game servers. From what I've observed over the years, almost all of Gravity's servers are in the same LAN.

I agree the servers are in the network but depending on the network topology it can give different results (sometimes minimal) if you try to trace 2 different map servers (as they maybe connected on different branches on the network which might have different traffic level, on an heirarchal topology for example).

But nevertheless, we have already made full effort to help everyone up to the smallest detail.... So why not?

I suppose it's possible, but I'd be surprised if using specific server addresses made any measurable difference. It's certainly more sound in terms of methodology, but I don't think recommending it is worth the confusion it would cause the average person. In my experience, most people hugely struggle even with copying complete commands into Command Prompt.

Maybe I misunderstood these posts or was this only apply to tracerts & not windump?

[Razzez]

I don't see the normal disconnect was captured in the logs. Are you sure you're still capturing when you logged out? I don't see the FIN and RST flags captured.

I didn't either. I'm sure that everything I say I have done I have done each & every time I have posted. Like I said though I only logged off the one character. My other client was still connected at the time so I don't know if that makes a difference. Do I have to log off on both of them for it to show up?

I guess so. Here it is with both logged off.

D:\Downloads>windump -i 1 -w rawfile.log net 128.241.92.112 and tcp port 4500
windump: listening on \Device\NPF_{F831F7C1-65B0-4591-A2F8-DD9855742023}
74 packets captured
157 packets received by filter
0 packets dropped by kernel

07:01:22.491200 IP (Terms of Service 0x0, ttl  48, id 19059, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0xe8dc (correct), ack 988 win 32879
07:01:22.736147 IP (Terms of Service 0x0, ttl 120, id 28026, offset 0, flags [DF], proto: TCP (6), length: 43) 128.241.92.112.4500 > myipaddress:port: P, cksum 0xb43c (correct), 988:991(3) ack 16 win 260
07:01:22.736203 IP (Terms of Service 0x0, ttl  48, id 19066, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0xe8d9 (correct), ack 991 win 32879
07:01:22.757054 IP (Terms of Service 0x0, ttl  48, id 19067, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: F, cksum 0xe8d8 (correct), 16:16(0) ack 991 win 32879
07:01:22.799140 IP (Terms of Service 0x0, ttl 120, id 28053, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.112.4500 > myipaddress:port: ., cksum 0x6844 (correct), ack 17 win 260
07:01:22.801747 IP (Terms of Service 0x0, ttl 120, id 28054, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.112.4500 > myipaddress:port: R, cksum 0x6944 (correct), 991:991(0) ack 17 win 0

Now I'll run windump again using this IP, unless you want me to use another one, until I get another Time Gap Error.

Edited by Razzez, 26 April 2013 - 03:08 AM.

[Javsy]

I believe I have been taking your advice.

I was referring to the people who advised you can use the other IP addresses in the same WP network. You can use any map server i guess if you're just making route diagnostics. But for zone/map server specific lag, I really suggest you use the map server IP you are logged in when doing traceroutes.

For windumps, it's really a must.

Now I'll run windump again using this IP, unless you want me to use another one, until I get another Time Gap Error.

Perhaps you logged off the wrong client? Or maybe they're in the same map server so when you logged off the other one you will still see the FIN and RST flags but it won't be at the last part of the log since the other client open and is connected to the same map server and its packets are also captured.

This means it's better to stay away dual clienting on the same zone so only one game client is captured to avoid confusion.

On the last log you posted, you can see the FIN and RST flags there so I think you did it right. As for the map server IP, you can use Eden HQ or Prontera or anywhere you want as long as you know the IP address of that map and you're actually logged in that place.

Edited by Javsy, 26 April 2013 - 03:21 AM.

[Razzez]

I was referring to the people who advised you can use the other IP addresses in the same WP network. You can use any map server i guess if you're just making route diagnostics. But for zone/map server specific lag, I really suggest you use the map server IP you are logged in when doing traceroutes.

For windumps, it's really a must.




Perhaps you logged off the wrong client? Or maybe they're in the same map server so when you logged off the other one you will still see the FIN and RST flags but it won't be at the last part of the log since the other client open and is connected to the same map server and its packets are also captured.

This means it's better to stay away dual clienting on the same zone so only one game client is captured to avoid confusion.

On the last log you posted, you can see the FIN and RST flags there so I think you did it right. As for the map server IP, you can use Eden HQ or Prontera or anywhere you want as long as you know the IP address of that map and you're actually logged in that place.

I was referring to what you & Axylus had said in the quotes I stated above but I can understand if the windumps make a difference. That I didn't realize.

I am now using the Eden HQ's IP because that is where I am actually vending & yes both my characters are vending there. At this point I don't think I need to just use the one client since I find they both normally receive the Time Gap Errors & are disconnected at the same time. If it is causing confusion in the log I will do what you need me to but so far everything I have done so far has been at the time they had both received the Time Gap Error. Only the one log I posted when I manually logged off had the other one still on that explains why it showed to still be connected.

[renouille]

I was referring to what you & Axylus had said in the quotes I stated above but I can understand if the windumps make a difference. That I didn't realize.

I am now using the Eden HQ's IP because that is where I am actually vending & yes both my characters are vending there. At this point I don't think I need to just use the one client since I find they both normally receive the Time Gap Errors & are disconnected at the same time. If it is causing confusion in the log I will do what you need me to but so far everything I have done so far has been at the time they had both received the Time Gap Error. Only the one log I posted when I manually logged off had the other one still on that explains why it showed to still be connected.

To capture only one client you'll have to filter by local port, e.g. "host 128.241.92.112 and tcp port 4500 and 55555"

You can get ip:port<->PID associations from "netstat -no" and PID<->process name from task manager.

[Axylus]

Shouldn't WinDump be configured to capture packets using the zone server port if Razzez is being disconnected while vending?

[renouille]

zone server port

= 4500

[Razzez]

To capture only one client you'll have to filter by local port, e.g. "host 128.241.92.112 and tcp port 4500 and 55555"

You can get ip:port<->PID associations from "netstat -no" and PID<->process name from task manager.

I'm not sure what you mean by either of these comments. I've posted above & below the windump command I am running.

Now this time I only left one client/character vending in Eden. My other client was logged in but I didn't have any character connected to the server.

Here's the results now:

D:\Downloads>windump -i 1 -w rawfile.log net 128.241.92.112 and tcp port 4500
windump: listening on \Device\NPF_{F831F7C1-65B0-4591-A2F8-DD9855742023}
37400 packets captured
143417 packets received by filter
0 packets dropped by kernel

08:27:28.317410 IP (Terms of Service 0x0, ttl  48, id 30225, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0x12c6 (correct), ack 369397 win 32838
08:27:29.252395 IP (Terms of Service 0x0, ttl 120, id 9639, offset 0, flags [DF], proto: TCP (6), length: 50) 128.241.92.112.4500 > myipaddress:port: P, cksum 0x6230 (correct), 369397:369407(10) ack 2997 win 260
08:27:29.252445 IP (Terms of Service 0x0, ttl  48, id 30230, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0x12be (correct), ack 369407 win 32836
08:27:29.418714 IP (Terms of Service 0x0, ttl 120, id 9802, offset 0, flags [DF], proto: TCP (6), length: 117) 128.241.92.112.4500 > myipaddress:port: P 369407:369484(77) ack 2997 win 260
08:27:29.418770 IP (Terms of Service 0x0, ttl  48, id 30231, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0x127a (correct), ack 369484 win 32827
08:27:29.442323 IP (Terms of Service 0x0, ttl  48, id 30232, offset 0, flags [DF], proto: TCP (6), length: 46) myipaddress:port > 128.241.92.112.4500: P, cksum 0xc184 (correct), 2997:3003(6) ack 369484 win 32827
08:27:29.492403 IP (Terms of Service 0x0, ttl 120, id 9871, offset 0, flags [DF], proto: TCP (6), length: 43) 128.241.92.112.4500 > myipaddress:port: P, cksum 0x0da0 (correct), 369484:369487(3) ack 3003 win 260
08:27:29.492447 IP (Terms of Service 0x0, ttl  48, id 30233, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0x1272 (correct), ack 369487 win 32826
08:27:29.525774 IP (Terms of Service 0x0, ttl  48, id 30234, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: F, cksum 0x1271 (correct), 3003:3003(0) ack 369487 win 32826
08:27:29.567811 IP (Terms of Service 0x0, ttl 120, id 9942, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.112.4500 > myipaddress:port: ., cksum 0x91a7 (correct), ack 3004 win 260
08:27:29.569199 IP (Terms of Service 0x0, ttl 120, id 9944, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.112.4500 > myipaddress:port: R, cksum 0x92a7 (correct), 369487:369487(0) ack 3004 win 0

[Razzez]

This time I only logged in with one client to the 2nd floor of the Eden HQ. I was completely idle, not vending, while I afk was on Firefox.

D:\Downloads>windump -i 1 -w rawfile.log net 128.241.92.112 and tcp port 4500
windump: listening on \Device\NPF_{F831F7C1-65B0-4591-A2F8-DD9855742023}
14982 packets captured
46679 packets received by filter
0 packets dropped by kernel

09:22:59.823638 IP (Terms of Service 0x0, ttl  48, id 7821, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0x8e00 (correct), ack 343466 win 32871
09:23:00.962386 IP (Terms of Service 0x0, ttl  48, id 8496, offset 0, flags [DF], proto: TCP (6), length: 46) myipaddress:port > 128.241.92.112.4500: P, cksum 0xea37 (correct), 3689:3695(6) ack 343466 win 32871
09:23:01.005829 IP (Terms of Service 0x0, ttl 120, id 644, offset 0, flags [DF], proto: TCP (6), length: 43) 128.241.92.112.4500 > myipaddress:port: P, cksum 0x8955 (correct), 343466:343469(3) ack 3695 win 257
09:23:01.005884 IP (Terms of Service 0x0, ttl  48, id 8497, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: ., cksum 0x8df7 (correct), ack 343469 win 32871
09:23:01.010220 IP (Terms of Service 0x0, ttl  48, id 8498, offset 0, flags [DF], proto: TCP (6), length: 40) myipaddress:port > 128.241.92.112.4500: F, cksum 0x8df6 (correct), 3695:3695(0) ack 343469 win 32871
09:23:01.055716 IP (Terms of Service 0x0, ttl 120, id 670, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.112.4500 > myipaddress:port: ., cksum 0x0d5d (correct), ack 3696 win 257
09:23:01.058637 IP (Terms of Service 0x0, ttl 120, id 673, offset 0, flags [DF], proto: TCP (6), length: 40) 128.241.92.112.4500 > myipaddress:port: R, cksum 0x0e5a (correct), 343469:343469(0) ack 3696 win 0

I know this still doesn't make sense but one thing I don't understand, compared to what you showed me & described, Javsy, is why I am seeing my IP being sent twice along with the Servers IP?

[Razzez]

There is no "one" IP for RO's servers. The char server has its own IP. Each zone server has its own IP. When you get "disconnected from server" while in game, you are connected to a zone server.

If you looked at my original command line arguments, you'd see that I gave an address range known to encompass all of RO's game servers, rather than a single IP. The advantage is that you don't have to edit the command line for different zones. The disadvantage is that the log can become confusing if you have multiple clients connected.



I don't have to ask about things that are in plain sight for anyone to see.

Fact #1: 128.241.92.98 is the address of the renewal char server
Fact #2: your log shows only communication with this server
Fact #3: the packet lengths in your log are consistent with communication with the current version of the char server, terminating with character selection followed by the expected response
Fact #4: your log begins with a successful connection
Fact #5: your log ends 2.5 seconds later with a connection shutdown initiated by the client, which is exactly what is supposed to happen after the events in #3

Feel free to dispute any of these, but I expect more than "you are incorrect."

"There is no "one" IP for RO's servers. The char server has its own IP. Each zone server has its own IP."
I already know this & never said there was. I said there was one gateway & "ONE SERVER" NOT IP.

Seriously? Are you trying to help me or confuse me? If you want to help me I would think you would ask what is happening or what I am doing rather then tell me?
First of all the only post regarding a list of IP's I saw is the original one from Javsy so I'm not sure what you are referring to even. The only full log I even posted was the first one. Since then I have only posted the end of the logs since that's all that appeared to matter. Javsy also already said that from looking at the log it appeared that I logged off myself but he asked me if that was the case where you are assuming things based off of them. Since there is a problem with something here you should know better then to assume things to be the way they should be.

The problem, as I've said a number of times previously, is that I am getting "TIME GAP ERRORS". That's what is causing the disconnects. If I was actually playing the game, & actively fighting monsters, & being "disconnected from the server", then yes it would matter where I was connected to at the time however that isn't the issue in my case. I am using the Chaos Renewal Server. It doesn't matter where my character is. It doesn't matter if I am in Prontera or Eden or anywhere else. I receive the "Time Gap Errors" & am disconnected due to them. So I'll use any IP you guys want me to use it doesn't matter to me as long as you understand that the problem is with "Time Gap Errors" & not disconnects themselves. The only time I normally get disconnected from the server is when maintenance is done

You obviously can't see my computer & don't know what I am doing on it otherwise you wouldn't be saying the things you are. I have better things to do then waste my time or yours posting here & trying to get help with a problem that has been going on within RO for some time now & I'm not the only one that has this problem. There are many users that have been having problems with Time Gap Errors for quite some time. Most don't take the time to say anything about it however I made a post awhile back in the Forum just to make sure that I wasn't alone.

If you can't or don't want to help me then that's okay. There is no reason to post messages that are unhelpful though. I am here for help not to waste my time or anyone else's.

Edited by Razzez, 26 April 2013 - 06:16 AM.

[renouille]

"There is no "one" IP for RO's servers. The char server has its own IP. Each zone server has its own IP."
I already know this & never said there was. I said there was one gateway & "ONE SERVER" NOT IP.

RO has more than one server.

Seriously? Are you trying to help me or confuse me? If you want to help me I would think you would ask what is happening or what I am doing rather then tell me?

I already know from your numerous posts that you are suffering from time gaps. Also, I wasn't telling you. I was telling Javsy--because his interpretation was incorrect.

First of all the only post regarding a list of IP's I saw is the original one from Javsy so I'm not sure what you are referring to even. The only full log I even posted was the first one. Since then I have only posted the end of the logs since that's all that appeared to matter. Javsy also already said that from looking at the log it appeared that I logged off myself but he asked me if that was the case where you are assuming things based off of them. Since there is a problem with something here you should know better then to assume things to be the way they should be.

If you're referring to this post, it shows a 2.5-second character server connection exactly as I described. I noticed that you didn't dispute any of the facts I listed.

The problem, as I've said a number of times previously, is that I am getting "TIME GAP ERRORS". That's what is causing the disconnects.

We know.

If I was actually playing the game, & actively fighting monsters, & being "disconnected from the server", then yes it would matter where I was connected to at the time however that isn't the issue in my case. I am using the Chaos Renewal Server. It doesn't matter where my character is. It doesn't matter if I am in Prontera or Eden or anywhere else. I receive the "Time Gap Errors" & am disconnected due to them. So I'll use any IP you guys want me to use it doesn't matter to me as long as you understand that the problem is with "Time Gap Errors" & not disconnects themselves. The only time I normally get disconnected from the server is when maintenance is done

The IP does matter for the purpose of capturing packet headers from the server that you're connected to at the moment you time gap. (Of course that's only true if you're filtering by IP instead of the net/mask I originally posted.)

You obviously can't see my computer & don't know what I am doing on it otherwise you wouldn't be saying the things you are. I have better things to do then waste my time or yours posting here & trying to get help with a problem that has been going on within RO for some time now & I'm not the only one that has this problem. There are many users that have been having problems with Time Gap Errors for quite some time. Most don't take the time to say anything about it however I made a post awhile back in the Forum just to make sure that I wasn't alone.

What do you think the point of the logs is? Just because I can't see your computer doesn't mean I can't tell that you posted a capture of the char server that one time (or that you have TCPAckFrequency=1, or that you don't use IPv4 checksum offloading...)

If you can't or don't want to help me then that's okay. There is no reason to post messages that are unhelpful though. I am here for help not to waste my time or anyone else's.

Correcting a misreading of the logs was unhelpful? Suggesting that you check your clock and run WinDump was unhelpful? I really don't know what to say to that.

---

Brief Overview of Time Gaps

When a client logs in to a zone server, it reports the result of the Windows API function "GetTickCount." It also does this subsequently at regular intervals. If at any time the tick deviates from what the server expects (given the initial difference) by more than 60000 milliseconds, the server sends the time gap message and the client closes the connection. This is what happened here and here.

There are several ways this situation can arise: server overloading (anyone who's been around long enough can remember at least one instance in which everything froze and eventually resumed with a time gap) and network problems are two possibilities. We can safely rule out the first, and from the two posts I linked it's obvious that the network isn't at fault (at least in those cases).

At this point I would ordinarily propose further tests to pinpoint the exact cause. However, since you obviously don't want my help and just want to "stand up . . . to experts," I'll leave it at this.

[Razzez]

I already know from your numerous posts that you are suffering from time gaps. Also, I wasn't telling you. I was telling Javsy--because his interpretation was incorrect.

I apologize for misreading that then.

If you're referring to this post, it shows a 2.5-second character server connection exactly as I described. I noticed that you didn't dispute any of the facts I listed.

I didn't know which log you were referring to. That was my first log & the only full log I posted. You are correct.

The facts you listed, that I disputed, were #3 & #5, since nothing I posted had to do with me logging off myself. Everything I have posted has been because of a Time Gap error regardless of how it has "appeared" in the log. That was all I was trying to say.

The IP does matter for the purpose of capturing packet headers from the server that you're connected to at the moment you time gap. (Of course that's only true if you're filtering by IP instead of the net/mask I originally posted.)

I understand this now. I didn't before which is why I asked if it was different when doing an tracert versus using windump since I have never used windump up till now.

What do you think the point of the logs is? Just because I can't see your computer doesn't mean I can't tell that you posted a capture of the char server that one time (or that you have TCPAckFrequency=1, or that you don't use IPv4 checksum offloading...)

That wasn't what I meant. I only was referring to when you said that I was disconnecting on my own according to the logs. I was just trying to clarify that I wasn't & that the only time I was being disconnected was due to the Time Gaps.

Correcting a misreading of the logs was unhelpful? Suggesting that you check your clock and run WinDump was unhelpful? I really don't know what to say to that.

I'm not sure, when I ever referred to checking my clock, or when this was even discussed. I only recall something being said to the effect that clock errors could be one of the problems.

Brief Overview of Time Gaps

When a client logs in to a zone server, it reports the result of the Windows API function "GetTickCount." It also does this subsequently at regular intervals. If at any time the tick deviates from what the server expects (given the initial difference) by more than 60000 milliseconds, the server sends the time gap message and the client closes the connection. This is what happened here and here.

There are several ways this situation can arise: server overloading (anyone who's been around long enough can remember at least one instance in which everything froze and eventually resumed with a time gap) and network problems are two possibilities. We can safely rule out the first, and from the two posts I linked it's obvious that the network isn't at fault (at least in those cases).

At this point I would ordinarily propose further tests to pinpoint the exact cause. However, since you obviously don't want my help and just want to "stand up . . . to experts," I'll leave it at this.

This information really helps explain a lot more to me. I'm glad to hear you agree that I don't have network problems since that is what I have been saying all along.

Just to clarify things I think there has been some misunderstandings between all of us. For instance I never said I DIDN'T want your help. I do very much. That's why I am posting as much information as I can here. I may say the wrong things or use the wrong words at times but that doesn't change the fact that I do need help.

I am technical savvy & learn things I am not familiar with pretty quick. I said from the start that windump is one program I have never used before so please be patient with me while I am learning to use it. I believe I am & have gotten the idea of how it works so far fairly fast. Like anything else, working with something new takes a little time to learn. So please don't take things the wrong way if I say I'm confused, don't understand and/or question something.

I really hope you understand where I am coming from.