Using the Capture command on a PIX firewall

A vital tool to use when troubleshooting computer networking problems and monitoring computer networks is a packet sniffer. That being said, one of the best methods to use when troubleshooting connection problems or monitoring suspicious network activity in a Cisco Systems PIX firewall is by using the capture command. Many times Cisco TAC will request captures from a PIX in PCAP format for open problem tickets associated with unusual problems or activity associated with the PIX and the network.

The capture command was first introduced to the PIX OS in version 6.2 and has the ability to capture all data that passes through the PIX device. You can use access-lists to specify the type of traffic that you wish to capture, along with the source and destination addresses and ports. Multiple capture statements can be used to attach the capture command to multiple interfaces. You can even copy the raw header and hexadecimal data in PCAP format to a tftp server and open it with TCPDUMP or Ethereal.

• NOTE: You must be in privileged mode to invoke the capture command.

Below is the command usage and syntax description per Cisco's PIX OS 7.0 documentation:

To enable packet capture capabilities for packet sniffing and network fault isolation, use the capture command. To disable packet capture capabilities, use the no form of this command (see the "Usage Guidelines" section for additional information about the no form of this command).

capture capture_name [access-list access_list_name] [buffer buf_size] [ethernet-type type] [interface interface_name] [packet-length bytes] [circular-buffer]

capture capture_name type asp-drop [drop-code] [buffer buf_size] [circular-buffer] [packet-length bytes]

capture capture_name type isakmp [access-list access_list_name] [buffer buf_size] [circular-buffer] [interfacepacket-length bytes] interface_name] [

capture capture_name type raw-data [access-list access_list_name] [buffer buf_size] [circular-buffer] [ethernet-type type] [interface interface_name] [packet-length bytes]

capture capture_name type webvpn user webvpn-user [url url]

no capture capture_name

 Syntax Description:

access-list access_list_name	(Optional) Selects packets based on IP or higher fields for a specific access list identification.
buffer buf_size	(Optional) Defines the buffer size used to store the packet in bytes.
capture_name	Specifies the name of the packet capture.
circular-buffer	(Optional) Overwrites the buffer, starting from the beginning, when the buffer is full.
ethernet-type type	(Optional) Selects an Ethernet type to capture.
interface interface_name	(Optional) Specifies the interface on which to use packet capture, where interface_name is the name assigned to the interface by the nameif command.
packet-length bytes	(Optional) Sets the maximum number of bytes of each packet to store in the capture buffer.
type asp-drop drop-code	(Optional) Captures packets dropped for a reason. You can specify a particular reason by using the drop-code argument. Valid values for the drop-code argument are listed in the "Usage Guidelines" section, below.
type isakamp	(Optional) Captures encrypted and decrypted ISAKMP payloads.
type raw-data	(Optional) Captures inbound and outbound packets on one or more interfaces. This is the default.
type webvpn	(Optional) Captures WebVPN data for a specific WebVPN connection.
url url	(Optional) Specifies a URL for a WebVPN connection capture.
user webvpn-user	(Optional) Specifies a username for a WebVPN capture.

 The Capture command defaults are as follows:

• The capture type is raw data.
• The buffer size is 512 KB.
• All the Ethernet types are accepted.
• All the IP packets are matched.
• The packet-length is 68 bytes.

 Since the documentation above is not very easy to interpret for a beginner, I will be providing a simple monitoring situation and example below to help familiarize you with the commands associated with running a packet capture on a Cisco Secure Pix Firewall.

EXAMPLE:  (NOTE: The following scenario is made up, the domain and IP addresses are invalid and purely for example.) You are wanting to monitor traffic between any users and a questionable Internet website from the inside to the outside via TCP port 80 for an internal security auditor needing proof of the transaction. The website www.madeupsite.com resolves with the IP address 192.168.1.1. In this example, the internal (Local) IP address is 10.1.1.1 and the external (Global) NAT IP Address is 192.168.2.2 and the PIX firewall is running 7.X code. To accomplish this first we will write an extended access-list to apply to the capture that will allow us to capture any TCP traffic from any source address or port to the destination address 192.168.1.1 port 80 and vice versa. Next we will apply a capture to both the inside and outside interfaces of the firewall such that we can capture all the data specified in the access-list. Then we will then copy the raw captures in PCAP format to a TFTP server on the inside network with the IP address 10.1.1.100 such that the files can be viewed with TCPDUMP or Ethereal. Finally we will remove the captures and access-list from the PIX firewall.

 Start: Secure Shell connection to the PIX:

 ! Go into global config mode and configure an extended access-list permitting any tcp traffic from any source host/port to destination host 192.168.1.1/port 80 and any tcp traffic from source host 192.168.1.1/port 80 to any destination host/port.

PIX# config t

PIX(config)# access-list webcap line 1 extended permit tcp any host 192.168.1.1 eq 80

PIX(config)# access-list webcap line 2 extended permit tcp host 192.168.1.1 eq 80 any

PIX(config)# exit

 ! Exit from global config mode and verify your access-list using the show access-list command.

PIX# show access-list webcap

access-list webcap; 2 elements

access-list webcap line 1 extended permit tcp any host 192.168.1.1 eq www (hitcnt=0)

access-list webcap line 2 extended permit tcp host 192.168.1.1 eq www any (hitcnt=0)

 ! From privileged mode configure two raw-data captures based on the access-list requirements configured above and apply one to the outside interface and one to the inside interface of the PIX firewall.

PIX# capture webcapinside type raw-data access-list webcap interface inside

PIX# capture webcapoutside type raw-data access-list webcap interface outside

 ! Verify your captures using the show capture command.

PIX# show capture

capture webcapinside type raw-data access-list webcap interface inside

capture webcapoutside type raw-data access-list webcap interface outside

 ! In this example we will assume that the captures were on long enough to capture the data below. This data consists of a TCP connection from 10.1.1.1 (Local) / 192.168.2.2 (Global) to 192.168.1.1 over port 80. The capture data is displayed in the PIX console by using the show capture command.

• NOTE: The data captured on the outside interface shows the source as the global IP.

PIX# show capture webcapoutside

17 packets captured

1: 09:03:02.244906 192.168.2.2.2536 > 192.168.1.1.80: S 39829922:39829922(0) win 65535 <mss 1260,nop,nop,sackOK>

2: 09:03:02.275620 192.168.1.1.80 > 192.168.2.2.2536: S 1295066193:1295066193(0) ack 39829923 win 5840 <mss 1380>

3: 09:03:02.275940 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295066194 win 65535

4: 09:03:02.282303 192.168.2.2.2536 > 192.168.1.1.80: P 39829923:39830620(697) ack 1295066194 win 65535

5: 09:03:02.314864 192.168.1.1.80 > 192.168.2.2.2536: . ack 39830620 win 6970

6: 09:03:05.029722 192.168.1.1.80 > 192.168.2.2.2536: . 1295066194:1295067454(1260) ack 39830620 win 6970

7: 09:03:05.030805 192.168.1.1.80 > 192.168.2.2.2536: . 1295067454:1295068714(1260) ack 39830620 win 6970

8: 09:03:05.031309 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295068714 win 65535

9: 09:03:05.064129 192.168.1.1.80 > 192.168.2.2.2536: . 1295068714:1295069974(1260) ack 39830620 win 6970

10: 09:03:05.065182 192.168.1.1.80 > 192.168.2.2.2536: . 1295069974:1295071234(1260) ack 39830620 win 6970

11: 09:03:05.065700 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295071234 win 65535

12: 09:03:05.066296 192.168.1.1.80 > 192.168.2.2.2536: . 1295071234:1295072494(1260) ack 39830620 win 6970

13: 09:03:05.098597 192.168.1.1.80 > 192.168.2.2.2536: . 1295072494:1295073754(1260) ack 39830620 win 6970

14: 09:03:05.099146 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295073754 win 65535

15: 09:03:05.099588 192.168.1.1.80 > 192.168.2.2.2536: . 1295073754:1295075014(1260) ack 39830620 win 6970

16: 09:03:05.100168 192.168.1.1.80 > 192.168.2.2.2536: P 1295075014:1295075958(944) ack 39830620 win 6970

17: 09:03:05.100595 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295075958 win 65535

17 packets shown

 

• NOTE: The data captured on the intside interface shows the source as the local IP.

PIX# show capture webcapinside

17 packets captured

1: 09:03:02.244784 10.1.1.1.2536 > 192.168.1.1.80: S 4015780382:4015780382(0) win 65535 <mss 1260,nop,nop,sackOK>

2: 09:03:02.275651 192.168.1.1.80 > 10.1.1.1.2536: S 2468538302:2468538302(0) ack 4015780383 win 5840 <mss 1380>

3: 09:03:02.275895 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468538303 win 65535

4: 09:03:02.282288 10.1.1.1.2536 > 192.168.1.1.80: P 4015780383:4015781080(697) ack 2468538303 win 65535

5: 09:03:02.314894 192.168.1.1.80 > 10.1.1.1.2536: . ack 4015781080 win 6970

6: 09:03:05.029753 192.168.1.1.80 > 10.1.1.1.2536: . 2468538303:2468539563(1260) ack 4015781080 win 6970

7: 09:03:05.030821 192.168.1.1.80 > 10.1.1.1.2536: . 2468539563:2468540823(1260) ack 4015781080 win 6970

8: 09:03:05.031278 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468540823 win 65535

9: 09:03:05.064144 192.168.1.1.80 > 10.1.1.1.2536: . 2468540823:2468542083(1260) ack 4015781080 win 6970

10: 09:03:05.065197 192.168.1.1.80 > 10.1.1.1.2536: . 2468542083:2468543343(1260) ack 4015781080 win 6970

11: 09:03:05.065670 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468543343 win 65535

12: 09:03:05.066311 192.168.1.1.80 > 10.1.1.1.2536: . 2468543343:2468544603(1260) ack 4015781080 win 6970

13: 09:03:05.098612 192.168.1.1.80 > 10.1.1.1.2536: . 2468544603:2468545863(1260) ack 4015781080 win 6970

14: 09:03:05.099131 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468545863 win 65535

15: 09:03:05.099619 192.168.1.1.80 > 10.1.1.1.2536: . 2468545863:2468547123(1260) ack 4015781080 win 6970

16: 09:03:05.100199 192.168.1.1.80 > 10.1.1.1.2536: P 2468547123:2468548067(944) ack 4015781080 win 6970

17: 09:03:05.100580 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468548067 win 65535

17 packets shown

 ! Now we will copy the raw data that we captured to a tftp server on the inside network with the IP address of 10.1.1.100 in PCAP format using the copy /pcap command.

• ! NOTE: The !!!!! indicates successful transfer of data.

PIX# copy /pcap capture:webcapinside tftp:

Source capture name [webcapinside]? <enter>

Address or name of remote host []? 10.1.1.100

Destination filename [webcapinside]? <enter> ! NOTE: The filename could be changed here.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 NOTE: The !!!!! indicates successful transfer of data.

PIX# copy /pcap capture:webcapoutside tftp:

Source capture name [webcapoutside]? <enter>

Address or name of remote host []? 10.1.1.100

Destination filename [webcapoutside]? <enter> ! NOTE: The filename could be changed here.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 ! Now we will remove the captures from the PIX firewall using the no form of the capture command.

PIX# no capture webcapinside type raw-data access-list webcap interface inside.

PIX# no capture webcapoutside type raw-data access-list webcap interface outside

 ! Finally we will remove the access-list entries from the PIX firewall using the no form of the access-list command.

PIX# config t

PIX(config)# access-list webcap line 1 extended permit tcp any host 192.168.1.1 eq 80

PIX(config)# access-list webcap line 2 extended permit tcp host 192.168.1.1 eq 80 any

PIX(config)# exit

PIX#

 Now we have accomplished our task and the captures wanted by the auditor can be opened with TCPDUMP or Ethereal from the TFTP server. I hope you've enjoyed this simple tutorial on using the capture command in the PIX firewall. This command can be very powerful and very useful if configured properly.

---------------------------------------------------------------------------------

Article courtesy of www.ComputerNetworkingHelp.com

SYNCHRONOUS SERIAL COMMUNICATION OVERVIEW

---

Coordinated Speed

As its name implies, synchronous communication takes place between a transmitter and a receiver operating on synchronized clocks. In a synchronous system, the communication partners have a short conversation before data exchange begins. In this conversation, they align their clocks and agree upon the parameters of the data transfer, including the time interval between bits of data. Any data that falls outside these parameters will be assumed to be either in error or a placeholder used to maintain synchronization. (Synchronous lines must remain constantly active in order to maintain synchronization, thus the need for placeholders between valid data.) Once each side knows what to expect of the other, and knows how to indicate to the other whether what was expected was received, then communication of any length can commence.

The theory behind asynchronous and synchronous communication is essentially the same: Point B needs to know when a transmission from Point A begins, when it ends, and if it was processed correctly. However, the difference lies in how the transmission is broken down. Think of the difference in terms of a friendly chat. With asynchronous communication you would need to stop after every word to make sure the listener understood your meaning, and knew that you were about to speak the next word. With synchronous communication, you would establish with your listener that you were speaking English, that you will be speaking words at measured intervals, and that you would utter a complete sentence, or paragraph, or extended soliloquy, before pausing to confirm understanding. Further, you would establish with your listener beforehand that any extraneous noises you make during the speech or between speeches (coughing, burping, hiccupping) should be ignored. Clearly the second approach is much faster, even though initializing communication may take slightly longer. In fact, by replacing the start, stop and parity bits around individual words with start, stop and control (processing instructions and error checking) sequences around large continuous data blocks, synchronous communication is about 30% faster than asynchronous communication, before any other factors are considered.

Clock Synchronization

In order to initiate a successful synchronous communication link, several distinct pieces of hardware must be configured around a common clock. This configuration must take two data lines into account, the transmission line (the line it uses to send data) and the reception line (the line it uses to receive data). It is essential not only that all devices in the system be synchronized with each other, but also that each individual device have its transmission and reception lines synchronized as well.

There are three clocking methods by which to achieve synchronization: internal, external, and recovered clocking. All three methods derive the clock signal for the reception line from the incoming data. The clock signal for the transmission line will always be generated by the devices internal oscillator, but the phase reference used by the internal oscillator differs for each of the clocking methods. When internal clocking is used, the transmit clock is phase locked to the device's own internal oscillator. For external clocking, the transmit clock is phase locked to the phase of the oscillator belonging to another device in the network. For recovered clocking, the transmit clock phase is locked to the clock derived from the incoming data.

In general, the DCE device (such as a modem) uses internal clocking, while the DTE device (such as a PC) uses external clocking and synchronizes around the DCE device. (See the RS-232 overview for a discussion of DTE and DCE devices.) In cases where DTE-DTE or DCE-DCE connections are necessary, one device must be configured atypically, or a device such as a modem-eliminator or tail-circuit buffer must be placed between the two. However, in large networks with multiple devices this is not always possible. One solution for such networks is to have all devices synchronize around a single modem's clock source. However, this solution has the tendency to result in clock drift, and thus can potentially corrupt data. The other solution is to use recovered clocking so that a modem can derive the clock from data on its reception line then send that information out on its transmit line to be used by the next modem in line, etc.

Byte Oriented Synchronous Protocols

Synchronous communication can be implemented for full and half-duplex networks using bit- or byte-oriented protocols. Half-duplex networks, whether point-to-point or multipoint, can only support communication in one direction at a time. The most commonly used protocol for such networks is IBM's Binary Synchronous Communication Procedures (BiSync). BiSync is a byte oriented protocol, which means that it approaches transmitted data as “blocks" that must each be decoded and tracked to determine what they are, and what they are telling the receiver to do.

In a BiSync system one computer is designated as a control station. It is responsible for initiating all data transfers, and thereby controlling the direction of flow on the communication line. Byte-oriented communication begins with establishing synchronization, it then establishes communication parameters that define instructions for processing given bit sequences. Finally, the actual data will be transmitted, and then followed by several frames that validate the transmission. BiSync transmission is also governed by a strict set of rules for data transmission. These rules require frequent handshaking and validation--speaking in sentences rather than paragraphs between pauses. As a result of the extensive handshaking, and because communication can take place in only one direction, BiSync communication is best suited for low-speed applications.

Byte Oriented Synchronous Protocols

In bit-oriented protocols, data is accepted as a long string of bits whose order does not impart specific instructions to the receiver. Data is flagged by a set bit pattern at either end, and is validated by a single frame check sequence at the end of the message that either accepts it or demands retransmission. Any bits received outside of valid flag sequences are ignored as placeholders.

Clearly, bit-oriented communication requires considerably less overhead than byte-oriented communication, because it is not constantly attempting to match bit sequences to numerous predetermined arrangements. The only sequence the bit-oriented protocol is concerned with identifying is the flag sequence. Bit protocols have other advantages over byte protocols as well. In a byte-oriented system, because of the constant handshaking, communication can take place in only one direction at a time. In bit-oriented systems, both ends can talk to each other at once, enabling effective use of full-duplex networks. Further, a single master device using bit protocols can communicate with multiple slave devices by using an address field following the start of message flag. This address field is tailored to each individual slave, and slaves only process data that is specifically addressed to them. Likewise, when the master receives from the slave, it knows from precisely where the transmission originated.

The two main bit-oriented protocols used today are Synchronous Data Link Control (SDLC) and High-Level Data Link Control (HDLC). SDLC, which was developed by IBM in the 1970s, is based around a network of primary and secondary network nodes. The primary controls the network and continually polls the secondaries to determine whether they have data to transmit. Four configurations are available for SDLC networks:

• Point to Point: one primary connected to one secondary
• Multipoint: one primary connected to multiple secondaries
• Loop: one primary connects to the first and last secondary, and secondaries in the middle pass messages through each other to the primary.
• Hub go-ahead: Uses one inbound and one outbound channel. The primary sends on the outbound channel and the secondaries send on the inbound channel. Secondaries pass messages through each other back to the primary.

Key to SDLC communication is the control characters it uses to maintain data integrity. The figure below shows the six fields that comprise a single SDLC data frame.

Flag

Address

Control

Data

Frame Check Sequence

Flag

The Flag field starts and ends error checking. The Address field is used to indicate the intended data destination, and can be a single address, a group of addresses, or a broadcast to the entire network. The Data field is the information being transmitted, and the Frame Check Sequence (FCS) is generally a Cyclic Redundancy Check (CRC) calculation. A calculation on the transmitted data is done by the transmitter and the result is sent in the FCS. This calculation is then performed by the receiver after data transmission is complete. If the results don't match, an error is assumed.

The Control field uses three different formats depending on the type of SDLC frame. The diagram below breaks out the different data bits in the control field. Explanations for the three control formats follow.

 

(Control Field Formats for SDLC Frames)

The Information Frame is used when actual data is being transmitted. It is also used to provide sequencing, flow and error control functions. The sequence number bits are used to indicate the number of the frame that will be sent/received next, and are used by both the primary and secondary nodes. The Poll Final bit is used by the primary to tell the secondary whether or not an immediate response is required. The secondary uses the Poll Final bit to indicate whether the current frame is the last in its response, or whether more frames are coming.

The Supervisory Frame is used to control the communication network. It can request or suspend data transfer, report status, and acknowledge receipt of data. Note that since Supervisory frames are used exclusively for control, they do not have data fields.

The Unnumbered Frame is unsequenced, can contain one or two bytes, and is used to provide miscellaneous control commands. For instance, it might be used by a primary node to activate the secondary nodes in the network.

Another bit-oriented synchronous communication protocol, High Level Data Link Control (HDLC) which is based on SDLC, also uses the frame format described above. However HDLC, which was approved by the International Standards Organization (ISO) in 1979, differs from SDLC in several ways. With HDLC, 32-bit checksums can be used, thereby providing an advantage over SDLC in the sophistication and accuracy of error checking, and thus data integrity. Unlike SDLC, HDLC protocols cannot operate using loop or hub go-ahead configurations.

The largest difference between the two, is that SDLC uses only a single transfer mode, while HDLC provides three choices. Both use Normal Response Mode (NRM) in which a secondary node is precluded from communicating with a primary node until the primary gives permission. The two additional HDLC modes are Asynchronous Response Mode (ARM) and Asynchronous Balanced Mode (ABM). In ARM mode, any secondary can initiate communication without receiving permission from the primary. ABM mode requires that all devices be configured as combination nodes that, depending on the situation, can assume the role of primary or secondary in the network. In such a system, any device can initiate communication at any time without permission.

Data Buffers

Though synchronous communication enables transmission of large amounts of data at high speed, it puts in place extensive control and error-checking mechanisms to prevent data corruption. However, in full-duplex networks using bit-oriented protocols, the transmitter is most likely sending frame B before it knows if frame A was received successfully. (This is not as much of a problem in slower byte-oriented protocols where data flows in only one direction at a time.) To maintain the highest possible data rates, synchronous hardware must contain sufficient data buffers to store transmitted data (for resending if necessary) until a successful transfer is confirmed.

Quatech synchronous serial PCMCIA and PCI cards use a 1024-byte FIFO for data buffering. Our ISA synchronous cards use DMA. All support both bit and byte protocols, and point-to-point and multipoint full- and half-duplex networks. We also supply SyncDrive and SyncDrive Plus software with all synchronous cards. SYNCDrive provides hardware specific device drivers, DLLs and APIs to simplify incorporating Quatech boards into your BiSync, SDLC and HDLC applications under DOS, Windows 98/98/Me and OS/2. SyncDrive Plus provides device drivers for SDLC and HDLC applications under Windows 2000/XP.

----------------------------------------------------------------------------------------------------------------------

Article courtesy of quatech.com

ASYNCHRONOUS SERIAL COMMUNICATION OVERVIEW

---

The Simple, Inexpensive Choice

Most PC serial devices such as mice, keyboards and modems are asynchronous. Asynchronous communication requires nothing more than a transmitter, a receiver and a wire. It is thus the simplest of serial communication protocols, and the least expensive to implement. As the name implies, asynchronous communication is performed between two (or more) devices which operate on independent clocks. Therefore, even if the two clocks agree for a time, there is no guarantee that they will continue to agree over extended periods, and thus there is no guarantee that when point A begins transmitting, point B will begin receiving, or that Point B will continue to sample at the rate Point A transmits. See the figure below for an illustration of what happens when transmission clocks differ significantly.

To combat this timing problem, asynchronous communication requires additional bits to be added around actual data in order to maintain signal integrity. Asynchronously transmitted data is preceded with a start bit which indicates to the receiver that a word (a chunk of data broken up into individual bits) is about to begin. To avoid confusion with other bits, the start bit is twice the size of any other bit in the transmission. The end of a word is followed by a stop bit, which tells the receiver that the word has come to an end, that it should begin looking for the next start bit, and that any bits it receives before getting the start bit should be ignored. To ensure data integrity, a parity bit is often added between the last bit of data and the stop bit. The parity bit makes sure that the data received is composed of the same number of bits in the same order in which they were sent. Use the link below to view a portrayal of how asynchronous communication works.

asynchronous communication, data is preceded with a start bit which indicates to the receiver that a word (a chunk of data broken up into individual bits) is about to begin. To avoid confusion with other bits, the start bit is twice the size of any other bit in the transmission. The end of a word is followed by a stop bit, which tells the receiver that the word has come to an end, that it should begin looking for the next start bit, and that any bits it receives before getting the start bit should be ignored. To insure data integrity, a parity bit is often added between the last bit of data and the stop bit. The parity bit makes sure that the data received is composed of the same number of bits in the same order in which they were sent. See the diagram in Figure 11 for a portrayal of how asynchronous communication works.

Upgraded UARTs For Increased Performance

At the heart of every asynchronous serial system is the Universal Asynchronous Receiver/Transmitter or UART. The UART is responsible for implementing the asynchronous communication process described above as both a transmitter and a receiver (both encoding and decoding data frames). The UART not only controls the transfer of data, but the speed at which communication takes place. However, the first UARTs could only handle one byte of information at a time, which meant that the computer needed to immediately process any transmission or risk losing data as the next byte of information pushed its way onto the UART. Not only does this makes for unreliable and slow communication, it can slow down the entire system.

Improved UARTs, such as the 16750 UARTs, increase communication speed and lower system overhead by offering 64-byte FIFOs (first in first out buffers). With the 64-byte FIFO buffer, the UART can store enough information that the data stream need not be suspended while the computer is busy. This is particularly helpful in heavy multitasking operating systems such as Windows 95/98/Me/NT/2000/XP and OS/2.

Enhanced Serial Adapters for Even More Speed

Even with top of the line 16750 UARTs, a standard serial board with a standard 1.8432 MHz clock can only reach data transfer rates of 115.2 kbps. This is because the UART sets the baud rate by dividing down the clock frequency, and the lower the clock speed, the lower the possible data rate. An obvious solution to faster data rates is to simply get a faster clock--and many Quatech serial boards can be custom configured with upgraded crystals to achieve higher speeds. The other solution is to create a faster clock from the standard clock by multiplying its frequency. Quatech enhanced serial adapters do just that.

All Quatech PCI serial products are based on the enhanced design, as are some of the ISA and PCMCIA asynchronous serial boards. The standard clock rate on these boards can be multiplied by a factor of one, two, four, or eight by using jumper or software controls. High baud rates, up to 921.6 kbps, can be produced through a combination of changing the clock rate multiplier and the UART baud rate divisor (see chart below). For example, a baud rate of 230.4 kbps could be achieved by setting the clock rate multiplier to X2 and setting a software application for 115.2 kbps. However, because of the limitations of the 16-byte FIFOs on 16550 UARTs, 16750 UARTs will be needed to take full advantage of 4X and 8X clock multiplying.

Clock Rate Multiplier	UART Clock Frequency	Max Data Rate
X1	1.832 MHz	115.2 kbaud
X2	3.6834 MHz	230.4 kbaud
X3	7.3728 MHz	460.8 kbaud
X4	14.7456 MHz	921.6 kbaud

-----------------------------------------------------------------------------------------------------------------------
Artice courtesy of quatech.com

Point-to-Point Protocol

---

Introduction

The Point-to-Point Protocol (PPP) originally emerged as an encapsulation protocol for transporting IP traffic over point-to-point links. PPP also established a standard for the assignment and management of IP addresses, asynchronous (start/stop) and bit-oriented synchronous encapsulation, network protocol multiplexing, link configuration, link quality testing, error detection, and option negotiation for such capabilities as network layer address negotiation and data-compression negotiation. PPP supports these functions by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCPs) to negotiate optional configuration parameters and facilities. In addition to IP, PPP supports other protocols, including Novell's Internetwork Packet Exchange (IPX) and DECnet.

PPP Components

PPP provides a method for transmitting datagrams over serial point-to-point links. PPP contains three main components:

•A method for encapsulating datagrams over serial links. PPP uses the High-Level Data Link Control (HDLC) protocol as a basis for encapsulating datagrams over point-to-point links. (See Chapter 16, "Synchronous Data Link Control and Derivatives," for more information on HDLC.)

•An extensible LCP to establish, configure, and test the data link connection.

•A family of NCPs for establishing and configuring different network layer protocols. PPP is designed to allow the simultaneous use of multiple network layer protocols.

General Operation

To establish communications over a point-to-point link, the originating PPP first sends LCP frames to configure and (optionally) test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, the originating PPP sends NCP frames to choose and configure one or more network layer protocols. When each of the chosen network layer protocols has been configured, packets from each network layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP frames close the link, or until some external event occurs (for example, an inactivity timer expires or a user intervenes).

Physical Layer Requirements

PPP is capable of operating across any DTE/DCE interface. Examples include EIA/TIA-232-C (formerly RS-232-C), EIA/TIA-422 (formerly RS-422), EIA/TIA-423 (formerly RS-423), and International Telecommunication Union Telecommunication Standardization Sector (ITU-T) (formerly CCITT) V.35. The only absolute requirement imposed by PPP is the provision of a duplex circuit, either dedicated or switched, that can operate in either an asynchronous or synchronous bit-serial mode, transparent to PPP link layer frames. PPP does not impose any restrictions regarding transmission rate other than those imposed by the particular DTE/DCE interface in use.

PPP Link Layer

PPP uses the principles, terminology, and frame structure of the International Organization for Standardization (ISO) HDLC procedures (ISO 3309-1979), as modified by ISO 3309:1984/PDAD1 "Addendum 1: Start/Stop Transmission." ISO 3309-1979 specifies the HDLC frame structure for use in synchronous environments. ISO 3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to allow its use in asynchronous environments. The PPP control procedures use the definitions and control field encodings standardized in ISO 4335-1979 and ISO 4335-1979/Addendum 1-1979. The PPP frame format appears in Figure 13-1.

Figure 13-1 Six Fields Make Up the PPP Frame

The following descriptions summarize the PPP frame fields illustrated in Figure 13-1:

•Flag—A single byte that indicates the beginning or end of a frame. The flag field consists of the binary sequence 01111110.

•Address—A single byte that contains the binary sequence 11111111, the standard broadcast address. PPP does not assign individual station addresses.

•Control—A single byte that contains the binary sequence 00000011, which calls for transmission of user data in an unsequenced frame. A connectionless link service similar to that of Logical Link Control (LLC) Type 1 is provided. (For more information about LLC types and frame types, refer to Chapter 16.)

•Protocol—Two bytes that identify the protocol encapsulated in the information field of the frame. The most up-to-date values of the protocol field are specified in the most recent Assigned Numbers Request For Comments (RFC).

•Data—Zero or more bytes that contain the datagram for the protocol specified in the protocol field. The end of the information field is found by locating the closing flag sequence and allowing 2 bytes for the FCS field. The default maximum length
of the information field is 1,500 bytes. By prior agreement, consenting PPP implementations can use other values for the maximum information field length.

•Frame check sequence (FCS)—Normally 16 bits (2 bytes). By prior agreement, consenting PPP implementations can use a 32-bit (4-byte) FCS for improved error detection.

The LCP can negotiate modifications to the standard PPP frame structure. Modified frames, however, always will be clearly distinguishable from standard frames.

PPP Link-Control Protocol

The PPP LCP provides a method of establishing, configuring, maintaining, and terminating the point-to-point connection. LCP goes through four distinct phases.

First, link establishment and configuration negotiation occur. Before any network layer datagrams (for example, IP) can be exchanged, LCP first must open the connection and negotiate configuration parameters. This phase is complete when a configuration-acknowledgment frame has been both sent and received.

This is followed by link quality determination. LCP allows an optional link quality determination phase following the link-establishment and configuration-negotiation phase. In this phase, the link is tested to determine whether the link quality is sufficient to bring up network layer protocols. This phase is optional. LCP can delay transmission of network layer protocol information until this phase is complete.

At this point, network layer protocol configuration negotiation occurs. After LCP has finished the link quality determination phase, network layer protocols can be configured separately by the appropriate NCP and can be brought up and taken down at any time. If LCP closes the link, it informs the network layer protocols so that they can take appropriate action.

Finally, link termination occurs. LCP can terminate the link at any time. This usually is done at the request of a user but can happen because of a physical event, such as the loss of carrier or the expiration of an idle-period timer.

Three classes of LCP frames exist. Link-establishment frames are used to establish and configure a link. Link-termination frames are used to terminate a link, and link-maintenance frames are used to manage and debug a link.

These frames are used to accomplish the work of each of the LCP phases.

Summary

The Point-to-Point Protocol (PPP) originally emerged as an encapsulation protocol for transporting IP traffic over point-to-point links. PPP also established a standard for assigning and managing IP addresses, asynchronous and bit-oriented synchronous encapsulation, network protocol multiplexing, link configuration, link quality testing, error detection, and option negotiation for added networking capabilities.

PPP provides a method for transmitting datagrams over serial point-to-point links, which include the following three components:

•A method for encapsulating datagrams over serial links

•An extensible LCP to establish, configure, and test the connection

•A family of NCPs for establishing and configuring different network layer protocols

PPP is capable of operating across any DTE/DCE interface. PPP does not impose any restriction regarding transmission rate other than those imposed by the particular DTE/DCE interface in use.

Six fields make up the PPP frame. The PPP LCP provides a method of establishing, configuring, maintaining, and terminating the point-to-point connection.

---

Article courtesy of the Cisco Internetworking Handbook