■ FIGURE 2. This isn’t as ugly as it may
seem. As we go along, I’ll use sniffer
captures to explain what is going on in
each of the areas of this graphic that
we’re interested in. The sequence and
acknowledgement numbers, along with
the flags, make the TCP segment unique
with respect to the UDP datagram.
forth between Screen Shot 2 and
Figure 2. You’ll see that you can
physically match the sniffer fields
with the fields delineated in the
Figure 2 layout graphic. The first 16
bits of the TCP header contain the
TCP source port address. The destination port resides on our embedded
TCP/IP host, the Frame Thrower II.
The TCP/IP embedded host firmware
defines the Frame Thrower II’s TCP
port as 8088 decimal. 1297 decimal
is the TCP port being used by the
Telnet application on the laptop
computer I used to generate the
TCP/IP data stream.
What you see in Screen Shot 2
is the beginning of what is called
the three-way handshake. The first
message sent in the three-way
handshake process is a dataless TCP
segment with the SYN bit set in the
TCP header flag’s field. If there is no
TCP session established, the Frame
Thrower II’s first inclination is to
check the destination port address
and, if the destination port belongs
to the Frame Thrower II, it then
runs a test on the SYN flag bit in the
TCP header.
If it is determined that the remote
host (my laptop) is trying to establish a
TCP/IP session (in this case, it is), the
receiving host (the Frame Thrower II)
prepares for part two of the three-way
handshake by incrementing the
incoming sequence number from the
remote host before sending it back as
the acknowledgement number.
■ SCREEN SHOT 2. You can easily tell
who’s talking and who’s listening by
associating the source and destination
port numbers with their respective
hardware. In our case, port 8088 belongs
to the Frame Thrower II and port 1297
resides at the laptop end of the link. This
capture is the first shot fired in the TCP
three-way handshake process.
86
September 2006
