group__wpcapfunc.html

WinPcap V4.01技术手册

Accept a set of strings (host name, port, ...), and it returns the complete source string according to the new format (e.g. 'rpcap://1.2.3.4/eth0'). 
<p>
This function is provided in order to help the user creating the source string according to the new format. An unique source string is used in order to make easy for old applications to use the remote facilities. Think about tcpdump, for example, which has only one way to specify the interface on which the capture has to be started. However, GUI-based programs can find more useful to specify hostname, port and interface name separately. In that case, they can use this function to create the source string before passing it to the <a class="el" href="group__wpcapfunc.html#g2b64c7b6490090d1d37088794f1f1791">pcap_open()</a> function.<p>
<dl compact><dt><b>Parameters:</b></dt><dd>
  <table border="0" cellspacing="2" cellpadding="0">
    <tr><td valign="top"></td><td valign="top"><em>source,:</em>&nbsp;</td><td>a user-allocated buffer that will contain the complete source string wen the function returns.<br>
 The source will start with an identifier according to the new <a class="el" href="group__remote__source__string.html">Source Specification Syntax </a>.<br>
 This function assumes that the allocated buffer is at least PCAP_BUF_SIZE bytes.</td></tr>
    <tr><td valign="top"></td><td valign="top"><em>type,:</em>&nbsp;</td><td>its value tells the type of the source we want to create. It can assume the values defined in the <a class="el" href="group__remote__source__ID.html">Source identification Codes </a>.<br>
</td></tr>
    <tr><td valign="top"></td><td valign="top"><em>host,:</em>&nbsp;</td><td>an user-allocated buffer that keeps the host (e.g. "foo.bar.com") we want to connect to. It can be NULL in case we want to open an interface on a local host.</td></tr>
    <tr><td valign="top"></td><td valign="top"><em>port,:</em>&nbsp;</td><td>an user-allocated buffer that keeps the network port (e.g. "2002") we want to use for the RPCAP protocol. It can be NULL in case we want to open an interface on a local host.</td></tr>
    <tr><td valign="top"></td><td valign="top"><em>name,:</em>&nbsp;</td><td>an user-allocated buffer that keeps the interface name we want to use (e.g. "eth0"). It can be NULL in case the return string (i.e. 'source') has to be used with the <a class="el" href="group__wpcapfunc.html#g98f36e62c95c6ad81eaa8b2bbeb8f16e">pcap_findalldevs_ex()</a>, which does not require the interface name.</td></tr>
    <tr><td valign="top"></td><td valign="top"><em>errbuf,:</em>&nbsp;</td><td>a pointer to a user-allocated buffer (of size PCAP_ERRBUF_SIZE) that will contain the error message (in case there is one).</td></tr>
  </table>
</dl>
<dl class="return" compact><dt><b>Returns:</b></dt><dd>'0' if everything is fine, '-1' if some errors occurred. The string containing the complete source is returned in the 'source' variable.</dd></dl>
<dl class="warning" compact><dt><b>Warning:</b></dt><dd>If the source is longer than PCAP_BUF_SIZE, the excess characters are truncated. </dd></dl>

</div>
</div><p>
<a class="anchor" name="g64c019f851f7da6892d51cca15f12ace"></a><!-- doxytag: member="funcs/pcap.h::pcap_datalink" ref="g64c019f851f7da6892d51cca15f12ace" args="(pcap_t *p)" -->
<div class="memitem">
<div class="memproto">
      <table class="memname">
        <tr>
          <td class="memname">int pcap_datalink           </td>
          <td>(</td>
          <td class="paramtype"><a class="el" href="group__wpcap__def.html#g4711d025f83503ce692efa5e45ec60a7">pcap_t</a> *&nbsp;</td>
          <td class="paramname"> <em>p</em>          </td>
          <td>&nbsp;)&nbsp;</td>
          <td width="100%"></td>
        </tr>
      </table>
</div>
<div class="memdoc">

<p>
Return the link layer of an adapter. 
<p>
returns the link layer type; link layer types it can return include:<p>
<ul>
<li>DLT_NULL BSD loopback encapsulation; the link layer header is a 4-byte field, in host byte order, containing a PF_ value from socket.h for the network-layer protocol of the packet. Note that ``host byte order'' is the byte order of the machine on which the packets are captured, and the PF_ values are for the OS of the machine on which the packets are captured; if a live capture is being done, ``host byte order'' is the byte order of the machine capturing the packets, and the PF_ values are those of the OS of the machine capturing the packets, but if a ``savefile'' is being read, the byte order and PF_ values are not necessarily those of the machine reading the capture file.</li><li>DLT_EN10MB Ethernet (10Mb, 100Mb, 1000Mb, and up)</li><li>DLT_IEEE802: IEEE 802.5 Token Ring</li><li>DLT_ARCNET: ARCNET</li><li>DLT_SLIP: SLIP; the link layer header contains, in order:<ol type=a>
<li>a 1-byte flag, which is 0 for packets received by the machine and 1 for packets sent by the machine;</li><li>a 1-byte field, the upper 4 bits of which indicate the type of packet, as per RFC 1144:<ul>
<li>0x40: an unmodified IP datagram (TYPE_IP);</li><li>0x70: an uncompressed-TCP IP datagram (UNCOMPRESSED_TCP), with that byte being the first byte of the raw IP header on the wire, containing the connection number in the protocol field;</li><li>0x80: a compressed-TCP IP datagram (COMPRESSED_TCP), with that byte being the first byte of the compressed TCP/IP datagram header;</li></ul>
</li><li>for UNCOMPRESSED_TCP, the rest of the modified IP header, and for COMPRESSED_TCP, the compressed TCP/IP datagram header;</li><li>for a total of 16 bytes; the uncompressed IP datagram follows the header.</li></ol>
</li></ul>
<p>
<ul>
<li>DLT_PPP: PPP; if the first 2 bytes are 0xff and 0x03, it's PPP in HDLC-like framing, with the PPP header following those two bytes, otherwise it's PPP without framing, and the packet begins with the PPP header.</li><li>DLT_FDDI: FDDI</li><li>DLT_ATM_RFC1483: RFC 1483 LLC/SNAP-encapsulated ATM; the packet begins with an IEEE 802.2 LLC header.</li><li>DLT_RAW: raw IP; the packet begins with an IP header.</li><li>DLT_PPP_SERIAL: PPP in HDLC-like framing, as per RFC 1662, or Cisco PPP with HDLC framing, as per section 4.3.1 of RFC 1547; the first byte will be 0xFF for PPP in HDLC-like framing, and will be 0x0F or 0x8F for Cisco PPP with HDLC framing.</li><li>DLT_PPP_ETHER: PPPoE; the packet begins with a PPPoE header, as per RFC 2516.</li><li>DLT_C_HDLC: Cisco PPP with HDLC framing, as per section 4.3.1 of RFC 1547.</li><li>DLT_IEEE802_11: IEEE 802.11 wireless LAN</li><li>DLT_FRELAY: Frame Relay</li><li>DLT_LOOP: OpenBSD loopback encapsulation; the link layer header is a 4-byte field, in network byte order, containing a PF_ value from OpenBSD's socket.h for the network-layer protocol of the packet. Note that, if a ``savefile'' is being read, those PF_ values are not necessarily those of the machine reading the capture file.</li><li>DLT_LINUX_SLL: Linux "cooked" capture encapsulation; the link layer header contains, in order:<ul>
<li>a 2-byte "packet type", in network byte order, which is one of:<ol type=i>
<li>packet was sent to us by somebody else</li><li>packet was broadcast by somebody else</li><li>packet was multicast, but not broadcast, by somebody else</li><li>packet was sent by somebody else to somebody else</li><li>packet was sent by us</li></ol>
</li><li>a 2-byte field, in network byte order, containing a Linux ARPHRD_ value for the link layer device type;</li><li>a 2-byte field, in network byte order, containing the length of the link layer address of the sender of the packet (which could be 0);</li><li>an 8-byte field containing that number of bytes of the link layer header (if there are more than 8 bytes, only the first 8 are present);</li><li>2-byte field containing an Ethernet protocol type, in network byte order, or containing 1 for Novell 802.3 frames without an 802.2 LLC header or 4 for frames beginning with an 802.2 LLC header.</li></ul>
</li><li>DLT_LTALK: Apple LocalTalk; the packet begins with an AppleTalk LLAP header.</li><li>DLT_PFLOG: OpenBSD pflog; the link layer header contains, in order:<ul>
<li>a 4-byte PF_ value, in network byte order;</li><li>a 16-character interface name;</li><li>a 2-byte rule number, in network byte order;</li><li>a 2-byte reason code, in network byte order, which is one of:<ol type=i>
<li>match</li><li>bad offset</li><li>fragment</li><li>short</li><li>normalize</li><li>memory -a 2-byte action code, in network byte order, which is one of:</li><li>passed</li><li>dropped</li><li>scrubbed</li></ol>
</li><li>a 2-byte direction, in network byte order, which is one of:<ol type=i>
<li>incoming or outgoing</li><li>incoming</li><li>outgoing</li></ol>
</li></ul>
</li><li>DLT_PRISM_HEADER: Prism monitor mode information followed by an 802.11 header.</li><li>DLT_IP_OVER_FC: RFC 2625 IP-over-Fibre Channel, with the link-layer header being the Network_Header as described in that RFC.</li><li>DLT_SUNATM: SunATM devices; the link layer header contains, in order:<ul>
<li>a 1-byte flag field, containing a direction flag in the uppermost bit, which is set for packets transmitted by the machine and clear for packets received by the machine, and a 4-byte traffic type in the low-order 4 bits, which is one of:<ol type=i>
<li>raw traffic</li><li>LANE traffic</li><li>LLC-encapsulated traffic</li><li>MARS traffic</li><li>IFMP traffic</li><li>ILMI traffic</li><li>Q.2931 traffic</li></ol>
</li><li>a 1-byte VPI value;</li><li>a 2-byte VCI field, in network byte order.</li></ul>
</li><li>DLT_IEEE802_11_RADIO: link-layer information followed by an 802.11 header - see <a href="http://www.shaftnet.org/~pizza/software/capturefrm.txt">http://www.shaftnet.org/~pizza/software/capturefrm.txt</a> for a description of the link-layer information.</li><li>DLT_ARCNET_LINUX: ARCNET, with no exception frames, reassembled packets rather than raw frames, and an extra 16-bit offset field between the destination host and type bytes.</li><li>DLT_LINUX_IRDA: Linux-IrDA packets, with a DLT_LINUX_SLL header followed by the IrLAP header.</li></ul>
<p>
<dl class="see" compact><dt><b>See also:</b></dt><dd><a class="el" href="group__wpcapfunc.html#g64e482360b0ed7d65fce1db23d56b921">pcap_list_datalinks()</a>, <a class="el" href="group__wpcapfunc.html#g9588b99ac118cf827873d9e941eb6c77">pcap_set_datalink()</a>, <a class="el" href="group__wpcapfunc.html#g440b2f0757acd4804588933324909207">pcap_datalink_name_to_val()</a> </dd></dl>

</div>
</div><p>
<a class="anchor" name="g440b2f0757acd4804588933324909207"></a><!-- doxytag: member="funcs/pcap.h::pcap_datalink_name_to_val" ref="g440b2f0757acd4804588933324909207" args="(const char *name)" -->
<div class="memitem">
<div class="memproto">
      <table class="memname">
        <tr>
          <td class="memname">int pcap_datalink_name_to_val           </td>
          <td>(</td>
          <td class="paramtype">const char *&nbsp;</td>
          <td class="paramname"> <em>name</em>          </td>
          <td>&nbsp;)&nbsp;</td>
          <td width="100%"></td>
        </tr>
      </table>
</div>
<div class="memdoc">

<p>
Translates a data link type name, which is a DLT_ name with the DLT_ removed, to the corresponding data link type value. The translation is case-insensitive. -1 is returned on failure. 
<p>

</div>
</div><p>
<a class="anchor" name="g3f142cd0694b49357e4a73371db71411"></a><!-- doxytag: member="funcs/pcap.h::pcap_datalink_val_to_description" ref="g3f142cd0694b49357e4a73371db71411" args="(int dlt)" -->
<div class="memitem">
<div class="memproto">
      <table class="memname">
        <tr>
          <td class="memname">const char* pcap_datalink_val_to_description           </td>
          <td>(</td>
          <td class="paramtype">int&nbsp;</td>
          <td class="paramname"> <em>dlt</em>          </td>
          <td>&nbsp;)&nbsp;</td>
          <td width="100%"></td>
        </tr>
      </table>
</div>
<div class="memdoc">

<p>
Translates a data link type value to a