Trying to understand every detail involved in creating an embedded product that communicates via Internet protocols can be a daunting task. These protocols were created for systems that generally have much more CPU power and memory than the average embedded design. So as an embedded engineer, it's very important that you know as much about TCP/IP as possible. Only then will you understand how to intelligently scale down these protocols to work in an embedded design.
This article provides the introductory steps necessary for integrating TCP/IP into a product. Creating the simple version of a Network Packet Sniffer de-scribed here will expose the Ethernet frame in detail and enable the investigation of data traffic on a local-area network (LAN).
Implementing embedded Ethernet requires a fundamental understanding of how to use an off-the-shelf Ethernet controller as an Internet-ready communication port in a design. Learning the general topology of a Packet Sniffer is the first step.
What's An Embedded Ethernet Sniffer? The word Sniffer is really shorthand for Packet Sniffer, a common networking term. A Packet Sniffer is a network-monitoring tool that captures data packets and decodes them into a desirable form for a user. Generally, they're employed to debug and monitor network problems.
An Embedded Sniffer occupies a spot in a LAN much as a normal computer would (Fig. 1). It simply displays a snapshot of the data traffic at a given moment. An Embedded Ethernet Sniffer is a passive device that never transmits data onto a LAN. It's configured to trap and capture data, based on a few parameters provided by a user.
The three parameters of interest are Ethernet addresses, IP addresses, and TCP port numbers. We'll begin by examining the fundamental concepts and building blocks for an Ethernet Sniffer used to monitor and capture TCP/IP frames.
Reviewing The TCP/IP Stack: When creating an embedded Ethernet application, a historical perspective of the Ethernet frame and knowledge of its modern-day implementation helps one to appreciate the peculiarities of the frame's composition. Just like every other form of communication, networking has its own protocols. TCP/IP, often referred to as the Internet Architecture, is a loose interpretation of the strictly layered architecture called the Open System Interconnection Model, otherwise known as the OSI Model. Seven layers compose this architecture.
The Upper layers—independent layers—prepare and present data to the user:
- Application: Interface to the end user.
- Presentation: Converts application data to a common format.
- Session: Organizes and routes data to/from application processes.
The Lower layers route, package, and verify data, regardless of the data:
- Transport: Establishes and maintains intercomputer communication.
- Network: Provides the physical routing between computers.
- Data Link: Corrects transmission errors.
- Physical: The wiring.
On the other hand, the TCP/IP Model (Stack) has only four layers:
- Application Layer: FTP, SMTP, Telnet, etc.
- Transport Layer: TCP, UDP, etc.
- Network Layer: IP, ICMP, etc.
- Link Layer: Ethernet, etc.
For this article, the layers of interest, in order of their importance, are the Link, Network, and Transport layers. Focus on the Link layer will concentrate on where the device driver lies. The Network layer will be examined only as it pertains to IP, and the Transport layer just as it relates to TCP. The Application layer won't be discussed.
The Link Layer—Ethernet Isn't Always Ethernet: In the early 1980s, a networking standard called Ethernet was created after approximately a decade of development. This technology uses Carrier-Sense Multiple Access with Collision Detection, or CSMA/CD. The three-part definition of CSMA/CD essentially defines the Ethernet concept. Consider a LAN configuration with multiple computers:
- Carrier Sense means that before a computer transmits data onto a network, it must monitor (sense) that network for data traffic. If the network is busy with other communication, the data transmission has to be suspended until the network is clear.
- Multiple Access refers to multiple computers that can communicate freely on a network.
- Collision Detection resolves erroneous simultaneous transmissions by two or more computers at the same time. Each computer introduces a random time before retransmission.
A short time after the introduction of the Ethernet standard, the IEEE created a committee called Project 802 to develop standards for the office network. Subsequent subcommittees under Project 802 were formed to handle different types of networks. For example, subcommittee IEEE 802.3 covered CSMA/CD networks, IEEE 802.4 covered token bus networks, and IEEE 802.5 covered token ring networks.
The IEEE 802.3 standard was defined to also support the original Ethernet standard. This ensures that equipment based on the two standards may operate on the same LAN. An Ethernet frame can be identified by the Length/Type field.
If the value of the Length/Type field is equal to or greater than 1536 decimal, this value indicates the Type of the MAC Client protocol relevant only to Ethernet frames (Fig. 2). Otherwise, this field is used to indicate the Length, which is the number of bytes in the subsequent MAC Client Data field of an IEEE 802.3 frame. Examples of common Type fields include:
- 0800h—IP (Internet Protocol), used exclusively here.
- 0806h—ARP (Address Resolution Protocol).
- 0835h—RARP (Reverse Address Resolution Protocol).
Note that ARP and RARP aren't discussed in this article. See the reference section at the end for further information.
Ethernet Payload: For the purpose of the Sniffer here, we'll focus on the Ethernet frame and IP packets containing TCP data. In a hierarchical fashion, an Ethernet frame encapsulates the data for the upper layers (Fig. 3). The Ethernet data, or payload, is an IP frame with its own header and trailer information, and its own data portion or IP payload. The IP payload is a TCP frame.
By now, you should have a good understanding of what Ethernet and IEEE 802.3 look like. Ethernet, contained neatly within the TCP/IP Link layer, is the shell/carrier of all data going to and coming from your computer on a LAN.
For further information on this subject, and the Internet in general, check the Internet Request for Comments (RFC) documents in the references. There are two documents to get you started. The Sniffer described here uses the RFC 894 Ethernet encapsulation.
The Soft Part Is Hardware: Now it's time to move on to the hardware considerations of an embedded Ethernet design. Two main elements, the Ethernet controller and the microprocessor, must be considered when designing Ethernet connectivity into your design. As far as embedded systems go these days, designing the hardware is usually the easy part. ICs are well designed and they provide a straightforward interface when integrating a 10-Mbit/s Ethernet controller to a microprocessor.
Ethernet Controller: The generic Ethernet controller depicted in this article has three primary characteristics. It's NE2000 compatible, it has an ISA bus or ISA compatible interface, and it can operate in I/O or memory mode.
A typical off-the-shelf ISA Ethernet controller comes in a 100-pin PQFP package, has 16 kbytes of built-in SRAM, and complies with both CSMA/CD standards (IEEE 802.3 and Ethernet II). It also accommodates a common 10BaseT physical interface. Manufacturers like AMD, Crystal, and Realtek offer Ethernet controllers with these features and capabilities.
Microprocessor: Perhaps more important, the second task is selecting the microprocessor. Sufficient speed, a generous number of I/O ports, and low power consumption top the list of requirements.
A highly integrated, feature-rich processor can minimize or eliminate the need for peripheral circuitry, thereby reducing cost. Built-in ROM, EEPROM or flash, SRAM, serial I/O, ADCs, DACs, and timers are the minimum considerations. The Toshiba 900/H2 series processor was chosen for this project because it satisfied the company's basic criteria for high-speed operation—20 MHz and a 32-bit bus (Fig. 4).
Software Is The Hard Part: After the hardware is designed, the Sniffer can be "created" by configuring the Ethernet controller in a mode that's slightly different from its normal operation. This is critical. By using the proper configuration, the designer can create a dynamic system to decompose Ethernet frames and study their content. Once the hardware is configured, three steps remain:
- Set up the Ethernet controller configuration registers.
- Write the firmware to remove a complete Ethernet frame (data) from the controller's internal SRAM to the system memory.
- Parse the Ethernet frame into desired fields to display.
Ethernet Controller Configuration: To avoid communication conflicts, expect every piece of hardware attached to a LAN to be uniquely addressable. This is the first thing to keep in mind when configuring your hardware because it's up to you to set the address. As Ethernet addresses are 48 bits long, it's very easy to assign a unique Ethernet ad-dress. For this example, the address 11-22-33-44-55-66 will be used.
Once the address is set, you must configure the Receiver Control Registers. Normally, configuring an Ethernet controller requires a series of long, complicated steps. For the most part, it involves telling the controller which destination addresses it can and can't accept. For the application at hand, we avoid this obstacle by enabling the Promiscuous Mode bit. When this bit is set, the controller will accept and store any valid frame, regardless of the destination address, including the Broadcast frame FF-FF-FF-FF-FF-FF. Thus, a Sniffer is born.
Frame Capture And Move: After the Ethernet controller is configured, it automatically starts capturing frames. At this point, the host processor must poll the controller to see if a frame is ready to be read. This usually involves two steps.
First, the Receive Status Register has to be polled to see if a Frame Capture is complete. The second step is to read a Length Register, then perform simple memory-mapped reads for that length. This will result in an Ethernet frame of data being recorded in the system memory. Once the data has been read out in its entirety, the Ethernet controller will automatically start looking for a new frame and capture it to internal SRAM. It will stay there until the host either reads it out or flushes the buffer.
Parse And Display: The final steps concern parsing the Ethernet frame in the system memory, and displaying it to the user. For this Sniffer, we're only interested in displaying six pieces of information to the user:
- Ethernet source address.
- Ethernet destination address.
- IP source address.
- IP destination address.
- TCP source address port.
- TCP destination address port.
Main Executive: Software development is the final task. Depending on the intended purpose of the Sniffer, various software routines can be created to capture just the specific frames of interest. We used our example Sniffer to monitor and capture TCP/IP frames. The software startup routine initializes the microcontroller and the Ethernet chip. Each received Ethernet frame was inspected for IP type. Then, further TCP data were retrieved and displayed.
TCP/IP Illustrated, Volumes 1 and 2, Stevens, W. Richard, and Wright, Gary R.; Addison Wesley Longman Inc., 1994 (Vol. 1) and 1995 (Vol. 2).
Toshiba 900H2 Series Data Manual, http://doc.semicon.toshiba.co.jp/pdf_e/micon/900h2_1/index.htm.
Internet request for comments (RFC), RFC 894 and RFC 1042, www.cis.ohio-state.edu/Services/rfc/index.html.