| <HTML><HEAD> | |
| <STYLE type="text/css"> | |
| <!-- | |
| A { text-decoration:none } | |
| --> | |
| </STYLE> | |
| </HEAD> | |
| <BODY> | |
| <TABLE WIDTH=100%><TR> | |
| <TD ALIGN=LEFT VALIGN=TOP> | |
| <FONT SIZE=+0 FACE="COURIER"><B>A "Distributed Pcap" for<BR>Remote Monitoring LANs & WANs</B><BR> | |
| (Design Notes for the SITA ACN device)</FONT> | |
| </TD> | |
| <TD ALIGN=RIGHT VALIGN=TOP> | |
| Fulko Hew<BR>SITA INC Canada, Inc.<BR>Revised: October 2, 2007 | |
| </TD> | |
| </TR></TABLE> | |
| <H3>SUMMARY</H3> | |
| <UL> | |
| <STRONG>Note:</STRONG> This document is part of the libpcap Git and was derived from 'pcap.3' (circa Aug/07). | |
| <P> | |
| The ACN provides a customized/distributed version of this library that alows SMPs to | |
| interact with the various IOPs within the site providing a standard mechanism | |
| to capture LAN and WAN message traffic. | |
| <P> | |
| <CENTER> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3 WIDTH=75%> | |
| <TR> | |
| <TH VALIGN=TOP>SMP</TH> | |
| <TD VALIGN=TOP>The Supervisory Management Processor where Wireshark (or equivalent) | |
| runs in conjuction with a libpcap front-end.</TD> | |
| </TR> | |
| <TR> | |
| <TH VALIGN=TOP>IOP</TH> | |
| <TD VALIGN=TOP>I/O Processors where the monitored ports exist in conjunction | |
| with a custom device driver/libpcap back-end.</TD> | |
| </TR> | |
| </TABLE> | |
| </CENTER> | |
| <P> | |
| Each IOP will be capable of supporting multiple connections from an SMP | |
| enabling monitoring of more than one interface at a time, each through | |
| its own seperate connection. The IOP is responsible to ensure and report | |
| an error if any attempt is made to monitor the same interface more than once. | |
| <P> | |
| There are three applications that will be supported by the ACN version of libpcap. | |
| They each use a slightly different mode for looping/capturing and termination | |
| as summarized in the following table: | |
| <P> | |
| <CENTER> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR><TH>Application</TH> <TH>Capture</TH> <TH>Termination</TH></TR> | |
| <TR><TH VALIGN=TOP NOWRAP>wireshark</TH> | |
| <TD VALIGN=TOP>pcap_dispatch(all packets in one buffer of capture only)</TD> | |
| <TD VALIGN=TOP>pcap_breakloop()</TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>tshark</TH> | |
| <TD VALIGN=TOP>pcap_dispatch(one buffer of capture only)</TD> | |
| <TD VALIGN=TOP>Since a CTRL-C was used to terminate the application, pcap_breakloop() is never called.</TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>tcpdump</TH> | |
| <TD VALIGN=TOP>pcap_loop(all packets in the next buffer, and loop forever)</TD> | |
| <TD VALIGN=TOP>pcap_breakloop()</TD> | |
| </TR> | |
| </TABLE> | |
| </CENTER> | |
| <P> | |
| <B>Note: </B>In all cases, the termination of capturing is always (apparently) followed by | |
| pcap_close(). Pcap_breakloop() is only used to stop/suspend looping/processing, | |
| and upon close interpretation of the function definitions, it is possible to resume | |
| capturing following a pcap_breakloop() without any re-initialization. | |
| <P> | |
| <H4>ACN Limitations</H4> | |
| <OL> | |
| <LI>Monitoring of backup IOPs is not currently supported. | |
| <LI>Ethernet interfaces cannot be monitored in promiscuous mode. | |
| </OL> | |
| </UL> | |
| <H3>ROUTINES</H3> | |
| <UL> | |
| The following list of functions is the sub-set of Pcap functions that have been | |
| altered/enhanced to support the ACN remote monitoring facility. The remainder of the Pcap | |
| functions continue to perform their duties un-altered. Libpcap only supports this | |
| mode of operation if it has been configured/compiled for SITA/ACN support. | |
| <P> | |
| <UL><FONT FACE=COURIER> | |
| pcap_findalldevs<BR> | |
| pcap_freealldevs<BR> | |
| pcap_open_live<BR> | |
| pcap_close<BR> | |
| pcap_setfilter<BR> | |
| pcap_dispatch<BR> | |
| pcap_loop<BR> | |
| pcap_next<BR> | |
| pcap_next_ex<BR> | |
| pcap_stats<BR> | |
| </FONT></UL> | |
| These subroutines have been modified for the ACN specific distributed and remote monitoring | |
| ability perform the following basic functions. More detail is provided in the | |
| "SMP/IOP Inter-Process Communication Protocol" section. | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_open_live()</B></TD> | |
| <TD VALIGN=TOP>Used to obtain a packet capture descriptor to look at packets on the network.</TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| The SMP will open a connection to the selected IOP on its 'sniffer' port | |
| to ensure it is available. It sends a null terminated string identifying | |
| the interface to be monitored. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP -> SMP</TH> | |
| <TD> | |
| After any required processing is complete, the IOP will return a | |
| null terminated string containing an error message if one occured. | |
| If no error occured, a empty string is still returned. | |
| Errors are: | |
| <UL> | |
| <LI>"Interface (xxx) does not exist." | |
| <LI>"Interface (xxx) not configured." | |
| <LI>"Interface (xxx) already being monitored." | |
| </UL> | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_findalldevs()</B></TD> | |
| <TD VALIGN=TOP>It constructs a list of network devices that can be opened with pcap_open_live().</TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP</TH> | |
| <TD> | |
| It obtains a list of IOPs currently available (via /etc/hosts). | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| The SMP will sequentially open a connection to each IOP on its 'sniffer' port to ensure | |
| the IOP is available. | |
| It sends a null terminated empty interface ID followed by the query request command. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP -> SMP</TH> | |
| <TD>The IOP returns an error response and its list of devices. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| The SMP closes the TCP connection with each IOP. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP</TH> | |
| <TD> | |
| The SMP adds the received information to its internal structure. | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_freealldevs()</B></TD> | |
| <TD VALIGN=TOP>Used to free a list allocated by pcap_findalldevs().</TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP</TH> | |
| <TD> | |
| The SMP frees the structure it built as a result of the previous | |
| invocation of pcap_findalldevs(). | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_dispatch()</B></TD> | |
| <TD VALIGN=TOP>Used to collect and process packets.</TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| On the first invocation of pcap_dispatch(), pcap_loop(), or pcap_next(), or pcap_next_ex() following a pcap_open_live(), | |
| the SMP will pass down the monitor start command and various parameters the IOP should use. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP -> SMP</TH> | |
| <TD> | |
| The IOP now sends a stream of captured data. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP</TH> | |
| <TD> | |
| The SMP will read the reverse channel of the connection between the SMP and the | |
| IOP that provides the captured data (via 'p->read_op' which is 'pcap_read_linux()' | |
| until the select() call returns a 'no more data' indication. | |
| It will the process (at most) the next 'cnt' packets and invoke the specified | |
| callback function for each packet processed. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP</TH> | |
| <TD> | |
| The IOP continues to listen for additional commands as well as capturing and forwarding data to the SMP. | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_loop()</B></TD> | |
| <TD VALIGN=TOP> | |
| Is similar to pcap_dispatch() except it keeps reading packets until | |
| the requested number of packets are processed or an error occurs. | |
| </TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| On the first invocation of pcap_dispatch(), pcap_loop(), or pcap_next(), or pcap_next_ex() following a pcap_open_live(), | |
| the SMP will pass down the monitor start command and various parameters the IOP should use. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP -> SMP</TH> | |
| <TD> | |
| The IOP now sends a stream of captured data. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP</TH> | |
| <TD> | |
| The SMP continuously reads the next packet from the reverse channel of the connection | |
| between the SMP and the IOP that provides the captured data (via 'p->read_op' | |
| which is 'pcap_read_linux()' until 'cnt' packets have been received. | |
| The specified callback function will be invoked for each packet received. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP</TH> | |
| <TD> | |
| The IOP continues to listen for additional commands as well as capturing and forwarding data to the SMP. | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_next()</B></TD> | |
| <TD VALIGN=TOP> | |
| It reads the next packet (by calling pcap_dispatch() with a count of 1) | |
| and returns a pointer to the data in that packet. | |
| </TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| On the first invocation of pcap_dispatch(), pcap_loop(), or pcap_next(), or pcap_next_ex() following a pcap_open_live(), | |
| the SMP will pass down the monitor start command and various parameters the IOP should use. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP -> SMP</TH> | |
| <TD> | |
| The IOP now sends a stream of captured data. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP</TH> | |
| <TD> | |
| The SMP reads only the next packet from the reverse channel of the connection | |
| between the SMP and the IOP that provides the captured data (via calling pcap_dispatch() | |
| with a count of 1) and returns a pointer to that data by invoking an internal callback. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP</TH> | |
| <TD> | |
| The IOP continues to listen for additional commands as well as capturing and forwarding data to the SMP. | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_next_ex()</B></TD> | |
| <TD VALIGN=TOP>Reads the next packet and returns a success/failure indication.</TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| On the first invocation of pcap_dispatch(), pcap_loop(), or pcap_next(), or pcap_next_ex() following a pcap_open_live(), | |
| the SMP will pass down the monitor start command and various parameters the IOP should use. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP -> SMP</TH> | |
| <TD> | |
| The IOP now sends a stream of captured data. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP</TH> | |
| <TD> | |
| The SMP reads only the next packet from the reverse channel of the connection | |
| between the SMP and the IOP that provides the captured data (via calling pcap_dispatch() | |
| with a count of 1) and returns seperate pointers to both the | |
| packet header and packet data by invoking an internal callback. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP</TH> | |
| <TD> | |
| The IOP continues to listen for additional commands as well as capturing and forwarding data to the SMP. | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_setfilter()</B></TD> | |
| <TD VALIGN=TOP>Used to specify a filter program.</TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| The SMP sends a 'set filter' command followed by the BPF commands. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP -> SMP</TH> | |
| <TD> | |
| The IOP returns a null terminated error string if it failed to accept the filter. | |
| If no error occured, then a NULL terminated empty string is returned instead. | |
| Errors are: | |
| <UL> | |
| <LI>"Invalid BPF." | |
| <LI>"Insufficient resources for BPF." | |
| </UL> | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_stats()</B></TD> | |
| <TD VALIGN=TOP>Fills in a pcap_stat struct with packet statistics.</TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| The SMP sends a message to the IOP requesting its statistics. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP -> SMP</TH> | |
| <TD> | |
| The IOP returns the statistics. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP</TH> | |
| <TD> | |
| The SMP fills in the structure provided with the information retrieved from the IOP. | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2><B>pcap_close()</B></TD> | |
| <TD VALIGN=TOP>Closes the file and deallocates resources.</TD> | |
| </TR> | |
| <TR><TD><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=100%> | |
| <TR><TH VALIGN=TOP NOWRAP>SMP -> IOP</TH> | |
| <TD> | |
| The SMP closes the file descriptor, and if the descriptor is that of | |
| the comminucation session with an IOP, it too is terminated. | |
| </TD> | |
| </TR> | |
| <TR><TH VALIGN=TOP NOWRAP>IOP</TH> | |
| <TD> | |
| If the IOP detects that its communication session with an SMP | |
| has closed, it will terminate any monitoring in progress, | |
| release any resources and close its end of the session. | |
| It will not maintain persistance of any information or prior mode of operation. | |
| </TD> | |
| </TR> | |
| </TABLE></TD></TR> | |
| </TABLE> | |
| </UL> | |
| <P> | |
| <H3>SMP/IOP Inter-Process Communication Protocol</H3> | |
| <UL> | |
| <LI><P>Communications between an SMP and an IOP consists of a TCP session | |
| between an ephemeral port on the SMP and the well known port of 49152 | |
| (which is the first available port in the 'dynamic and/or private port' | |
| range) on an IOP. | |
| <LI><P>Following a TCP open operation the IOP receives a null terminated | |
| 'interface ID' string to determine the type of operation that follows: | |
| <LI><P>Every command received by an IOP implies a 'stop trace/stop forwarding' operation must | |
| occur before executing the received command. | |
| <LI><P>A session is closed when the SMP closes the TCP session with the IOP. | |
| Obviously monitoring and forwarding is also stopped at that time. | |
| <B>Note: </B>All multi-octet entities are sent in network neutral order. | |
| <P> | |
| <TABLE BORDER=0 CELLSPACING=0 CELLPADDING=5> | |
| <TR><TH COLSPAN=3><HR WIDTH=100%></TH></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=6>pcap_findalldevs()</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>SMP -> IOP</TD> | |
| <TD VALIGN=TOP>Open socket (to each IOP), and sends: | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TH VALIGN=TOP ALIGN=CENTER>Name/<BR>Purpose</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER NOWRAP>Size<BR>(in bytes)</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Description</TH> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>Interface ID</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>A NULL to indicate an an empty 'interface ID'.</TD> | |
| </TR> | |
| </TABLE> | |
| </TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>IOP -> SMP</TD> | |
| <TD VALIGN=TOP>Send its (possibly empty) NULL terminated error response string.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>SMP -> IOP</TD> | |
| <TD VALIGN=TOP>Sends the 'interface query request': | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TH VALIGN=TOP ALIGN=CENTER>Name/<BR>Purpose</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER NOWRAP>Size<BR>(in bytes)</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Description</TH> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>Interface ID</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>A 'Q' (indicating 'interface query request').</TD> | |
| </TR> | |
| </TABLE> | |
| </TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>IOP -> SMP</TD> | |
| <TD VALIGN=TOP>The IOP returns a list of sequences of information as | |
| defined by the return parameter of this function call (as shown in the following table). | |
| Elements are specified by providing an unsigned byte preceeding the actual data that contains length information. | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TH VALIGN=TOP ALIGN=CENTER>Notes:</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Name/<BR>Purpose</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER NOWRAP>Size<BR>(in bytes)</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Description</TH> | |
| </TR> | |
| <TR> | |
| <TD ROWSPAN=7> </TD> | |
| <TD VALIGN=TOP ALIGN=RIGHT>length</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>The number of octets in the name field that follows.</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=LEFT>Name</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1-255</TD> | |
| <TD VALIGN=TOP>The name of the interface. The format of the name is an alphabetic string (indicating | |
| the type of interface) followed by an optional numeric string (indicating the interface's | |
| sequence number). | |
| Sequence numbers (if needed) will begin at zero and progress monotonically upwards. | |
| (i.e. 'eth0', 'lo', 'wan0', etc.) | |
| <P> | |
| For an IOP, the alphabetic string will be one of: 'eth', 'wan', and 'lo' | |
| for Ethernet, WAN ports and the IP loopback device respectively. | |
| An IOP currently supports: 'eth0', 'eth1', 'lo', 'wan0' ... 'wan7'. | |
| <P> | |
| <B>Note:</B> IOPs and ACNs will not currently support the concept of 'any' interface.</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=RIGHT>length</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>The number of octets in the interface description field that follows.</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=LEFT>Interface Description</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>0-255</TD> | |
| <TD VALIGN=TOP>A description of the interface or it may be an empty string. (i.e. 'ALC')</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=LEFT>Interface Type</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>4</TD> | |
| <TD VALIGN=TOP>The type of interface as defined in the description for pcap_datalink() (in network neutral order).</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=LEFT>Loopback Flag</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>1 = if the interface is a loopback interface, zero = otherwise.</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=RIGHT>count</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP># of address entries that follow. | |
| Each entry is a series of bytes in network neutral order. | |
| See the parameter definition above for more details.</TD> | |
| </TR> | |
| <TR> | |
| <TD ALIGN=CENTER ROWSPAN=8 WIDTH=1%>Repeated 'count' number of times.</TD> | |
| <TD VALIGN=TOP ALIGN=RIGHT>length</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>The number of octets in the address field that follows.</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=LEFT>Address</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1-255</TD> | |
| <TD VALIGN=TOP>The address of this interface (in network neutral order).</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=RIGHT>length</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>The number of octets in the netmask field that follows.</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=LEFT>Network Mask</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>0-255</TD> | |
| <TD VALIGN=TOP>The network mask used on this interface (if applicable) (in network neutral order).</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=RIGHT>length</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>The number of octets in the broadcast address field that follows.</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=LEFT>Broadcast Address</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>0-255</TD> | |
| <TD VALIGN=TOP>The broadcast address of this interface (if applicable) (in network neutral order).</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=RIGHT>length</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>The number of octets in the destination address field that follows.</TD> | |
| </TR> | |
| <TR><TD VALIGN=TOP ALIGN=LEFT>Destination Address</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>0-255</TD> | |
| <TD VALIGN=TOP>The destination address of this interface (if applicable) (in network neutral order).</TD> | |
| </TR> | |
| </TABLE> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>SMP -> IOP</TD> | |
| <TD VALIGN=TOP>Close the socket.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>IOP -> SMP</TD> | |
| <TD VALIGN=TOP>Close the socket.</TD> | |
| </TR> | |
| <TR><TH COLSPAN=3><HR WIDTH=100%></TH></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2>pcap_open_live()</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>SMP -> IOP</TD> | |
| <TD VALIGN=TOP>Open socket, and sends: | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TH VALIGN=TOP ALIGN=CENTER>Name/<BR>Purpose</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER NOWRAP>Size<BR>(in bytes)</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Description</TH> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>Interface ID</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>'n'</TD> | |
| <TD VALIGN=TOP>'n' octets containing a NULL terminated interface name string.</TD> | |
| </TR> | |
| </TABLE> | |
| </TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>IOP -> SMP</TD> | |
| <TD VALIGN=TOP>Send its NULL terminated error response string.</TD> | |
| </TR> | |
| <TR><TH COLSPAN=3><HR WIDTH=100%></TH></TR> | |
| <TR> | |
| <TD VALIGN=TOP NOWRAP ROWSPAN=2>pcap_dispatch()<BR>pcap_loop()<BR>pcap_next()<BR>pcap_next_ex()</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>SMP -> IOP</TD> | |
| <TD VALIGN=TOP>On the first invocation following a pcap_open_live() or pcap_breakloop() additional information is sent: | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TH VALIGN=TOP ALIGN=CENTER>Name/<BR>Purpose</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER NOWRAP>Size<BR>(in bytes)</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Description</TH> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>command</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>'M' (indicating 'monitor start')</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>snaplen</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>4</TD> | |
| <TD VALIGN=TOP>snaplen</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>timeout</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>timeout value (in milliseconds)</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>promiscuous</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>A flag indicating that the interface being monitored show operate | |
| in promiscuous mode. [off(0) / on(NZ)]</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>direction</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>A flag indicating the direction of traffic that should be captuted [both(0) / in(1) / out(2)]</TD> | |
| </TR> | |
| </TABLE> | |
| </TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>IOP -> SMP</TD> | |
| <TD VALIGN=TOP>Sends captured packets.</TD> | |
| </TR> | |
| <TR><TH COLSPAN=3><HR WIDTH=100%></TH></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2>pcap_setfilter()</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>SMP -> IOP</TD> | |
| <TD VALIGN=TOP>At any time, the SMP can issue a set filter command which contains | |
| an indicator, a count of the number of statements in the filter, | |
| followed by the sequence of filter commands represented as a sequence | |
| of C-style structures. | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TH VALIGN=TOP ALIGN=CENTER>Name/<BR>Purpose</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER NOWRAP>Size<BR>(in bytes)</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Description</TH> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>command</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>'F' (indicating 'filter')</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>count</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>4</TD> | |
| <TD VALIGN=TOP>The number of command in the Berkeley Packet Filter that follow.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>BPF program</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>'n'</TD> | |
| <TD VALIGN=TOP>8 bytes of each command (repeated 'n' times).<BR> | |
| Each command consists of that C-style structure which contains: | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TH VALIGN=TOP ALIGN=CENTER>Name/<BR>Purpose</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER NOWRAP>Size<BR>(in bytes)</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Description</TH> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>opcode</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>2</TD> | |
| <TD VALIGN=TOP>The command's opcode.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>'jt'</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>The 'jump if true' program counter offset.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>'jf'</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>The 'jump if false' program counter offset.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>'k'</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>4</TD> | |
| <TD VALIGN=TOP>The 'other' data field.</TD> | |
| </TR> | |
| </TABLE> | |
| <P> | |
| Refer to the bpf(4) man page for more details. | |
| </TD> | |
| </TR> | |
| </TABLE> | |
| </TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>IOP -> SMP</TD> | |
| <TD VALIGN=TOP>In return the IOP will send its (possibly empty) NULL terminated error response string.</TD> | |
| </TR> | |
| <TR><TH COLSPAN=3><HR WIDTH=100%></TH></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=2>pcap_stats()</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>SMP -> IOP</TD> | |
| <TD VALIGN=TOP>At any time, the SMP can issue a 'retrieve statistics' command which contains:<BR> | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TH VALIGN=TOP ALIGN=CENTER>Name/<BR>Purpose</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER NOWRAP>Size<BR>(in bytes)</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Description</TH> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>command</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>1</TD> | |
| <TD VALIGN=TOP>'S' (indicating 'request statistics')</TD> | |
| </TR> | |
| </TABLE> | |
| </TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>IOP -> SMP</TD> | |
| <TD VALIGN=TOP>In return the IOP will send: | |
| <P> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TH VALIGN=TOP ALIGN=CENTER>Name/<BR>Purpose</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER NOWRAP>Size<BR>(in bytes)</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Description</TH> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>ps_recv</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>4</TD> | |
| <TD VALIGN=TOP>The number of packets that passed the filter.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>ps_drop</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>4</TD> | |
| <TD VALIGN=TOP>The number of packets that were dropped because the input queue was full, | |
| regardless of whether they passed the filter.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>ps_ifdrop</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER>4</TD> | |
| <TD VALIGN=TOP>The number of packets dropped by the network inteface | |
| (regardless of whether they would have passed the input filter).</TD> | |
| </TR> | |
| </TABLE> | |
| </TD> | |
| </TR> | |
| <TR><TH COLSPAN=3><HR WIDTH=100%></TH></TR> | |
| <TR> | |
| <TD VALIGN=TOP ROWSPAN=1>pcap_close()</TD> | |
| <TD VALIGN=TOP ALIGN=CENTER NOWRAP>SMP -> IOP</TD> | |
| <TD VALIGN=TOP>At any time, the SMP can close the TCP session with the IOP.</TD> | |
| </TR> | |
| <TR><TH COLSPAN=3><HR WIDTH=100%></TH></TR> | |
| </TABLE> | |
| </UL> | |
| <H3>Interface ID Naming Convention</H3> | |
| <UL> | |
| Each interface within an IOP will be referred to uniquely. Since an currently contains | |
| 8 monitorable WAN ports and a monitorable Ethernet port, the naming convention is: | |
| <P> | |
| <CENTER> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR><TH>Interface #</TH> <TH>Type</TH> <TH>Name</TH></TR> | |
| <TR><TD ALIGN=CENTER>1</TD> <TD ALIGN=CENTER>WAN</TD> <TD ALIGN=CENTER>wan0</TD></TR> | |
| <TR><TD ALIGN=CENTER>2</TD> <TD ALIGN=CENTER>WAN</TD> <TD ALIGN=CENTER>wan1</TD></TR> | |
| <TR><TD ALIGN=CENTER>3</TD> <TD ALIGN=CENTER>WAN</TD> <TD ALIGN=CENTER>wan2</TD></TR> | |
| <TR><TD ALIGN=CENTER>4</TD> <TD ALIGN=CENTER>WAN</TD> <TD ALIGN=CENTER>wan3</TD></TR> | |
| <TR><TD ALIGN=CENTER>5</TD> <TD ALIGN=CENTER>WAN</TD> <TD ALIGN=CENTER>wan4</TD></TR> | |
| <TR><TD ALIGN=CENTER>6</TD> <TD ALIGN=CENTER>WAN</TD> <TD ALIGN=CENTER>wan5</TD></TR> | |
| <TR><TD ALIGN=CENTER>7</TD> <TD ALIGN=CENTER>WAN</TD> <TD ALIGN=CENTER>wan6</TD></TR> | |
| <TR><TD ALIGN=CENTER>8</TD> <TD ALIGN=CENTER>WAN</TD> <TD ALIGN=CENTER>wan7</TD></TR> | |
| <TR><TD ALIGN=CENTER>9</TD> <TD ALIGN=CENTER>Ethernet</TD> <TD ALIGN=CENTER>eth0</TD></TR> | |
| <TR><TD ALIGN=CENTER>10</TD> <TD ALIGN=CENTER>Ethernet</TD> <TD ALIGN=CENTER>eth1</TD></TR> | |
| </TABLE> | |
| </CENTER> | |
| </UL> | |
| <H3>Packet Trace Data Format</H3> | |
| <UL> | |
| The format of the trace data that is sent to the SMP follows a portion of the libpcap file format | |
| and is summarized here. This format specifies the generic requirements needed to | |
| be able to decode packets, but does not cover ACN specifics such as custom MAC addressing | |
| and WAN protocol support. | |
| <P> | |
| Although a libpcap file begins with a global header followed by zero or | |
| more records for each captured packet, trace data sent to the SMP does NOT begin with a global header. | |
| A trace sequence looks like this: | |
| <P> | |
| <TABLE> | |
| <TR> | |
| <TD STYLE="background-color: #c0FFc0"> [Packet Header] </TD> | |
| <TD STYLE="background-color: #c0FFc0"> [Packet Data] </TD> | |
| <TD STYLE="background-color: #c0c0FF"> [Packet Header] </TD> | |
| <TD STYLE="background-color: #c0c0FF"> [Packet Data] </TD> | |
| <TD STYLE="background-color: #e0c0c0"> [Packet Header] </TD> | |
| <TD STYLE="background-color: #e0c0c0"> [Packet Data] </TD> | |
| <TD>...</TD> | |
| </TR> | |
| </TABLE> | |
| <H4>Packet Header</H4> | |
| <UL> | |
| Each captured packet starts with a header that contains the following values | |
| (in network neutral order): | |
| <FONT SIZE=-1> | |
| <PRE> | |
| uint32 tv_sec; /* timestamp seconds */ | |
| uint32 tv_usec; /* timestamp microseconds */ | |
| uint32 caplen; /* number of octets in the following packet */ | |
| uint32 len; /* original length of packet on the wire */ | |
| </PRE> | |
| </FONT> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> | |
| <TD VALIGN=TOP>tv_sec</TD> | |
| <TD>The date and time when this packet was captured. | |
| This value is in seconds since January 1, 1970 00:00:00 GMT; | |
| this is also known as a UN*X time_t. You can use the ANSI C | |
| <em>time()</em> function from <em>time.h</em> to get this value, | |
| but you might use a more optimized way to get this timestamp value. | |
| If this timestamp isn't based on GMT (UTC), use <em>thiszone</em> | |
| from the global header for adjustments.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>tv_usec</TD> | |
| <TD>The microseconds when this packet was captured, as an offset to <em>ts_sec</em>. | |
| <B>Beware: </B>this value must never reach 1 second (1,000,000), | |
| in this case <em>ts_sec</em> must be increased instead!</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>caplen</TD> | |
| <TD>The number of bytes actually provided in the capture record. | |
| This value should never become larger than <em>len</em> or the | |
| <em>snaplen</em> value specified during the capture.</TD> | |
| </TR> | |
| <TR> | |
| <TD VALIGN=TOP>len</TD> | |
| <TD>The length of the packet "on the wire" when it was captured. | |
| If <em>caplen</em> and <em>len</em> differ, the actually | |
| saved packet size was limited by the value of <em>snaplen</em> specified | |
| during one of the capture directives such as pcap_dispatch().</TD> | |
| </TR> | |
| </TABLE> | |
| </UL> | |
| <H4>Packet Data</H4> | |
| <UL> | |
| The actual packet data will immediately follow the packet header as a sequence of <em>caplen</em> octets. | |
| Depending on the DLT encoding number assigned to the interface, the packet data will contain an additional | |
| custom header used to convey WAN port related information. | |
| </UL> | |
| <H4>ACN Custom Packet Header</H4> | |
| <UL> | |
| PCAP, Wireshark and Tcpdump enhancements have been added to the ACN to support | |
| monitoring of its ports, however each of these facilities were focused on capturing | |
| and displaying traffic from LAN interfaces. The SITA extentions to these facilities | |
| are used to also provide the ability to capture, filter, and display information from | |
| an ACN's WAN ports. | |
| <P> | |
| Although each packet follows the standard libpcap format, since there are | |
| two types of interfaces that can be monitored, the format of the data | |
| packet varies slightly. | |
| <P> | |
| <UL TYPE=DISC> | |
| <LI>For Ethernet (like) devices, the packet format is unchanged from the standard Pcap format. | |
| <LI>For WAN devices, the packet contains a 5 byte header that preceeds the actual captured data | |
| described by the following table: | |
| </UL> | |
| <P> | |
| <CENTER> | |
| <TABLE BORDER=1 CELLSPACING=0 CELLPADDING=3> | |
| <TR> <TH>Octet</TH> | |
| <TH>Name</TH> | |
| <TH>Mask/Value</TH> | |
| <TH COLSPAN=2>Definition</TH> </TR> | |
| <TR> <TH VALIGN=TOP ALIGN=CENTER ROWSPAN=3>0</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER ROWSPAN=3>Control / Status</TH> | |
| <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxxxx0</FONT></TD> | |
| <TD>Transmitted by capture device</TD> | |
| <TD ROWSPAN=2 ALIGN=CENTER>(see 'Errors' octets)</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxxxx1</FONT></TD> | |
| <TD>Received by capture device</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">1xxxxxxx</FONT></TD> | |
| <TD COLSPAN=2>No buffer was available during capture of previous packet.</TD> </TR> | |
| <TR> <TH VALIGN=TOP ALIGN=CENTER ROWSPAN=8>1</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER ROWSPAN=8>Signals</TH> | |
| <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxxxx1</FONT></TD> <TD COLSPAN=2>DSR asserted</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxxx1x</FONT></TD> <TD COLSPAN=2>DTR asserted</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxx1xx</FONT></TD> <TD COLSPAN=2>CTS asserted</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxx1xxx</FONT></TD> <TD COLSPAN=2>RTS asserted</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxx1xxxx</FONT></TD> <TD COLSPAN=2>DCD asserted</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xx1xxxxx</FONT></TD> <TD COLSPAN=2>Undefined</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">x1xxxxxx</FONT></TD> <TD COLSPAN=2>Undefined</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">1xxxxxxx</FONT></TD> <TD COLSPAN=2>Undefined</TD> </TR> | |
| <TR> <TH VALIGN=TOP ALIGN=CENTER ROWSPAN=9>2</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER ROWSPAN=9>Errors<BR>(octet 1)</TH> | |
| <TH> </TH> <TH>Tx</TH> <TH>Rx</TH> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxxxx1</FONT></TD> <TD>Underrun</TD> <TD>Framing</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxxx1x</FONT></TD> <TD>CTS Lost</TD> <TD>Parity</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxx1xx</FONT></TD> <TD>UART Error</TD> <TD>Collision</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxx1xxx</FONT></TD> <TD>Re-Tx Limit Reached</TD> <TD>Long Frame</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxx1xxxx</FONT></TD> <TD>Undefined</TD> <TD>Short Frame</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xx1xxxxx</FONT></TD> <TD>Undefined</TD> <TD>Undefined</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">x1xxxxxx</FONT></TD> <TD>Undefined</TD> <TD>Undefined</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">1xxxxxxx</FONT></TD> <TD>Undefined</TD> <TD>Undefined</TD> </TR> | |
| <TR> <TH VALIGN=TOP ALIGN=CENTER ROWSPAN=9>3</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER ROWSPAN=9>Errors<BR>(octet 2)</TH> | |
| <TH> </TH> <TH>Tx</TH> <TH>Rx</TH> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxxxx1</FONT></TD> <TD>Undefined</TD> <TD>Non-Octet Aligned</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxxx1x</FONT></TD> <TD>Undefined</TD> <TD>Abort Received</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxxx1xx</FONT></TD> <TD>Undefined</TD> <TD>CD Lost</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxxx1xxx</FONT></TD> <TD>Undefined</TD> <TD>Digital PLL Error</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xxx1xxxx</FONT></TD> <TD>Undefined</TD> <TD>Overrun</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">xx1xxxxx</FONT></TD> <TD>Undefined</TD> <TD>Frame Length Violation</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">x1xxxxxx</FONT></TD> <TD>Undefined</TD> <TD>CRC Error</TD> </TR> | |
| <TR> <TD VALIGN=TOP ALIGN=CENTER><FONT FACE="COURIER">1xxxxxxx</FONT></TD> <TD>Undefined</TD> <TD>Break Received</TD> </TR> | |
| <TR> <TH VALIGN=TOP ALIGN=CENTER ROWSPAN=12>4</TH> | |
| <TH VALIGN=TOP ALIGN=CENTER>Protocol</TH> | |
| <TD COLSPAN=3> | |
| <CENTER> | |
| <TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x01</TD> <TD>-</TD> <TD>LAPB (BOP) <SUP> </SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x02</TD> <TD>-</TD> <TD>Ethernet <SUP>1</SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x03</TD> <TD>-</TD> <TD>Async (Interrupt IO) <SUP> </SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x04</TD> <TD>-</TD> <TD>Async (Block IO) <SUP> </SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x05</TD> <TD>-</TD> <TD>IPARS <SUP> </SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x06</TD> <TD>-</TD> <TD>UTS <SUP> </SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x07</TD> <TD>-</TD> <TD>PPP (HDLC) <SUP> </SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x08</TD> <TD>-</TD> <TD>SDLC <SUP> </SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x09</TD> <TD>-</TD> <TD>Token Ring <SUP>1</SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x10</TD> <TD>-</TD> <TD>I2C <SUP> </SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x11</TD> <TD>-</TD> <TD>DPM Link <SUP> </SUP> </TD> </TR> | |
| <TR VALIGN=BOTTOM><TD ALIGN=CENTER>0x12</TD> <TD>-</TD> <TD>Frame Relay (BOP) <SUP> </SUP> </TD> </TR> | |
| </TABLE> | |
| </CENTER> | |
| <P> | |
| <STRONG>Note 1:</STRONG> | |
| Ethernet and Token Ring frames will never be sent as DLT_SITA (with the 5 octet header), | |
| but will be sent as their corresponding DLT types instead. | |
| </TD> | |
| </TR> | |
| </TABLE> | |
| </CENTER> | |
| </UL> | |
| <P> | |
| </UL> | |
| </UL> |