JHD's possible answers to CM50123 coursework 2. I've put most of the effort into part (a), and briefly sketched answers to (b) and (c) at the end. It was perfectly OK to write more on (b) and (c) and less on (a). Features we might see. ARP for router and DNS for web site (which are connected) This was the ARP at 15:07:52.683549. For the earlier ARP from 172.16.112.3 at 15:07:30.720247, we don't see the reply as it's unicast. Initial 3-way open (incl WSCALE, SACKOK), noting that the far end's option packing is sub-optimal. Absence of DF (as shown) Absence of Nagle comment on 1368 as segment size (which contradicts RFC 1122, since we should use 1380) absence of delayed ACKs (at least by the amount expected!) from either end 15:08:01.186552 and its successors show two arriving at us before an ACK is sent, but this is not always the case (see .727369 et seq., or 15:08:00.024781/025361). One could argue that there is a delay between receipt at 15:08:00.311692/ 979 and the ACK at .351203, but the delay isn't much, and as it is ACKing two packets it shouldn't be delayed, so I suspect this is just busy-ness on our part. At least from 15:08:01 onwards, we are sending timestamps, but not getting any in reply, so they're useless. But we now seem to be delaying ACKs - curious causality, if such it be. Comments on win size at our end RST with timestamps/windows - no explanation of the reset (I can't think of one either) ARP at 15:08:06.229850 (cache on router) Nothing seems to happen as a consequence of DNS at 15:08:07:659950, which is the last "interesting" event. Some candidates got really rather confused about delayed ACKs, and complained that 172.16.2.1 wasn't responding to packets, when in fact it was merely delaying ACKs. Not all candidates appreciated the round-trip time, around 140ms. 172.16.2.1 seems to have a broken window size: confusion between WIN and CWIN is the only plausible explanation. Reading the description of its TCP, this says "window" when it clearly (to me) means cwin. UNFORTUNATELY, several students were confused by this, and described slow start as if they were seeing cwin rather than window. To repeat, cwin is NOT directly seen on the wire. 128.186.6.14 advertises an MSS of 1380 (1500-60-60), but sends packets of size 1368=1380-12 until such time as it stops sending the timestamp. 172.16.2.1 continues sending the timestamp even after 128.186.6.14 has stopped, and hence they are useless. After a while it stops, and sets the window down to 0. Only some evidence of delayed ACKs: certainly not in place at our end: it SEEMS to be that delayed ACKs and timestamps are mutually exclusive. No evidence of path MTU discovery, which seems pretty primitive, but RJB points out that (undocumented) that this TCPdump doesn't show DF. The evidence from 15:08:02.140376 is that the far end has disabled Nagle. 128.186.6.14 seems to have slow start with an opening value of three segments 172.16.2.1 goes into 'reset' mode after a while on connection 45242, but continues to send timestamps, even though the other end isn't. SackOK in both directions, but no actual SACKs observed. Wscale in both directions on all connections. Most people forgot to allow for this. Script started on Fri 16 Mar 2007 15:07:22 GMT tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:07:30.720247 arp who-has 172.16.0.1 tell 172.16.112.3 Extraneous (to us) ARPing 15:07:33.891942 IP 172.16.2.1.45982248 > 172.16.0.3.2049: 120 getattr [|nfs] 15:07:33.892140 IP 172.16.0.3.2049 > 172.16.2.1.45982248: reply ok 116 getattr [|nfs] Random NFS traffic above 15:07:33.892169 IP 172.16.2.1.1022 > 172.16.0.3.2049: . ack 840531559 win 32739 An ACK of ??, possibly NFS mount in view of the fact that its a reserved port 15:07:33.892457 IP 172.16.2.1.62759464 > 172.16.0.3.2049: 124 access [|nfs] 15:07:33.892828 IP 172.16.0.3.2049 > 172.16.2.1.62759464: reply ok 124 access [|nfs] Random NFS traffic above (but what is the port number? >65535!) 15:07:33.932862 IP 172.16.2.1.1022 > 172.16.0.3.2049: . ack 125 win 32768 Another ACK of ??, note that sequence numbers are now relative 15:07:36.421646 arp who-has 172.16.128.22 tell 172.16.0.1 Extraneous ARPing 15:07:52.683549 arp who-has 172.16.0.1 tell 172.16.2.1 15:07:52.683689 arp reply 172.16.0.1 is-at 00:0e:0c:bd:36:5a We ARPed, and got a reply: presumably so that we can send the next packet.Not everyone got the causality here. 15:07:58.770969 IP 172.16.2.1.43862 > 138.38.108.3.53: 28394+ A? www.fsu.edu. (29) 15:07:59.031483 IP 138.38.108.3.53 > 172.16.2.1.43862: 28394 1/5/4 A 128.186.6.14 (217) DNS Query/response for FSU 15:07:59.031738 IP 172.16.2.1.45242 > 128.186.6.14.80: S 1577674907:1577674907(0) win 5840 15:07:59.165677 IP 128.186.6.14.80 > 172.16.2.1.45242: S 1769524229:1769524229(0) ack 1577674908 win 49248 15:07:59.165722 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 1 win 1460 A 3way open. Both sides exchange SACKOK, so this is enabled. Both sides exchange WSCALE, so this is enabled. Both sides are using timestamps. The MSS, though different (1380/1460), are both sensible. Note that our window is now 1460: apparently down from the 5860 advertised earlier, but we now know that the other end understands our scaling (by a factor of 2 bits, i.e. times 4) and in fact 1460<<2=5860 Oddly enough, neither side makes any use of DF (path MTU) but this tcpdump MAY not be showing it. 15:07:59.165939 IP 172.16.2.1.45242 > 128.186.6.14.80: P 1:396(395) ack 1 win 1460 We send some data (probably HTTP's GET and associated stuff) 15:07:59.299833 IP 128.186.6.14.80 > 172.16.2.1.45242: . ack 396 win 48853 And it's acknowledged, almost certainly not delayed 15:07:59.314350 IP 128.186.6.14.80 > 172.16.2.1.45242: . 1:1369(1368) ack 396 win 49248 Data come barrelling back. We were unlucky (?) that the delayed ACK mechanism didn't combine the two, as (at this end, admittedly) only 0.015 seconds apart. Odd that the WIN has gone back up by the data length sent by us, since those data were presumably read by the application in order to generate this response. Hence the first ACK was almost certainly not delayed. 15:07:59.314384 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 1369 win 2144 We ACK it immediately (so no delayed ACKs here) and our window goes up by 2144-1460=684, which means (WSCALE=2) 2736=1368*2: looks like a bastard 'slow start' increasing by 2*SEG even though we don't have two distinct ACKs, but the same ACK twice (once with data). Anyway, slow start should only affect CWIN, which we don't see on the wire, rather than WIN. 15:07:59.314480 IP 128.186.6.14.80 > 172.16.2.1.45242: . 1369:2737(1368) ack 396 win 49248 More data, so soon after the first that this must have been sent before our ACK arrived. Again 1368 bytes. I can only assume that the moron who wrote their ode is deducting 12 for the timestamp option, despite the fact that it's allowed for in the 1500-1380=2*60 headers allowance. 15:07:59.314496 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 2737 win 2828 ACK it, and WIN again goes up by two segments! 15:07:59.314599 IP 128.186.6.14.80 > 172.16.2.1.45242: P 2737:4105(1368) ack 396 win 49248 15:07:59.314613 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 4105 win 3512 ACK it, and WIN again goes up by two segments! Very clearly delayed ACK is not in use by 172.16.2.1 15:07:59.330767 IP 172.16.2.1.45243 > 128.186.6.14.80: S 1576501183:1576501183(0) win 5840 The first part of a 3-way open to 45243. 15:07:59.448783 IP 128.186.6.14.80 > 172.16.2.1.45242: . 4105:5473(1368) ack 396 win 49248 More data to port 45242: sufficiently much later that we can assume our ACK has got there and triggered more sending, so slow start (starting at three segments) seems to be in place at 128.186.6.14. 15:07:59.448823 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 5473 win 4196 15:07:59.448900 IP 128.186.6.14.80 > 172.16.2.1.45242: P 5473:6841(1368) ack 396 win 49248 15:07:59.448917 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 6841 win 4880 15:07:59.449027 IP 128.186.6.14.80 > 172.16.2.1.45242: . 6841:8209(1368) ack 396 win 49248 15:07:59.449041 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 8209 win 5564 15:07:59.449150 IP 128.186.6.14.80 > 172.16.2.1.45242: P 8209:9577(1368) ack 396 win 49248 15:07:59.449163 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 9577 win 6248 15:07:59.449236 IP 128.186.6.14.80 > 172.16.2.1.45242: P 9577:10567(990) ack 396 win 49248 15:07:59.449252 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 10567 win 6932 Four more packets of data and their ACKs from us. 15:07:59.464740 IP 128.186.6.14.80 > 172.16.2.1.45243: S 3258806187:3258806187(0) ack 1576501184 win 49248 15:07:59.464800 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 1 win 1460 The rest of the 3-way open. 15:07:59.464912 IP 172.16.2.1.45243 > 128.186.6.14.80: P 1:378(377) ack 1 win 1460 45243 sends data 15:07:59.598415 IP 128.186.6.14.80 > 172.16.2.1.45243: . ack 378 win 48871 The ACK of our data. 15:07:59.602593 IP 128.186.6.14.80 > 172.16.2.1.45243: P 1:270(269) ack 378 win 49248 And the first chunk of the reply: clearly no delayed ACKs here! 15:07:59.602619 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 270 win 1728 We ACK, and window goes up by 268 = 1 SEG (but WSCALE=2!) 15:07:59.602816 IP 128.186.6.14.80 > 172.16.2.1.45243: . 270:1638(1368) ack 378 win 49248 15:07:59.602835 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 1638 win 2412 Data (1368 again) and ACK (window up by 2 SEG!) 15:07:59.602938 IP 128.186.6.14.80 > 172.16.2.1.45243: . 1638:3006(1368) ack 378 win 49248 15:07:59.602957 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 3006 win 3096 Data (1368 again) and ACK (window up by 2 SEG!) 15:07:59.602963 IP 128.186.6.14.80 > 172.16.2.1.45243: P 3006:3038(32) ack 378 win 49248 15:07:59.602973 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 3038 win 3096 Data and ACK, and window goes up by 32 = 1 SEG (but WSCALE=2!) 15:07:59.609956 IP 172.16.2.1.45242 > 128.186.6.14.80: P 396:770(374) ack 10567 win 6932 After 150 msec, 45242 becomes active again. Looks as though we may be getting a new page, in view of the fact that we send data 15:07:59.743580 IP 128.186.6.14.80 > 172.16.2.1.45242: . ack 770 win 49248 Pretty clearly not a delayed ACK. 128.186.6.14 has stopped sending timestamps on this connection, even though 172.16.2.1 is still sending them, pointlessly. 15:07:59.745256 IP 128.186.6.14.80 > 172.16.2.1.45242: P 10567:10836(269) ack 770 win 49248 15:07:59.745280 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 10836 win 6932 An odd-sized chunk of data and its ACK: WIN doesn't change 15:07:59.745613 IP 128.186.6.14.80 > 172.16.2.1.45242: . 10836:12216(1380) ack 770 win 49248 Now hat it's not using timestamps, 128.186.6.14 uses 1380-sized segments: further evidence that its handling of timestamps/MSS is broken 15:07:59.745658 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 12216 win 7622 In our ack the WIN goes up by 690*4=1380+1380. 15:07:59.745770 IP 128.186.6.14.80 > 172.16.2.1.45242: . 12216:13596(1380) ack 770 win 49248 15:07:59.745792 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 13596 win 8312 15:07:59.745881 IP 128.186.6.14.80 > 172.16.2.1.45242: . 13596:14976(1380) ack 770 win 49248 15:07:59.745996 IP 128.186.6.14.80 > 172.16.2.1.45242: P 14976:16354(1378) ack 770 win 49248 15:07:59.746016 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 16354 win 8312 Two data segments before 172.16.2.1 gets an ACK out. The WIN doesn't change, presumably the effect of bungled slow start (which shouldn't affect WIN, only CWIN) is cancelled by the fact that these data are still in the buffer. 15:07:59.750897 IP 172.16.2.1.45243 > 128.186.6.14.80: P 378:753(375) ack 3038 win 3096 Now We send more data on 45243: presumably a fresh GET 15:07:59.885019 IP 128.186.6.14.80 > 172.16.2.1.45243: . ack 753 win 49248 15:07:59.885926 IP 128.186.6.14.80 > 172.16.2.1.45243: P 3038:3306(268) ack 753 win 49248 Almost certainly non-delayed ACK, followed by data. Note that the far end has now stopped using timestamps on 45243 15:07:59.885952 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 3306 win 3096 15:07:59.885989 IP 128.186.6.14.80 > 172.16.2.1.45243: P 3306:3771(465) ack 753 win 49248 This packet, coming so close after the previous one, implies no Nagle. 15:07:59.886001 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 3771 win 3780 15:07:59.890598 IP 172.16.2.1.45242 > 128.186.6.14.80: P 770:1103(333) ack 16354 win 8312 15:07:59.894289 IP 172.16.2.1.45243 > 128.186.6.14.80: P 753:1109(356) ack 3771 win 3780 Fresh requests on 45242 and 45243 15:08:00.024638 IP 128.186.6.14.80 > 172.16.2.1.45242: P 16354:16806(452) ack 1103 win 49248 15:08:00.024781 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 16806 win 8312 15:08:00.025361 IP 172.16.2.1.45242 > 128.186.6.14.80: P 1103:1509(406) ack 16806 win 8312 Data to 45242 followed by 45242 sending more data. Odd? 15:08:00.029490 IP 128.186.6.14.80 > 172.16.2.1.45243: P 3771:4057(286) ack 1109 win 49248 15:08:00.029949 IP 128.186.6.14.80 > 172.16.2.1.45243: . 4057:5437(1380) ack 1109 win 49248 15:08:00.030000 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 5437 win 4470 15:08:00.030075 IP 128.186.6.14.80 > 172.16.2.1.45243: . 5437:6817(1380) ack 1109 win 49248 15:08:00.030196 IP 128.186.6.14.80 > 172.16.2.1.45243: . 6817:8197(1380) ack 1109 win 49248 15:08:00.030214 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 8197 win 5850 Two data packets and an ACK: WIN up by 1380*4. 15:08:00.030252 IP 128.186.6.14.80 > 172.16.2.1.45243: P 8197:8695(498) ack 1109 win 49248 15:08:00.035804 IP 172.16.2.1.45243 > 128.186.6.14.80: P 1109:1473(364) ack 8695 win 5850 More on 45243, then back to 45242 15:08:00.159651 IP 128.186.6.14.80 > 172.16.2.1.45242: P 16806:17079(273) ack 1509 win 49248 15:08:00.160133 IP 128.186.6.14.80 > 172.16.2.1.45242: . 17079:18459(1380) ack 1509 win 49248 15:08:00.160185 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 18459 win 8312 Two data packets and an ACK on 45242. 15:08:00.160194 IP 128.186.6.14.80 > 172.16.2.1.45242: P 18459:18485(26) ack 1509 win 49248 15:08:00.170525 IP 128.186.6.14.80 > 172.16.2.1.45243: P 8695:8979(284) ack 1473 win 49248 15:08:00.171163 IP 128.186.6.14.80 > 172.16.2.1.45243: P 8979:9352(373) ack 1473 win 49248 Two small packets in rapid succession violates Nagle, and possibly SWS. 15:08:00.176815 IP 172.16.2.1.45242 > 128.186.6.14.80: P 1509:1874(365) ack 18485 win 8312 15:08:00.210220 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 9352 win 5850 15:08:00.311692 IP 128.186.6.14.80 > 172.16.2.1.45242: P 18485:18770(285) ack 1874 win 49248 15:08:00.311979 IP 128.186.6.14.80 > 172.16.2.1.45242: P 18770:19846(1076) ack 1874 win 49248 15:08:00.316463 IP 172.16.2.1.45243 > 128.186.6.14.80: P 1473:1834(361) ack 9352 win 5850 15:08:00.351203 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 19846 win 8312 This ACK on 45242 took 0.035 seconds to get out, longer than some, especially as it is acking two packets (.311692 and .311979) and therefore should not be delayed. 15:08:00.451242 IP 128.186.6.14.80 > 172.16.2.1.45243: P 9352:9637(285) ack 1834 win 49248 15:08:00.451363 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 9637 win 5850 This ACK seems not to be delayed. 15:08:00.451710 IP 128.186.6.14.80 > 172.16.2.1.45243: . 9637:11017(1380) ack 1834 win 49248 15:08:00.451744 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 11017 win 6540 15:08:00.451840 IP 128.186.6.14.80 > 172.16.2.1.45243: . 11017:12397(1380) ack 1834 win 49248 15:08:00.451865 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 12397 win 7230 15:08:00.451964 IP 128.186.6.14.80 > 172.16.2.1.45243: . 12397:13777(1380) ack 1834 win 49248 15:08:00.451986 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 13777 win 7920 15:08:00.452095 IP 128.186.6.14.80 > 172.16.2.1.45243: . 13777:15157(1380) ack 1834 win 49248 15:08:00.452127 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 15157 win 8610 15:08:00.452197 IP 128.186.6.14.80 > 172.16.2.1.45243: P 15157:16359(1202) ack 1834 win 49248 15:08:00.453334 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 16359 win 8610 Quite a bit of data flowing into 45243 15:08:00.469850 IP 172.16.2.1.45242 > 128.186.6.14.80: P 1874:2245(371) ack 19846 win 8312 15:08:00.605404 IP 128.186.6.14.80 > 172.16.2.1.45242: P 19846:20131(285) ack 2245 win 49248 We send, and have ACKed and replied to, data on 45242 15:08:00.605507 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 20131 win 8312 15:08:00.605906 IP 128.186.6.14.80 > 172.16.2.1.45242: . 20131:21511(1380) ack 2245 win 49248 15:08:00.606020 IP 128.186.6.14.80 > 172.16.2.1.45242: . 21511:22891(1380) ack 2245 win 49248 15:08:00.606044 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 22891 win 8312 15:08:00.606065 IP 128.186.6.14.80 > 172.16.2.1.45242: P 22891:23364(473) ack 2245 win 49248 15:08:00.606149 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 23364 win 8312 The window on 45242 seems to have stopped growing. 15:08:00.612468 IP 172.16.2.1.45243 > 128.186.6.14.80: P 1834:2198(364) ack 16359 win 8610 15:08:00.747573 IP 128.186.6.14.80 > 172.16.2.1.45243: P 16359:16643(284) ack 2198 win 49248 15:08:00.747674 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 16643 win 8610 15:08:00.747718 IP 128.186.6.14.80 > 172.16.2.1.45243: P 16643:17021(378) ack 2198 win 49248 15:08:00.747788 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 17021 win 8610 A couple of transactions on 45243. 15:08:00.776775 IP 172.16.2.1.45242 > 128.186.6.14.80: P 2245:2624(379) ack 23364 win 8312 15:08:00.779947 IP 172.16.2.1.45243 > 128.186.6.14.80: P 2198:2581(383) ack 17021 win 8610 We send data on both 15:08:00.911981 IP 128.186.6.14.80 > 172.16.2.1.45242: P 23364:23635(271) ack 2624 win 49248 15:08:00.912187 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 23635 win 8312 15:08:00.912337 IP 128.186.6.14.80 > 172.16.2.1.45242: . 23635:25015(1380) ack 2624 win 49248 15:08:00.912452 IP 128.186.6.14.80 > 172.16.2.1.45242: . 25015:26395(1380) ack 2624 win 49248 15:08:00.912469 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 26395 win 8312 15:08:00.912579 IP 128.186.6.14.80 > 172.16.2.1.45242: . 26395:27775(1380) ack 2624 win 49248 15:08:00.912644 IP 128.186.6.14.80 > 172.16.2.1.45242: P 27775:28528(753) ack 2624 win 49248 15:08:00.912656 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 28528 win 8312 15:08:00.913095 IP 172.16.2.1.45242 > 128.186.6.14.80: P 2624:2999(375) ack 28528 win 8312 Data/ACKs on 45242. 15:08:00.914227 IP 128.186.6.14.80 > 172.16.2.1.45243: P 17021:17292(271) ack 2581 win 49248 15:08:00.915331 IP 128.186.6.14.80 > 172.16.2.1.45243: . 17292:18672(1380) ack 2581 win 49248 15:08:00.915400 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 18672 win 8610 15:08:00.915449 IP 128.186.6.14.80 > 172.16.2.1.45243: . 18672:20052(1380) ack 2581 win 49248 15:08:00.915574 IP 128.186.6.14.80 > 172.16.2.1.45243: . 20052:21432(1380) ack 2581 win 49248 15:08:00.915586 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 21432 win 8610 15:08:00.915648 IP 128.186.6.14.80 > 172.16.2.1.45243: P 21432:22291(859) ack 2581 win 49248 15:08:00.917735 IP 172.16.2.1.45243 > 128.186.6.14.80: P 2581:2955(374) ack 22291 win 8610 Data/ACKs on 45243. 15:08:00.924109 IP 172.16.2.1.213754408 > 172.16.0.3.2049: 120 getattr [|nfs] 15:08:00.924304 IP 172.16.0.3.2049 > 172.16.2.1.213754408: reply ok 116 getattr [|nfs] Lots more NFS removed 15:08:01.048150 IP 128.186.6.14.80 > 172.16.2.1.45242: P 28528:28797(269) ack 2999 win 49248 15:08:01.048188 IP 128.186.6.14.80 > 172.16.2.1.45242: P 28797:29154(357) ack 2999 win 49248 15:08:01.048498 IP 172.16.2.1.45242 > 128.186.6.14.80: P 2999:3458(459) ack 29154 win 8312 45242 has come alive again. 15:08:01.052768 IP 128.186.6.14.80 > 172.16.2.1.45243: P 22291:22561(270) ack 2955 win 49248 15:08:01.053634 IP 128.186.6.14.80 > 172.16.2.1.45243: . 22561:23941(1380) ack 2955 win 49248 15:08:01.053673 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 23941 win 8610 15:08:01.053712 IP 128.186.6.14.80 > 172.16.2.1.45243: P 23941:24904(963) ack 2955 win 49248 15:08:01.054162 IP 172.16.2.1.45243 > 128.186.6.14.80: P 2955:3359(404) ack 24904 win 8610 As does 45243 15:08:01.183579 IP 128.186.6.14.80 > 172.16.2.1.45242: P 29154:29447(293) ack 3458 win 49248 15:08:01.184307 IP 128.186.6.14.80 > 172.16.2.1.45242: . 29447:30827(1380) ack 3458 win 49248 15:08:01.184347 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 30827 win 8312 15:08:01.184424 IP 128.186.6.14.80 > 172.16.2.1.45242: . 30827:32207(1380) ack 3458 win 49248 15:08:01.184553 IP 128.186.6.14.80 > 172.16.2.1.45242: . 32207:33587(1380) ack 3458 win 49248 15:08:01.184570 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 33587 win 8312 15:08:01.184706 IP 128.186.6.14.80 > 172.16.2.1.45242: . 33587:34967(1380) ack 3458 win 49248 15:08:01.184822 IP 128.186.6.14.80 > 172.16.2.1.45242: . 34967:36347(1380) ack 3458 win 49248 15:08:01.184837 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 36347 win 8312 15:08:01.184932 IP 128.186.6.14.80 > 172.16.2.1.45242: P 36347:37639(1292) ack 3458 win 49248 15:08:01.185054 IP 128.186.6.14.80 > 172.16.2.1.45242: . 37639:39019(1380) ack 3458 win 49248 15:08:01.185077 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 39019 win 8312 15:08:01.185166 IP 128.186.6.14.80 > 172.16.2.1.45242: . 39019:40399(1380) ack 3458 win 49248 15:08:01.185282 IP 128.186.6.14.80 > 172.16.2.1.45242: . 40399:41779(1380) ack 3458 win 49248 15:08:01.185297 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 41779 win 8312 15:08:01.185399 IP 128.186.6.14.80 > 172.16.2.1.45242: . 41779:43159(1380) ack 3458 win 49248 15:08:01.185514 IP 128.186.6.14.80 > 172.16.2.1.45242: . 43159:44539(1380) ack 3458 win 49248 15:08:01.185528 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 44539 win 8312 15:08:01.185625 IP 128.186.6.14.80 > 172.16.2.1.45242: P 44539:45831(1292) ack 3458 win 49248 15:08:01.185741 IP 128.186.6.14.80 > 172.16.2.1.45242: . 45831:47211(1380) ack 3458 win 49248 15:08:01.185759 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 47211 win 8312 15:08:01.185861 IP 128.186.6.14.80 > 172.16.2.1.45242: . 47211:48591(1380) ack 3458 win 49248 15:08:01.185973 IP 128.186.6.14.80 > 172.16.2.1.45242: . 48591:49971(1380) ack 3458 win 49248 15:08:01.185988 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 49971 win 8312 15:08:01.186091 IP 128.186.6.14.80 > 172.16.2.1.45242: . 49971:51351(1380) ack 3458 win 49248 15:08:01.186208 IP 128.186.6.14.80 > 172.16.2.1.45242: . 51351:52731(1380) ack 3458 win 49248 15:08:01.186223 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 52731 win 8312 15:08:01.186318 IP 128.186.6.14.80 > 172.16.2.1.45242: P 52731:54023(1292) ack 3458 win 49248 15:08:01.186435 IP 128.186.6.14.80 > 172.16.2.1.45242: . 54023:55403(1380) ack 3458 win 49248 15:08:01.186450 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 55403 win 8312 15:08:01.186552 IP 128.186.6.14.80 > 172.16.2.1.45242: . 55403:56783(1380) ack 3458 win 49248 15:08:01.186666 IP 128.186.6.14.80 > 172.16.2.1.45242: . 56783:58163(1380) ack 3458 win 49248 15:08:01.186701 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 58163 win 8312 15:08:01.186850 IP 128.186.6.14.80 > 172.16.2.1.45242: . 58163:59543(1380) ack 3458 win 49248 A lot of 45242: the WIN definitely seems to have frozen 15:08:01.189085 IP 128.186.6.14.80 > 172.16.2.1.45243: P 24904:25243(339) ack 3359 win 49248 15:08:01.189657 IP 172.16.2.1.45243 > 128.186.6.14.80: P 3359:3760(401) ack 25243 win 8610 Now 45243 comes alive 15:08:01.226055 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 59543 win 8312 15:08:01.318224 IP 128.186.6.14.80 > 172.16.2.1.45242: . 59543:60923(1380) ack 3458 win 49248 15:08:01.318328 IP 128.186.6.14.80 > 172.16.2.1.45242: . 60923:62215(1292) ack 3458 win 49248 15:08:01.318346 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 62215 win 8312 15:08:01.318475 IP 128.186.6.14.80 > 172.16.2.1.45242: . 62215:63595(1380) ack 3458 win 49248 More traffic on 45242, but ... 15:08:01.318537 IP 172.16.2.1.45242 > 128.186.6.14.80: R 3458:3458(0) ack 63595 win 8312 We send a RESET (it's pretty pointless to send a timestamp with a reset, but programmers can be idle at times!). Note that a RESET is NOT a half-close, or a retransmission - several got this wrong. 15:08:01.318612 IP 128.186.6.14.80 > 172.16.2.1.45242: . 63595:64975(1380) ack 3458 win 49248 15:08:01.318629 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0 We RESET again. TCPdump isn't expecting this, and has lost its history, so we are back to absolute values of the ACK field. However, timestamp is off, and window down to 0. 15:08:01.318727 IP 128.186.6.14.80 > 172.16.2.1.45242: . 64975:66355(1380) ack 3458 win 49248 15:08:01.318740 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0 15:08:01.318825 IP 172.16.2.1.45244 > 128.186.6.14.80: S 1580873046:1580873046(0) win 5840 Start of a 3-way open on 45244. Conjecture: it has opened a new channel since 45242 is "broken". 15:08:01.318849 IP 128.186.6.14.80 > 172.16.2.1.45242: . 66355:67735(1380) ack 3458 win 49248 15:08:01.318860 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0 15:08:01.318984 IP 128.186.6.14.80 > 172.16.2.1.45242: . 67735:69115(1380) ack 3458 win 49248 15:08:01.318997 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0 15:08:01.319093 IP 128.186.6.14.80 > 172.16.2.1.45242: . 69115:70407(1292) ack 3458 win 49248 This packet isn't (quite) full length, and is being sent in the presence of an unacknowledged packet (318984), so Nagle isn't being followed here. 15:08:01.319104 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0 15:08:01.319222 IP 128.186.6.14.80 > 172.16.2.1.45242: . 70407:71787(1380) ack 3458 win 49248 15:08:01.319232 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0 15:08:01.319338 IP 128.186.6.14.80 > 172.16.2.1.45242: . 71787:73167(1380) ack 345 win 49248 15:08:01.319351 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0 15:08:01.319454 IP 128.186.6.14.80 > 172.16.2.1.45242: . 73167:74547(1380) ack 3458 win 49248 15:08:01.319465 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0 15:08:01.319569 IP 128.186.6.14.80 > 172.16.2.1.45242: . 74547:75927(1380) ack 3458 win 49248 15:08:01.319581 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0 Lots of 128.186.6.14.80 talking to 172.16.2.1.45242, who doesn't want to hear 15:08:01.324493 IP 128.186.6.14.80 > 172.16.2.1.45243: P 25243:25513(270) ack 3760 win 49248 15:08:01.325287 IP 128.186.6.14.80 > 172.16.2.1.45243: P 25513:26594(1081) ack 3760 win 49248 15:08:01.325587 IP 172.16.2.1.45243 > 128.186.6.14.80: P 3760:4160(400) ack 26594 win 8610 45243 comes alive 15:08:01.452627 IP 128.186.6.14.80 > 172.16.2.1.45244: S 3542691101:3542691101(0) ack 1580873047 win 49248 15:08:01.452693 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 1 win 1460 We finish the 3-way open on 45244, and send some data 15:08:01.452976 IP 172.16.2.1.45244 > 128.186.6.14.80: P 1:405(404) ack 1 win 1460 15:08:01.460462 IP 128.186.6.14.80 > 172.16.2.1.45243: P 26594:26988(394) ack 4160 win 49248 15:08:01.461786 IP 172.16.2.1.5243 > 128.186.6.14.80: P 4160:4567(407) ack 26988 win 8610 15:08:01.489099 IP 172.16.2.1.1002283560 > 172.16.0.3.2049: 132 read [|nfs] More NFS deleted 15:08:01.586051 IP 128.186.6.14.80 > 172.16.2.1.45244: . ack 405 win 48844 15:08:01.591847 IP 128.186.6.14.80 > 172.16.2.1.45244: P 1:275(274) ack 405 win 49248 15:08:01.591902 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 275 win 1728 15:08:01.592446 IP 128.186.6.14.80 > 172.16.2.1.45244: . 275:1643(1368) ack 405 win 49248 Back to 1368-sized segments, since (bad logic) we have timestamps Similar (wrong!) behavious of the window on 172.16.2.1 15:08:01.592470 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 1643 win 2412 15:08:01.592941 IP 128.186.6.14.80 > 172.16.2.1.45244: . 1643:3011(1368) ack 405 win 49248 15:08:01.592967 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 3011 win 3096 15:08:01.596381 IP 128.186.6.14.80 > 172.16.2.1.45243: P 26988:27299(311) ack 4567 win 49248 15:08:01.597208 IP 172.16.2.1.45243 > 128.186.6.14.80: P 4567:4971(404) ack 27299 win 8610 A bit of 45243 15:08:01.725496 IP 128.186.6.14.80 > 172.16.2.1.45244: . 3011:4379(1368) ack 405 win 49248 15:08:01.725526 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 4379 win 3780 15:08:01.725619 IP 128.186.6.14.80 > 172.16.2.1.45244: P 4379:5747(1368) ack 405 win 49248 15:08:01.725629 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 5747 win 4464 15:08:01.726624 IP 128.186.6.14.80 > 172.16.2.1.45244: . 5747:7115(1368) ack 405 win 49248 15:08:01.726671 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 7115 win 5148 15:08:01.726745 IP 128.186.6.14.80 > 172.16.2.1.45244: P 7115:8483(1368) ack 405 win 49248 15:08:01.726762 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 8483 win 5832 15:08:01.727369 IP 128.186.6.14.80 > 172.16.2.1.45244: . 8483:9851(1368) ack 405 win 49248 15:08:01.727405 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 9851 win 6516 15:08:01.727497 IP 128.186.6.14.80 > 172.16.2.1.45244: P 9851:11219(1368) ack 405 win 49248 15:08:01.727512 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 11219 win 7200 Lots of 45244 with the familiar behaviour, then back to 45243 15:08:01.731653 IP 128.186.6.14.80 > 172.16.2.1.45243: P 27299:27626(327) ack 4971 win 49248 15:08:01.732062 IP 172.16.2.1.45243 > 128.186.6.14.80: P 4971:5387(416) ack 27626 win 8610 15:08:01.859292 IP 128.186.6.14.80 > 172.16.2.1.45244: . 11219:12587(1368) ack 405 win 49248 15:08:01.859325 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 12587 win 7884 15:08:01.859422 IP 128.186.6.14.80 > 172.16.2.1.45244: P 12587:13955(1368) ack 405 win 49248 15:08:01.859442 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 13955 win 8568 15:08:01.859560 IP 128.186.6.14.80 > 172.16.2.1.45244: . 13955:15323(1368) ack 405 win 49248 15:08:01.859572 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 15323 win 8568 15:08:01.859679 IP 128.186.6.14.80 > 172.16.2.1.45244: P 15323:16691(1368) ack 405 win 49248 15:08:01.859694 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 16691 win 8568 15:08:01.860563 IP 128.186.6.14.80 > 172.16.2.1.45244: . 16691:18059(1368) ack 405 win 49248 15:08:01.860612 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 18059 win 8568 15:08:01.860671 IP 128.186.6.14.80 > 172.16.2.1.45244: P 18059:19427(1368) ack 405 win 49248 15:08:01.860688 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 19427 win 8568 15:08:01.860795 IP 128.186.6.14.80 > 172.16.2.1.45244: . 19427:20795(1368) ack 405 win 49248 15:08:01.860924 IP 128.186.6.14.80 > 172.16.2.1.45244: P 20795:22163(1368) ack 405 win 49248 15:08:01.860964 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 22163 win 8568 15:08:01.861559 IP 128.186.6.14.80 > 172.16.2.1.45244: . 22163:23531(1368) ack 405 win 49248 15:08:01.861672 IP 128.186.6.14.80 > 172.16.2.1.45244: . 23531:24899(1368) ack 405 win 49248 15:08:01.861688 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 24899 win 8568 15:08:01.861789 IP 128.186.6.14.80 > 172.16.2.1.45244: P 24899:26267(1368) ack 405 win 49248 More 45244: here the WIN stabilises at 8568*4 15:08:01.867325 IP 128.186.6.14.80 > 172.16.2.1.45243: P 27626:27899(273) ack 5387 win 49248 15:08:01.868048 IP 128.186.6.14.80 > 172.16.2.1.45243: . 27899:29279(1380) ack 5387 win 49248 One candidate thought there was a violation of "ACK every two", since three packets have come in but only two on 45243, and each connection is independent. 15:08:01.868073 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 29279 win 8610 15:08:01.868163 IP 128.186.6.14.80 > 172.16.2.1.45243: . 29279:30659(1380) ack 5387 win 49248 15:08:01.868283 IP 128.186.6.14.80 > 172.16.2.1.45243: . 30659:32039(1380) ack 5387 win 49248 15:08:01.868302 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 32039 win 8610 15:08:01.868401 IP 128.186.6.14.80 > 172.16.2.1.45243: . 32039:33419(1380) ack 5387 win 49248 15:08:01.868524 IP 128.186.6.14.80 > 172.16.2.1.45243: . 33419:34799(1380) ack 5387 win 49248 15:08:01.868549 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 34799 win 8610 15:08:01.868630 IP 128.186.6.14.80 > 172.16.2.1.45243: P 34799:36091(1292) ack 5387 win 49248 15:08:01.868743 IP 128.186.6.14.80 > 172.16.2.1.45243: . 36091:37471(1380) ack 5387 win 49248 15:08:01.868762 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 37471 win 8610 15:08:01.868859 IP 128.186.6.14.80 > 172.16.2.1.45243: . 37471:38851(1380) ack 5387 win 49248 15:08:01.868977 IP 128.186.6.14.80 > 172.16.2.1.45243: . 38851:40231(1380) ack 5387 win 49248 15:08:01.868998 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 40231 win 8610 15:08:01.869095 IP 128.186.6.14.80 > 172.16.2.1.45243: . 40231:41611(1380) ack 5387 win 49248 15:08:01.869212 IP 128.186.6.14.80 > 172.16.2.1.45243: . 41611:42991(1380) ack 5387 win 49248 15:08:01.869233 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 42991 win 8610 15:08:01.869321 IP 128.186.6.14.80 > 172.16.2.1.45243: P 42991:44283(1292) ack 5387 win 49248 15:08:01.869435 IP 128.186.6.14.80 > 172.16.2.1.45243: . 44283:45663(1380) ack 5387 win 49248 15:08:01.869448 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 45663 win 8610 15:08:01.869564 IP 128.186.6.14.80 > 172.16.2.1.45243: . 45663:47043(1380) ack 5387 win 49248 15:08:01.869679 IP 128.186.6.14.80 > 172.16.2.1.45243: . 47043:48423(1380) ack 5387 win 49248 15:08:01.869693 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 48423 win 8610 15:08:01.869798 IP 128.186.6.14.80 > 172.16.2.1.45243: . 48423:49803(1380) ack 5387 win 49248 15:08:01.869917 IP 128.186.6.14.80 > 172.16.2.1.45243: . 49803:51183(1380) ack 5387 win 49248 15:08:01.869931 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 51183 win 8610 15:08:01.870025 IP 128.186.6.14.80 > 172.16.2.1.45243: P 51183:52475(1292) ack 5387 win 49248 15:08:01.870140 IP 128.186.6.14.80 > 172.16.2.1.45243: . 52475:53855(1380) ack 5387 win 49248 15:08:01.870155 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 53855 win 8610 15:08:01.870257 IP 128.186.6.14.80 > 172.16.2.1.45243: . 53855:55235(1380) ack 5387 win 49248 15:08:01.870376 IP 128.186.6.14.80 > 172.16.2.1.45243: . 55235:56615(1380) ack 5387 win 49248 15:08:01.870399 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 56615 win 8610 15:08:01.870492 IP 128.186.6.14.80 > 172.16.2.1.45243: . 56615:57995(1380) ack 5387 win 49248 15:08:01.870607 IP 128.186.6.14.80 > 172.16.2.1.45243: . 57995:59375(1380) ack 5387 win 49248 15:08:01.870622 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 59375 win 8610 15:08:01.870718 IP 128.186.6.14.80 > 172.16.2.1.45243: P 59375:60667(1292) ack 5387 win 49248 15:08:01.870834 IP 128.186.6.14.80 > 172.16.2.1.45243: . 60667:62047(1380) ack 5387 win 49248 15:08:01.870854 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 62047 win 8610 Lots of 45243, then (after some NFS) back to 45244 15:08:01.885500 IP 172.16.0.3.2049 > 172.16.2.1.1086169640: reply ok 276 create [|nfs] 15:08:01.901920 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 26267 win 8568 15:08:01.993342 IP 128.186.6.14.80 > 172.16.2.1.45244: . 26267:27635(1368) ack 405 win 49248 15:08:01.993466 IP 128.186.6.14.80 > 172.16.2.1.45244: P 27635:29003(1368) ack 405 win 49248 15:08:01.993486 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 29003 win 8568 15:08:01.993593 IP 128.186.6.14.80 > 172.16.2.1.45244: . 29003:30371(1368) ack 405 win 49248 15:08:01.993721 IP 128.186.6.14.80 > 172.16.2.1.45244: P 30371:31739(1368) ack 405 win 49248 15:08:01.993736 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 31739 win 8568 15:08:01.993847 IP 128.186.6.14.80 > 172.16.2.1.45244: . 31739:33107(1368) ack 405 win 49248 15:08:01.993970 IP 128.186.6.14.80 > 172.16.2.1.45244: P 33107:34475(1368) ack 405 win 49248 15:08:01.993987 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 34475 win 8568 15:08:01.994093 IP 128.186.6.14.80 > 172.16.2.1.45244: . 34475:35843(1368) ack 405 win 49248 15:08:01.994216 IP 128.186.6.14.80 > 172.16.2.1.45244: P 35843:37211(1368) ack 405 win 49248 15:08:01.994229 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 37211 win 8568 Then switch to 45243 15:08:02.002875 IP 128.186.6.14.80 > 172.16.2.1.45243: . 62047:63427(1380) ack 5387 win 49248 15:08:02.003217 IP 128.186.6.14.80 > 172.16.2.1.45243: . 63427:64807(1380) ack 5387 win 49248 15:08:02.003260 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 64807 win 8610 15:08:02.003338 IP 128.186.6.14.80 > 172.16.2.1.45243: . 64807:66187(1380) ack 5387 win 49248 15:08:02.003464 IP 128.186.6.14.80 > 172.16.2.1.45243: . 66187:67567(1380) ack 5387 win 49248 15:08:02.003484 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 67567 win 8610 15:08:02.003590 IP 128.186.6.14.80 > 172.16.2.1.45243: . 67567:68947(1380) ack 5387 win 49248 15:08:02.003838 IP 128.186.6.14.80 > 172.16.2.1.45243: . 68947:70327(1380) ack 5387 win 49248 15:08:02.003864 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 70327 win 8610 15:08:02.003963 IP 128.186.6.14.80 > 172.16.2.1.45243: . 70327:71707(1380) ack 5387 win 49248 15:08:02.004086 IP 128.186.6.14.80 > 172.16.2.1.45243: . 71707:73087(1380) ack 5387 win 49248 15:08:02.004102 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 73087 win 8610 15:08:02.004213 IP 128.186.6.14.80 > 172.16.2.1.45243: . 73087:74467(1380) ack 5387 win 49248 15:08:02.004336 IP 128.186.6.14.80 > 172.16.2.1.45243: . 74467:75847(1380) ack 5387 win 49248 15:08:02.004358 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 75847 win 8610 15:08:02.004439 IP 128.186.6.14.80 > 172.16.2.1.45243: P 75847:77059(1212) ack 5387 win 49248 15:08:02.005259 IP 172.16.2.1.45243 > 128.186.6.14.80: P 5387:5801(414) ack 77059 win 8610 15:08:02.007323 IP 172.16.2.1.1170055720 > 172.16.0.3.2049: 1448 write [|nfs] More NFS deleted, then on to 45244 15:08:02.127393 IP 128.186.6.14.80 > 172.16.2.1.45244: . 37211:38591(1380) ack 405 win 49248 15:08:02.127510 IP 128.186.6.14.80 > 172.16.2.1.45244: . 38591:39971(1380) ack 405 win 49248 15:08:02.127535 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 39971 win 8568 15:08:02.127626 IP 128.186.6.14.80 > 172.16.2.1.45244: . 39971:41351(1380) ack 405 win 49248 15:08:02.127743 IP 128.186.6.14.80 > 172.16.2.1.45244: . 41351:42731(1380) ack 405 win 49248 15:08:02.127766 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 42731 win 8568 15:08:02.127857 IP 128.186.6.14.80 > 172.16.2.1.45244: . 42731:44111(1380) ack 405 win 49248 15:08:02.127975 IP 128.186.6.14.80 > 172.16.2.1.45244: . 44111:45491(1380) ack 405 win 49248 15:08:02.127999 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 45491 win 8568 15:08:02.128092 IP 128.186.6.14.80 > 172.16.2.1.45244: . 45491:46871(1380) ack 405 win 49248 15:08:02.128210 IP 128.186.6.14.80 > 172.16.2.1.45244: . 46871:48251(1380) ack 405 win 49248 15:08:02.128228 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 48251 win 8568 15:08:02.128325 IP 128.186.6.14.80 > 172.16.2.1.45244: . 48251:49631(1380) ack 405 win 49248 Something very odd here: the next packet seems to ACK some data AFTER the data in the previous packet: I have no explanation for this, as it says 'no packets lost''. The next thing we see is a FIN, so presumably there was a small packet to finish the message 15:08:02.128349 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 49742 win 8568 And now to 45243 15:08:02.140297 IP 128.186.6.14.80 > 172.16.2.1.45243: P 77059:77328(269) ack 5801 win 49248 15:08:02.140376 IP 128.186.6.14.80 > 172.16.2.1.45243: P 77328:77892(564) ack 5801 win 49248 The arrival of these two tinygrams with the same ACK value (so no ACK was received between them) implies that the far end has disabled Nagle. 15:08:02.180871 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 77892 win 8610 15:08:02.254251 IP 172.16.0.3.2049 > 172.16.2.1.1287496232: reply ok 156 commit [|nfs] More NFS deleted 15:08:06.229850 arp who-has 172.16.2.1 tell 172.16.0.1 15:08:06.229869 arp reply 172.16.2.1 is-at 00:11:11:5f:b8:79 Four seconds later, the router is ARPing for us - presumably a cache time-out, but quite a quick one. 15:08:06.600473 IP 128.186.6.14.80 > 172.16.2.1.45244: F 49742:49742(0) ack 405 win 49248 15:08:06.641084 IP 172.16.2.1.45244 > 128.186.6.14.80: . ack 49743 win 8568 First pair of a 4-way close on 45244 15:08:07.140420 IP 128.186.6.14.80 > 172.16.2.1.45243: F 77892:77892(0) ack 5801 win 49248 15:08:07.180987 IP 172.16.2.1.45243 > 128.186.6.14.80: . ack 77893 win 8610 Ditto 45243 15:08:07.391749 arp who-has 172.16.105.1 tell 172.16.0.1 Random 15:08:07.695950 IP 172.16.2.1.43863 > 138.38.108.3.53: 1359+ A? www.liquidweather.net. (39) 15:08:07.696521 IP 138.38.108.3.53 > 172.16.2.1.43863: 1359 2/2/2 CNAME liquidweather.net., (156) We DNS for www.liquidweather (reply is quick, so presumably in the cache here). Note that there were additional records, which may have given the IP address that it was a CNAME for, but if so we ignored them! 15:08:11.085909 IP 172.16.2.1.45243 > 128.186.6.14.80: F 5801:5801(0) ack 77893 win 8610 15:08:11.085955 IP 172.16.2.1.45244 > 128.186.6.14.80: F 405:405(0) ack 49743 win 8568 While correct in terms of protocol, 172.16.2.1 took its time reacting to the active closes from the other end 15:08:11.219387 IP 128.186.6.14.80 > 172.16.2.1.45244: . ack 406 win 49248 15:08:11.219417 IP 128.186.6.14.80 > 172.16.2.1.45243: . ack 5802 win 49248 The other halves of those 4-way closes 15:08:12.697061 IP 172.16.2.1.43864 > 138.38.108.3.53: 925+ A? liquidweather.net. (35) 15:08:12.697601 IP 138.38.108.3.53 > 172.16.2.1.43864: 925 1/2/2 A 64.202.163.78 (138) Now the DNS for the real name. Also two additional records, so these might be the IP addresses for the name servers, instead.0 packets dropped by kernel Script done on Fri 16 Mar 2007 15:08:44 GMTAnalysis of 172.16.2.1 ====================== Doesn't use delayed ACKs at the start: breaks the SHOULD in 1122, but this common in the early days of slow start these days. Medium good TCP (as far as we cna tell from this sample!) keeps sending timestamps even when the other end has stopped responding with them, so no timing data are flowing back the behaviour of window size (8312 once, then 0) at reset is curious, but not actually WRONG. doesn't seem to use delayed ACKs, at least at the start of a connection (see 15:08:01.591902) The reset is unexplained. Analysis of 128.186.6.14 ======================== Doesn't use delayed ACKs at the start: breaks the SHOULD in 1122, but this common in the early days of slow start these days. Really not a very good TCP: (a) seems confused between cwin and window (not actually WRONG, but ...) (b) sends 1368 packets if using timestamps, even though it's already allowed for them (1380=1500-60-60) (c) Suddenly stops sending timestamps half-way through a connection (d) doesn't seem to use delayed ACKs, at least at the start of a connection (see 15:08:01.591847) (e) Definitely no Nagle: see e.g. 15:07:59.885989