944 lines
37 KiB
HTML
944 lines
37 KiB
HTML
<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>
|