BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


FreeBSD Basics

IP Packets Revealed

03/28/2001

In last week's article, we used the tcpdump utility to capture the packets involved in a telnet session and then examined the resulting dump file. This week, I'd like to continue through the output of this file to see what else we can discover regarding a typical TCP connection.

When we looked at the packets involved in the TCP 3-way handshake, we paid particular attention to the flags field in the TCP header. The only time a packet's SYN flag is set is if it is one of the first two packets involved in the 3-way handshake. This means that whenever a packet arrives with its SYN flag set, someone is trying to create a TCP connection. Notice in today's output that every TCP header has an acknowledgment number and the ACK flag is set; the only exception to this rule is found in the very first packet involved in the 3-way handshake. That is, if a packet arrives with the SYN flag set but not the ACK flag, that packet is trying to initiate a connection to one of your network services; the destination port field will tell you which service they are trying to connect to.

Let's take one last look at that first packet from last week's 3-way handshake:

tcpshow < dump
<snip to just show this one packet>

-------------------------------------------------------------
Packet 10
TIME: 10:25:36.854420 (6.232947)
LINK: 00:00:B4:3C:56:40 -> 00:50:BA:DE:36:33 type=IP
  IP: 10.0.0.2 -> 10.0.0.1 hlen=20 TOS=10 dgramlen=44 id=0013
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=26A7
 TCP: port blackjack -> telnet seq=3205630181 ack=0000000000
      hlen=24 (data=0) UAPRSF=000010 wnd=16384 cksum=7814 urg=0
DATA: <No data>
--------------------------------------------------------------

Note that this packet has no acknowledgement (ack=0000000000) and the only TCP flag that has been set (UAPRSF=000010) to 1 is the S or SYN flag. This packet came from 10.0.0.2 and it is trying to establish a connection to (->) the telnet port on 10.0.0.1.

TCP also has an established procedure for gracefully ending a TCP connection. As you may have guessed, it involves the use of the FIN flag. Either end of a TCP connection can ask to close the connection at any time. In our example, I typed the word exit as soon as I had established the telnet connection and had successfully logged in. Let's see what packets were involved in this transaction. Again, I've snipped the output of the tcpshow command to just show these packets:

------------------------------------------------------------
Packet 72
TIME: 10:25:43.153131 (1.174173)
LINK: 00:00:B4:3C:56:40 -> 00:50:BA:DE:36:33 type=IP
  IP: 10.0.0.2 -> 10.0.0.1 hlen=20 TOS=10 dgramlen=41 id=0037
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=2686
 TCP: port blackjack -> telnet seq=3205630360 ack=1746120351
      hlen=20 (data=1) UAPRSF=011000 wnd=17520 cksum=0EE3 urg=0
DATA: e
-------------------------------------------------------------

This is the first packet we've seen that actually contains some data. Even though I typed the word exit from the computer 10.0.0.2, each character I typed was sent in a separate packet. The first packet contained the letter "e".

-------------------------------------------------------------
Packet 73
TIME: 10:25:43.153685 (0.000554)
LINK: 00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=IP
  IP: 10.0.0.1 -> 10.0.0.2 hlen=20 TOS=10 dgramlen=41 id=956E
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=914E
 TCP: port telnet -> blackjack seq=1746120351 ack=3205630361
      hlen=20 (data=1) UAPRSF=011000 wnd=17520 cksum=0EE2 urg=0
DATA: e
-------------------------------------------------------------

This is the response from 10.0.0.1. Note that it acknowledged receipt of my packet as it incremented my sequence number by one. Strangely, it also returned the same data; this told the telnet client to echo the letter "e" onto my terminal.

-------------------------------------------------------------
Packet 74
TIME: 10:25:43.248672 (0.094987)
LINK: 00:00:B4:3C:56:40 -> 00:50:BA:DE:36:33 type=IP
  IP: 10.0.0.2 -> 10.0.0.1 hlen=20 TOS=10 dgramlen=40 id=0038
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=2686
 TCP: port blackjack -> telnet seq=3205630361 ack=1746120352
      hlen=20 (data=0) UAPRSF=010000 wnd=17520 cksum=73EA urg=0
DATA: <No data>
-------------------------------------------------------------
Packet 75
TIME: 10:25:43.456449 (0.207777)
LINK: 00:00:B4:3C:56:40 -> 00:50:BA:DE:36:33 type=IP
  IP: 10.0.0.2 -> 10.0.0.1 hlen=20 TOS=10 dgramlen=41 id=0039
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=2684
 TCP: port blackjack -> telnet seq=3205630361 ack=1746120352
      hlen=20 (data=1) UAPRSF=011000 wnd=17520 cksum=FBE0 urg=0
DATA: x
-------------------------------------------------------------

The next two packets again came from me at 10.0.0.2. First, I acknowledged receipt of the packet from 10.0.0.1, then I sent the letter "x" in its own packet. I won't bore you with the outputs of packets 76 to 84 as they simply repeat this process of individually sending and echoing the letters "x", "i", and "t", and acknowledging that each packet was received.

Packet 85 contains data from the telnet application running on 10.0.0.1. This application is now aware that I typed the word exit. It responds by sending me the word logout to be echoed to my terminal:

-------------------------------------------------------------
Packet 85
TIME: 10:25:44.258982 (0.011001)
LINK: 00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=IP
  IP: 10.0.0.1 -> 10.0.0.2 hlen=20 TOS=10 dgramlen=48 id=9573
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=9142
 TCP: port telnet -> blackjack seq=1746120359 ack=3205630366
      hlen=20 (data=8) UAPRSF=011001 wnd=17520 cksum=1D70 urg=0
DATA: logout.
	
-------------------------------------------------------------

Did you also notice the TCP flags field in this packet? The FIN flag has been set. Not only did the telnet application echo the word logout to my screen, it also indicated that it would "finish up" this TCP connection. At this point, my machine responded with two packets. The first acknowledged receipt of this packet, and the second agreed to the closing of the TCP connection by setting its own FIN flag:

-------------------------------------------------------------
Packet 86
TIME: 10:25:44.259292 (0.000310)
LINK: 00:00:B4:3C:56:40 -> 00:50:BA:DE:36:33 type=IP
  IP: 10.0.0.2 -> 10.0.0.1 hlen=20 TOS=10 dgramlen=40 id=003F
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=267F
 TCP: port blackjack -> telnet seq=3205630366 ack=1746120368
      hlen=20 (data=0) UAPRSF=010000 wnd=17512 cksum=73DD urg=0
DATA: <No data>
-------------------------------------------------------------
Packet 87
TIME: 10:25:44.260137 (0.000845)
LINK: 00:00:B4:3C:56:40 -> 00:50:BA:DE:36:33 type=IP
  IP: 10.0.0.2 -> 10.0.0.1 hlen=20 TOS=10 dgramlen=40 id=0040
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=267E
 TCP: port blackjack -> telnet seq=3205630366 ack=1746120368
      hlen=20 (data=0) UAPRSF=010001 wnd=17520 cksum=73D4 urg=0
DATA: <No data>
-------------------------------------------------------------

The final packet in our dump file was the very last acknowledgment from 10.0.0.1:

-------------------------------------------------------------
Packet 88
TIME: 10:25:44.260231 (0.000094)
LINK: 00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=IP
  IP: 10.0.0.1 -> 10.0.0.2 hlen=20 TOS=10 dgramlen=40 id=9574
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=9149
 TCP: port telnet -> blackjack seq=1746120368 ack=3205630367
      hlen=20 (data=0) UAPRSF=010000 wnd=17519 cksum=73D5 urg=0
DATA: <No data>
-------------------------------------------------------------

Pages: 1, 2, 3

Next Pagearrow





Sponsored by: