This is a trace of ``tcpdump'' taken on hawkings (10.7.0.1) in the 
Internet Laboratory.

It shows that as long as there is an ``IPP Server'' (Internet Printing 
Protocol, Portnumber 631) and an IPP client on the network, there is 
incessant chatter. This trace still is a useful example. Please carefully
study the first few packets. Then find all S (SYN) and F (FIN) TCP
packets.

----

14:53:19.250556 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 79:
10.7.0.1.32771 > 10.1.0.254.53: 23054+ A? turing.internet.lab. (37)
(DF)

The packet above is a UDP packet from IP address 10.7.0.1, port 32771, 
to IP address 10.1.0.254, port 53.

14.53.19.250556 is the time stamp. (on 03/08/2004).
0:2:b3:d3:d4:86 is the source ethernet address (on hawking).
0:e0:81:24:28:9c is the dest ethernet address.
0800 is the frame type: IPv4.
79 is the size of the ethernet frame, including IP packet, ethernet 
adresses, ethertype, but excluding pre-amble and CRC.
This happens to be a UDP packet. 
The packet is a UDP packet from IP address 10.7.0.1, port 32771, 
to IP address 10.1.0.254, port 53.
There are 37 UDP data bytes, 8 UDP header bytes, 20 IPv4 header bytes, 
6+6+2 = 14 bytes for ethernet adresses and frametype. Total: 
37 + 8 + 20 + 14 = 79: right!
10.7.0.1 is the computer  ``hawking''  .
10.1.0.254 is one of the two interfaces on ``kirk''. kirk is a router 
as well as a domain name server.
port 53: domain name server.
port 32771: a high number port.
The packet above is part of a request for domain name resolution. 
(It requests the IP address of turing.internet.lab ).
The ``Do not fragment'' bit is set.
We happen to know that turing is the IPP Server. 
(Internet Printing Protocol).

---

14:53:19.252029 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 164:
10.1.0.254.53 > 10.7.0.1.32771: 23054* 2/1/2 A 10.6.0.253, A
10.7.0.254 (122) (DF)

This is the response from kirk to hawking. It gives the IP address 
(in fact: one of the two IP addresses) of turing: 10.6.0.253 .
turing is the print server.

---

14:53:19.252126 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 74:
10.7.0.1.48113 > 10.6.0.253.631: S 2466653205:2466653205(0) win 5840
<mss 1460,sackOK,timestamp 16478755 0,nop,wscale 0> (DF)

The packet above is a TCP packet from port 48113 on 10.7.0.1. to 
port 631 on 10.6.0.253 . Port 631 is IPP (Internet Printing 
Protocol). It is a SYN packet, so next should come a SYN-ACK in the 
opposite direction.
There are a few TCP options: MSS (L = 4), SACK OK (L = 2), 
Timestamp (L = 10), No-Op (L = 1), Windowscale = 0 (L = 3).
So there are 20 ordinary TCP header bytes, (4 + 2 + 10 + 1 + 3) = 20
TCP Option Bytes, 20 IP header bytes, Total 60 Bytes for the IPv4 
packet. Plus 14 for the ethernet header: total 74. Right!  

Note there is a timestamp in the forward direction. In the backward 
direction it is 0 (zero).

---

14:53:19.252262 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 74:
10.6.0.253.631 > 10.7.0.1.48113: S 3617864861:3617864861(0) ack
2466653206 win 5792 <mss 1460,sackOK,timestamp 666275654
16478755,nop,wscale 0> (DF)

This is the SYN-ACK in response to the SYN above.

Note the timestamp in the backward direction is the timestamp in
the forward direction of the previous packet.

---

14:53:19.252287 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66:
10.7.0.1.48113 > 10.6.0.253.631: . ack 3617864862 win 5840
<nop,nop,timestamp 16478755 666275654> (DF)

This is the ACK in response to the SYN-ACK above.

Note the timestamps have flipped but have not changed.

---

14:53:19.252342 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 83:
10.7.0.1.48113 > 10.6.0.253.631: P 2466653206:2466653223(17) ack
3617864862 win 5840 <nop,nop,timestamp 16478755 666275654> (DF)

Finally some real data! 17 TCP databytes, plus 12 TCP Option Bytes, 
plus 20 ordinary TCP header bytes, plus 20 IP header bytes: 
total IP packet is 69 Bytes. Plus 14 for the ethernet frame: 83 total.
Right!

This packet included a request to push the data.

Note the timestamps do not change. Is this a bug or a feature?

---

14:53:19.252350 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 87:
10.7.0.1.48113 > 10.6.0.253.631: P 2466653223:2466653244(21) ack
3617864862 win 5840 <nop,nop,timestamp 16478755 666275654> (DF)

14:53:19.252358 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 97:
10.7.0.1.48113 > 10.6.0.253.631: P 2466653244:2466653275(31) ack
3617864862 win 5840 <nop,nop,timestamp 16478755 666275654> (DF)

14:53:19.252481 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 66:
10.6.0.253.631 > 10.7.0.1.48113: . ack 2466653223 win 5792
<nop,nop,timestamp 666275654 16478755> (DF)

14:53:19.252482 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 66:
10.6.0.253.631 > 10.7.0.1.48113: . ack 2466653244 win 5792
<nop,nop,timestamp 666275654 16478755> (DF)

14:53:19.252501 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 66:
10.6.0.253.631 > 10.7.0.1.48113: . ack 2466653275 win 5792
<nop,nop,timestamp 666275654 16478755> (DF)

14:53:19.252516 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 315:
10.7.0.1.48113 > 10.6.0.253.631: P 2466653275:2466653524(249) ack
3617864862 win 5840 <nop,nop,timestamp 16478755 666275654> (DF)

14:53:19.252664 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 66:
10.6.0.253.631 > 10.7.0.1.48113: . ack 2466653524 win 6432
<nop,nop,timestamp 666275654 16478755> (DF)

14:53:19.252810 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 83:
10.6.0.253.631 > 10.7.0.1.48113: P 3617864862:3617864879(17) ack
2466653524 win 6432 <nop,nop,timestamp 666275654 16478755> (DF)

14:53:19.252820 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66:
10.7.0.1.48113 > 10.6.0.253.631: . ack 3617864879 win 5840
<nop,nop,timestamp 16478755 666275654> (DF)

14:53:19.252851 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 103:
10.6.0.253.631 > 10.7.0.1.48113: P 3617864879:3617864916(37) ack
2466653524 win 6432 <nop,nop,timestamp 666275654 16478755> (DF)

14:53:19.252861 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66:
10.7.0.1.48113 > 10.6.0.253.631: . ack 3617864916 win 5840
<nop,nop,timestamp 16478755 666275654> (DF)

14:53:19.252852 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 84:
10.6.0.253.631 > 10.7.0.1.48113: P 3617864916:3617864934(18) ack
2466653524 win 6432 <nop,nop,timestamp 666275654 16478755> (DF)

14:53:19.252866 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66:
10.7.0.1.48113 > 10.6.0.253.631: . ack 3617864934 win 5840
<nop,nop,timestamp 16478755 666275654> (DF)

14:53:19.254257 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 289:
10.6.0.253.631 > 10.7.0.1.48113: P 3617864934:3617865157(223) ack
2466653524 win 6432 <nop,nop,timestamp 666275654 16478755> (DF)

14:53:19.254271 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66:
10.7.0.1.48113 > 10.6.0.253.631: . ack 3617865157 win 6432
<nop,nop,timestamp 16478755 666275654> (DF)

14:53:19.254307 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66:
10.7.0.1.48113 > 10.6.0.253.631: F 2466653524:2466653524(0) ack
3617865157 win 6432 <nop,nop,timestamp 16478755 666275654> (DF)

This was a FIN

---

14:53:19.254435 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 66:
10.6.0.253.631 > 10.7.0.1.48113: F 3617865157:3617865157(0) ack
2466653525 win 6432 <nop,nop,timestamp 666275654 16478755> (DF)

This was a FIN in the opposite direction:  This violates the 
prescribed behavior! (ACK and FIN have been combined: apparently
this is legal?)

---

14:53:19.254450 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66:
10.7.0.1.48113 > 10.6.0.253.631: . ack 3617865158 win 6432
<nop,nop,timestamp 16478755 666275654> (DF)

The Final ACK. Terminates TCP connection.

---

14:53:24.249314 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 94 (DF)

Some kind of physical broadcast. Direct Broadcast to 10.7.0.0/16.
Turing advertises itself as an IPP server.

---

14:53:24.260569 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 79:
10.7.0.1.32771 > 10.1.0.254.53: 23055+ A? turing.internet.lab. (37)
(DF)

The history is about to repeat. With of course a different port number
at the hawking side. Clearly, turing frequently advertises itself as
print server, and every time it does that chatter ensues. Let's turn
off the printer deamon.

---

14:53:24.261390 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 164:
10.1.0.254.53 > 10.7.0.1.32771: 23055* 2/1/2 A 10.6.0.253, A
10.7.0.254 (122) (DF)

14:53:24.261532 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 74:
10.7.0.1.48114 > 10.6.0.253.631: S 2470060133:2470060133(0) win 5840
<mss 1460,sackOK,timestamp 16479256 0,nop,wscale 0> (DF)

14:53:24.261680 0:e0:81:24:28:9c 0:2:b3:d3:d4:86 0800 74:
10.6.0.253.631 > 10.7.0.1.48114: S 3638522992:3638522992(0) ack
2470060134 win 5792 <mss 1460,sackOK,timestamp 666276155
16479256,nop,wscale 0> (DF)

14:53:24.261704 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 66:
10.7.0.1.48114 > 10.6.0.253.631: . ack 3638522993 win 5840
<nop,nop,timestamp 16479256 666276155> (DF)

14:53:24.263179 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 83:
10.7.0.1.48114 > 10.6.0.253.631: P 2470060134:2470060151(17) ack
3638522993 win 5840 <nop,nop,timestamp 16479256 666276155> (DF)

14:53:24.263189 0:2:b3:d3:d4:86 0:e0:81:24:28:9c 0800 87:
10.7.0.1.48114 > 10.6.0.253.631: P 2470060151:2470060172(21) ack
3638522993 win 5840 <nop,nop,timestamp 16479256 666276155> (DF)


here about 23 seconds of frames thrown away.


14:53:47.915072 0:a:57:c0:8c:26 1:0:c:cc:cc:cc 008c 154: CDP v1,
ttl=180s DevID 'HP ProCurve Switch 2524(000a57-c08c00)' Addr (1): IPv4
127.0.0.1 PortID '6' CAP 0x08 Version: (suppressed) Platform: 'HP
2524'

from here on everything thrown away.