Below follows output from tcpdump on the computer hawking (10.7.0.1). I let hawking synchronize its clock to that of ntp.njit.edu (Network Time Protocol Server), using rdate. (In rdate I specified the name, not the address, of ntp.njit.edu). Do ``man rdate''. Name: ntp.njit.edu Addresses: 128.235.204.54, 128.235.204.50 When I started hawking did not know the IP address of ntp, so it had to find out (using a dns query). It knew the IP address of the domain name server in the lab. I first tried to synchronize hawking using udp: did not work. Then I tried to do it using tcp: did work. ------- 18:34:48.589779 0:a:57:c0:8c:26 1:0:c:cc:cc:cc 008c 154: snap 0:0:c:20:0 CDP v1, ttl=180s 01/2a DevID 'HP ProCurve Switch 2524(000a57-c08c00)' 02/11 Addr (1): IPv4 127.0.0.1 03/05 PortID '6' 04/08 CAP 0x08 05/2d Version: Revision F.04.08 /sw/code/build/info(f01) 06/0b Platform: 'HP 2524' Frame Type (Ether Type) is 008c (hexadec) = 141 (decimal). This is less than 1518, so it denotes the length of the (ethernet) data field. This is a special ethernet frame. Has something to do with the ethernet switch. Notice it is 6.25 sec from this frame until the next. - 18:34:54.848580 0:e0:81:24:28:9c ff:ff:ff:ff:ff:ff 0800 136: 10.7.0.254.631 > 10.7.255.255.631: [udp sum ok] udp 94 (DF) (ttl 64, id 0, len 122) directed broadcast from 10.7.0.254: ``I am an IPP server''. But hawking no longer reacts! - 18:35:18.397430 0:2:b3:d3:d4:86 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.7.0.253 tell 10.7.0.1 arp request from 10.7.0.1: who has address 10.7.0.253 ? - 18:35:18.397590 0:2:b3:cd:cd:c9 0:2:b3:d3:d4:86 0806 60: arp reply 10.7.0.253 is-at 0:2:b3:cd:cd:c9 arp reply from physical address 0:2:b3:cd:cd:c9 : ``I am 10.7.0.253''. - 18:35:18.397607 0:2:b3:d3:d4:86 0:2:b3:cd:cd:c9 0800 72: 10.7.0.1.32772 > 10.1.0.254.53: [udp sum ok] 21704+ A? ntp.njit.edu. (30) (DF) (ttl 64, id 50413, len 58) IP/UDP packet. Port 53 is the domain name server port.. This packet asks for the IP address of ntp.njit.edu . (Network Time Protocol Server on NJIT). This packet is a dns query. The dns server in the lab is kirk.internet.lab, and 10.1.0.254 is one of kirk's addresses. - 18:35:18.397788 0:2:b3:cd:cd:c9 0:2:b3:d3:d4:86 0800 100: 10.7.0.253 > 10.7.0.1: icmp: redirect 10.1.0.254 to host 10.7.0.254 for 10.7.0.1.32772 > 10.1.0.254.53: [udp sum ok] 21704+ A? ntp.njit.edu. (30) (DF) (ttl 64, id 50413, len 58) [tos 0xc0] (ttl 64, id 45676, len 86) ICMP redirect. To understand this one, look at full hexadecimal output. (For this destination, next hop is 10.7.0.254 , not 10.7.0.253) - 18:35:18.397809 0:2:b3:d3:d4:86 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.7.0.254 tell 10.7.0.1 Another arp request, to get physical address of 10.7.0.254 - 18:35:18.397921 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0806 60: arp reply 10.7.0.254 is-at 0:e0:81:24:28:9c arp reply from 0:e0:81:24:28:9c : ``I am 10.7.0.254'' - 18:35:18.399788 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 266: 10.1.0.254.53 > 10.7.0.1.32772: [udp sum ok] 21704 q: A? ntp.njit.edu. 2/4/4 ntp.njit.edu. A 128.235.204.54, ntp.njit.edu. A 128.235.204.50 ns: njit.edu. NS ns1.uthscsa.edu., njit.edu. NS dns1.njit.edu., njit.edu. NS auth00.ns.uu.net., njit.edu. NS mail-gw2.njit.edu. ar: ns1.uthscsa.edu. A 129.111.140.66, dns1.njit.edu. A 128.235.251.10, auth00.ns.uu.net. A 198.6.1.65, mail-gw2.njit.edu. A 128.235.251.192 (224) (DF) (ttl 60, id 0, len 252) A pretty long message, response to the dns query above. This is a response from kirk. It says: ``ntp.njit.edu has addresses 128.235.204.54 and 128.235.204.50'' . - 18:35:18.399966 0:2:b3:d3:d4:86 0:2:b3:cd:cd:c9 0800 42: 10.7.0.1.32772 > 128.235.204.54.37: [udp sum ok] udp 0 (DF) (ttl 64, id 0, len 28) hawking sends a udp packet to ntp. (udp port 37: Time protocol) We will see that ntp does not react to this packet. The return may have been dropped by the NAT router? - 18:35:18.400088 0:2:b3:cd:cd:c9 0:2:b3:d3:d4:86 0800 70: 10.7.0.253 > 10.7.0.1: icmp: redirect 128.235.204.54 to host 10.7.0.254 for 10.7.0.1.32772 > 128.235.204.54.37: [udp sum ok] udp 0 (DF) (ttl 64, id 0, len 28) [tos 0xc0] (ttl 64, id 45677, len 56) Again an ICMP redirect: Use 10.7.0.254, you dummy! - 18:35:23.393844 0:2:b3:cd:cd:c9 0:2:b3:d3:d4:86 0806 60: arp who-has 10.7.0.1 tell 10.7.0.253 Strange! An arp request that is not a broadcast. 10.7.0.253 seems to doubt the sanity of 10.7.0.1 . - 18:35:23.393866 0:2:b3:d3:d4:86 0:2:b3:cd:cd:c9 0806 42: arp reply 10.7.0.1 is-at 0:2:b3:d3:d4:86 10.7.0.1 responds: it is really me. - 18:35:23.394634 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0806 60: arp who-has 10.7.0.1 tell 10.7.0.254 10.7.0.254 is getting worried about 10.7.0.1 also. - 18:35:23.394652 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0806 42: arp reply 10.7.0.1 is-at 0:2:b3:d3:d4:86 10.7.0.1 says again: it is really me. 18:35:25.855932 0:e0:81:24:28:9c ff:ff:ff:ff:ff:ff 0800 136: 10.7.0.254.631 > 10.7.255.255.631: [udp sum ok] udp 94 (DF) (ttl 64, id 0, len 122) 10.7.0.254 broadcasts: I am the IPP server! - 18:35:46.456512 0:2:b3:d3:d4:86 0:2:b3:cd:cd:c9 0800 72: 10.7.0.1.32772 > 10.1.0.254.53: [udp sum ok] 44614+ A? ntp.njit.edu. (30) (DF) (ttl 64, id 53219, len 58) Another dns query for ntp.njit.edu . This probably is because I told hawking to synchronize, now using tcp. - 18:35:46.456699 0:2:b3:cd:cd:c9 0:2:b3:d3:d4:86 0800 100: 10.7.0.253 > 10.7.0.1: icmp: redirect 10.1.0.254 to host 10.7.0.254 for 10.7.0.1.32772 > 10.1.0.254.53: [udp sum ok] 44614+ A? ntp.njit.edu. (30) (DF) (ttl 64, id 53219, len 58) [tos 0xc0] (ttl 64, id 45678, len 86) Another redirect! - 18:35:46.458384 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 266: 10.1.0.254.53 > 10.7.0.1.32772: [udp sum ok] 44614 q: A? ntp.njit.edu. 2/4/4 ntp.njit.edu. A 128.235.204.50, ntp.njit.edu. A 128.235.204.54 ns: njit.edu. NS ns1.uthscsa.edu., njit.edu. NS dns1.njit.edu., njit.edu. NS auth00.ns.uu.net., njit.edu. NS mail-gw2.njit.edu. ar: ns1.uthscsa.edu. A 129.111.140.66, dns1.njit.edu. A 128.235.251.10, auth00.ns.uu.net. A 198.6.1.65, mail-gw2.njit.edu. A 128.235.251.192 (224) (DF) (ttl 60, id 0, len 252) Another dns reply - 18:35:46.458826 0:2:b3:d3:d4:86 0:2:b3:cd:cd:c9 0800 74: 10.7.0.1.48723 > 128.235.204.50.37: S [tcp sum ok] 3673432781:3673432781(0) win 5840 (DF) (ttl 64, id 60718, len 60) hawking starts setting up a TCP connection to ntp. This wqas the SYN packet. - 18:35:46.458967 0:2:b3:cd:cd:c9 0:2:b3:d3:d4:86 0800 102: 10.7.0.253 > 10.7.0.1: icmp: redirect 128.235.204.50 to host 10.7.0.254 for 10.7.0.1.48723 > 128.235.204.50.37: S [tcp sum ok] 3673432781:3673432781(0) win 5840 (DF) (ttl 64, id 60718, len 60) [tos 0xc0] (ttl 64, id 45679, len 88) Another redirect! We have to make sure hawking learns to accept redirects. - 18:35:46.461679 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 78: 128.235.204.50.37 > 10.7.0.1.48723: S [tcp sum ok] 1285792347:1285792347(0) ack 3673432782 win 49232 (DF) (ttl 58, id 7150, len 64) A response from ntp to hawking. This is the SYN-ACK. - 18:35:46.461707 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66: 10.7.0.1.48723 > 128.235.204.50.37: . [tcp sum ok] 1:1(0) ack 1 win 5840 (DF) (ttl 64, id 60719, len 52) From hawking to ntp. I did not use the -S option in tcpdump, so sequence numbers and ack numbers are given relative to the firdt ones. - 18:35:46.463926 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 70: 128.235.204.50.37 > 10.7.0.1.48723: P [tcp sum ok] 1:5(4) ack 1 win 49232 (DF) (ttl 58, id 7151, len 56) From ntp to hawking - 18:35:46.463944 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66: 10.7.0.1.48723 > 128.235.204.50.37: . [tcp sum ok] 1:1(0) ack 5 win 5840 (DF) (ttl 64, id 60720, len 52) From hawking to ntp. - 18:35:46.463959 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66: 10.7.dumpntp.txt0.1.48723 > 128.235.204.50.37: F [tcp sum ok] 1:1(0) ack 5 win 5840 (DF) (ttl 64, id 60721, len 52) From hawking to ntp: ``I am done''. (FIN). - 18:35:46.464092 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 66: 128.235.204.50.37 > 10.7.0.1.48723: F [tcp sum ok] 5:5(0) ack 1 win 49232 (DF) (ttl 58, id 7152, len 52) From ntp to hawking: ``I am done, too''. (FIN) - 18:35:46.464106 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66: 10.7.0.1.48723 > 128.235.204.50.37: . [tcp sum ok] 2:2(0) ack 6 win 5840 (DF) (ttl 64, id 60722, len 52) hawking to ntp: ACK (``I received your FIN). - 18:35:46.466212 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 66: 128.235.204.50.37 > 10.7.0.1.48723: . [tcp sum ok] 6:6(0) ack 2 win 49232 (DF) (ttl 58, id 7153, len 52) ntp to hawking: ACK (``and I received your FIN''). The last 3 packets are in a different order than the books say they ought to be. It ought to be (FIN ->), (<- ACK), (<- FIN), (ACK ->). Apparently this works. - 18:35:48.134858 0:a:57:c0:8c:26 1:0:c:cc:cc:cc 008c 154: snap 0:0:c:20:0 CDP v1, ttl=180s 01/2a DevID 'HP ProCurve Switch 2524(000a57-c08c00)' 02/11 Addr (1): IPv4 127.0.0.1 03/05 PortID '6' 04/08 CAP 0x08 05/2d Version: Revision F.04.08 /sw/code/build/info(f01) 06/0b Platform: 'HP 2524' Another frame not to or from hawking. Note it is 1.66 sec after the previous frame. It is 59.545 sec after the previous ``ethernetswitch'' frame. Seems to be a ``once a minute'' affair. ----