I've been doing some traces to try to determine why my users are seeing "xxx.gov.uk not responding" messages at irregular intervals for a business application. I see the pattern (in terms of trace records) below in virtually every case where my users see a 2 minute delay. Can anyone shed any light on why the PC (Win7) appears to suddenly start contacting lots of time servers? There is a significant delay before the first contact at record 60403 and then before each succeeding 7 requests - sometimes there are less requests but the total elapsed time of the TCP packet stream is always approximately 120 seconds! Can anyone hazzard a guess at why I am seeing this behaviour? Thanks for any suggestions.
No. Time Source Destination Protocol Length Info 60386 15:18:29.29 192.168.0.6 195.225.188.193 TCP 66 51749 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 60387 15:18:29.29 192.168.0.6 195.225.188.193 TCP 66 51750 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 60388 15:18:29.29 195.225.188.193 192.168.0.6 TCP 66 https > 51749 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1418 SACK_PERM=1 WS=128 60389 15:18:29.29 192.168.0.6 195.225.188.193 TCP 54 51749 > https [ACK] Seq=1 Ack=1 Win=66644 Len=0 60390 15:18:29.29 192.168.0.6 195.225.188.193 TLSv1 222 Client Hello 60391 15:18:29.29 195.225.188.193 192.168.0.6 TCP 66 https > 51750 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1418 SACK_PERM=1 WS=128 60392 15:18:29.29 192.168.0.6 195.225.188.193 TCP 54 51750 > https [ACK] Seq=1 Ack=1 Win=66644 Len=0 60393 15:18:29.29 192.168.0.6 195.225.188.193 TLSv1 222 Client Hello 60394 15:18:30.30 195.225.188.193 192.168.0.6 TCP 60 https > 51749 [ACK] Seq=1 Ack=169 Win=6912 Len=0 60395 15:18:30.30 195.225.188.193 192.168.0.6 TLSv1 199 Server Hello, Change Cipher Spec, Encrypted Handshake Message 60396 15:18:30.30 192.168.0.6 195.225.188.193 TLSv1 113 Change Cipher Spec, Encrypted Handshake Message 60397 15:18:30.30 195.225.188.193 192.168.0.6 TCP 60 https > 51750 [ACK] Seq=1 Ack=169 Win=6912 Len=0 60398 15:18:30.30 195.225.188.193 192.168.0.6 TLSv1 199 Server Hello, Change Cipher Spec, Encrypted Handshake Message 60399 15:18:30.30 192.168.0.6 195.225.188.193 TLSv1 113 Change Cipher Spec, Encrypted Handshake Message 60400 15:18:30.30 192.168.0.6 195.225.188.193 TLSv1 784 Application Data, Application Data 60401 15:18:30.30 195.225.188.193 192.168.0.6 TCP 60 https > 51750 [ACK] Seq=146 Ack=958 Win=8448 Len=0 60402 15:18:30.30 195.225.188.193 192.168.0.6 TCP 60 https > 51749 [ACK] Seq=146 Ack=228 Win=6912 Len=0 60403 15:18:56.56 192.168.0.6 178.79.149.162 NTP 90 NTP Version 4, client 60404 15:18:56.56 178.79.149.162 192.168.0.6 NTP 90 NTP Version 4, server 60405 15:19:04.04 192.168.0.6 213.229.82.130 NTP 90 NTP Version 4, client 60406 15:19:04.04 213.229.82.130 192.168.0.6 NTP 90 NTP Version 4, server 60407 15:19:13.13 192.168.0.6 109.74.206.120 NTP 90 NTP Version 4, client 60408 15:19:13.13 109.74.206.120 192.168.0.6 NTP 90 NTP Version 4, server 60409 15:19:18.18 Dell_ae:ac:2d Netgear_5b:d9:ee ARP 42 Who has 192.168.0.1? Tell 192.168.0.6 (duplicate use of 192.168.0.6 detected!) 60410 15:19:18.18 Netgear_5b:d9:ee Dell_ae:ac:2d ARP 60 192.168.0.1 is at 00:22:3f:5b:d9:ee (duplicate use of 192.168.0.6 detected!) 60411 15:19:23.23 192.168.0.6 85.119.80.232 NTP 90 NTP Version 4, client 60412 15:19:23.23 85.119.80.232 192.168.0.6 NTP 90 NTP Version 4, server 60413 15:19:28.28 Netgear_5b:d9:ee Dell_ae:ac:2d ARP 60 Who has 192.168.0.6? Tell 192.168.0.1 60414 15:19:28.28 Dell_ae:ac:2d Netgear_5b:d9:ee ARP 42 192.168.0.6 is at 00:1e:4f:ae:ac:2d 60415 15:20:00.00 192.168.0.6 178.79.149.162 NTP 90 NTP Version 4, client 60416 15:20:00.00 178.79.149.162 192.168.0.6 NTP 90 NTP Version 4, server 60417 15:20:05.05 Dell_ae:ac:2d Netgear_5b:d9:ee ARP 42 Who has 192.168.0.1? Tell 192.168.0.6 (duplicate use of 192.168.0.6 detected!) 60418 15:20:05.05 Netgear_5b:d9:ee Dell_ae:ac:2d ARP 60 192.168.0.1 is at 00:22:3f:5b:d9:ee (duplicate use of 192.168.0.6 detected!) 60419 15:20:07.07 192.168.0.6 213.229.82.130 NTP 90 NTP Version 4, client 60420 15:20:07.07 213.229.82.130 192.168.0.6 NTP 90 NTP Version 4, server 60421 15:20:12.12 Netgear_5b:d9:ee Dell_ae:ac:2d ARP 60 Who has 192.168.0.6? Tell 192.168.0.1 60422 15:20:12.12 Dell_ae:ac:2d Netgear_5b:d9:ee ARP 42 192.168.0.6 is at 00:1e:4f:ae:ac:2d 60423 15:20:17.17 192.168.0.6 109.74.206.120 NTP 90 NTP Version 4, client 60424 15:20:17.17 109.74.206.120 192.168.0.6 NTP 90 NTP Version 4, server 60425 15:20:26.26 192.168.0.6 85.119.80.232 NTP 90 NTP Version 4, client 60426 15:20:26.26 85.119.80.232 192.168.0.6 NTP 90 NTP Version 4, server 60427 15:20:30.30 195.225.188.193 192.168.0.6 TLSv1 91 Encrypted Alert 60428 15:20:30.30 195.225.188.193 192.168.0.6 TCP 60 https > 51749 [FIN, ACK] Seq=183 Ack=228 Win=6912 Len=0 60429 15:20:30.30 192.168.0.6 195.225.188.193 TCP 54 51749 > https [ACK] Seq=228 Ack=184 Win=66464 Len=0 60430 15:20:30.30 195.225.188.193 192.168.0.6 TLSv1 848 Application Data, Application Data 60431 15:20:30.30 192.168.0.6 195.225.188.193 TCP 54 51750 > https [FIN, ACK] Seq=958 Ack=940 Win=65704 Len=0 60432 15:20:30.30 195.225.188.193 192.168.0.6 TCP 60 https > 51750 [FIN, ACK] Seq=940 Ack=958 Win=8448 Len=0 60433 15:20:30.30 192.168.0.6 195.225.188.193 TCP 54 51750 > https [ACK] Seq=959 Ack=941 Win=65704 Len=0 60434 15:20:30.30 192.168.0.6 195.225.188.193 TCP 54 51749 > https [RST, ACK] Seq=228 Ack=184 Win=0 Len=0
asked 27 Jun '12, 15:40
Bernard46
1●3●3●4
accept rate: 0%
You're right in that it does not look good. However we have only seen this since we changed the router form a D-Link to a Netgear one, so perhaps it is something to do with the way the router is behaving. I believe I set up both routers in an absolute standard way.
Leaving aside this point just for a moment we still see the NTP requests and the delays in earlier and indeed later parts of the trace where there is no mention of duplicate IP addresses. Incidentally there are only 5 PCs on this LAN - 4 wired and 1 wireless so I don't understand the duplicate IP address messages at all.
Any thoughts on the multiple NTP records - the client PC here is 7 minutes ahead of UTC time - I don;t understand why it does not get back in sync with UTC, or whether this difference in time could cause some problems with the encryption regime.
regards, Bernard
If this is related to your other question, please see my answer there.
BTW: If you think the NTP requests of the client are somehow related to the problem, please post a full capture file with several of those "events".