THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

INTRODUCING THE PACKET WHACKER

Part 2: Setting a Course with Code
by Fred Eady

Start ı Packet Whacker Utilities ı Receiving Packets ı Who ARP You?ı Ping ı UDP ı TCP ı FIN ı Sources and PDF

TCP

Transmission control protocol (TCP) also rides on the IP bus. TCP requires a physical and logical connection between the local end and the remote end. The end points are sometimes referred to as client and server depending on the application running at the end point in question. In addition to requiring a connection, TCP requires acknowledgment of transmitted and received data across the link. This makes TCP reliable, and also makes the job of coding TCP firmware more difficult than UDP.

TCP is a complex protocol as far as coding is concerned. However, TCP is simple to understand. Basically, the TCP code in Listing 9 establishes a connection between the PICDEM.net and Sniffer PC, transfers data, and closes the connection. Iıll use TELNET to send data to the PICDEM.net. The PICDEM.net will echo the data back to the TELNET session and close the session

.TELNET clients must negotiate with TELNET servers before establishing a session. This negotiation concerns terminal parameters and what each side of the TELNET session is expected to do or react to. I donıt need any of that for my application. So, to get around the negotiation data stream, the Sniffer TELNET session will be pointed to an ephemeral port number of 8080 decimal instead of the well-known TELNET Port 23. As long as you stay away from Port 23, the negotiation process wonıt fire off.

Instead of trying to call the play by play, Iım going to include Sniffer shots to augment the commentary. Everything begins with the TELNET client sending a correctly addressed SYN packet to the PICDEM.net in Photo 9. The PICDEM.net is acting as a server in this case and sees the clientıs request to open a session. The sequence number is always sent and the acknowledgment number is always received. The client has sent an initial sequence number (ISN) of 0x74D0FBAD, and as you can see in the Sniffer shot, the client is expecting an acknowledgment of 0x74D0FBAE. Thatıs because the SYN bit is considered as a byte of data.

The Packet Whacker firmware sends a SYN and acknowledges the clientıs SYN, thus acknowledging with 0x74D0FBAE. In addition, the PICDEM.net (the server here) takes the opportunity to pass its ISN (0x1242FFFF) to the client. According to the TCP protocol rules, the client must acknowledge the serverıs ISN. The Sniffer shot in Photo 10 gives us a peek at the expected acknowledgment number of 0x12430000.

The final exchange needed to establish a TCP/IP connection is shown in Photo 11. Here, the client acknowledges the serverıs SYN, and the sequence numbers are set at both ends. From here on out, the sequence numbers and acknowledgments keep up with the actual number of bytes transferred between the client (Sniffer PC) and server (PICDEM.net).

The final Sniffer shot is Photo 12, and it shows the client sending a "c" to the PICDEM.net. The Sniffer view shows you that the tbird900 expects an acknowledgment on that character and that the acknowledgment bit is set. The ACK bit will remain set throughout the life of the connection, because without this bit on, the acknowledgment field of the TCP header is ignored. The connection is broken by the Telnet client when it sends a FIN to the PICDEM.net.

PREVIOUS • NEXT