/** @ingroup wpcap_tut
 */


/** @defgroup wpcap_tut3 Opening an adapter and capturing the packets
 *  @{

Now that we've seen how to obtain an adapter to play with, let's start the real job, opening the device and capturing the some traffic. In this lesson we'll write a program that will print some information for each packet flowing through the network.

The function that opens a capture device is pcap_open(). Among its parameters, \e snaplen, \e flags and \e to_ms deserve a better explanation. 

\e snaplen specifies the portion of the packet to capture. On some OSes (like xBSD and Win32), the packet driver gives the possibility to capture only the initial part of any packet: this decreases the amount of data to copy and therefore improves the efficiency of the capture. In this case we use a value (65536) higher than the greatest MTU that we could encounter, therefore we make sure that the application will always receive the whole packet.

\e flags: the most important flag is the one that indicates if the adapter will be put in promiscuous mode. In normal situations, an adapter extracts from the network only the traffic destined to it; the packets exchanged by other hosts are therefore ignored. Instead, when the adapter is in promiscuous mode it accepts the whole traffic: this means that on shared media (like non-switched Ethernet) WinPcap will be able to capture the packets of other hosts as well (provided that your network card is receiving them, e.g. you are not on a switched network). Promiscuous mode is the default for most capture applications, so we enable it in the following example.

\e to_ms specifies the read timeout, in milliseconds. A read on the adapter (for example with pcap_dispatch() or pcap_next_ex()) will always return after \e to_ms milliseconds, even if no packets are available from the network. Moreover, \e to_ms defines the interval between statistical report if the adapter is in statistical mode (see the lesson "\ref wpcap_tut9" for information about statistical mode). Setting \e to_ms to 0 means no timeout, a read on the adapter never returns if no packets arrive. A -1 timeout on the other side causes a read on the adapter to always return immediately.


\include misc/basic_dump.c

Once the adapter is opened, the capture can be started with pcap_dispatch() or pcap_loop(). These two functions are very similar, the difference is that pcap_ dispatch() is granted to return when the expires while pcap_loop() doesn't return until \e cnt packets have been captured, so it can block for an arbitrary period on an under-utilized network. pcap_loop() is enough for the purpose of this sample, while pcap_dispatch() is normally used in more complex program.

Both these functions have a \e callback parameter, pointing to a function that will receive the packets, packet_handler in this case. This function is invoked by libpcap for every new packet coming from the network and receives a generic status (corresponding to the \e user parameter of pcap_loop() and pcap_dispatch()), an header with some information on the packet like the timestamp and the length, and finally the actual data of the packet including all the protocol headers. Note that the MAC CRC is normally not present, because it is removed by the network adapter after frame validation. Note also that most adapters discard the packets with wrong CRC, therefore WinPcap is normally not able to capture them.

The just proposed example extracts the timestamp and the length of every packet from the pcap_pkthdr header and prints them on the screen.

Please note that using pcap_loop() could have some drawback, mostly related to the fact that the dispatcher handler is called by the packet capture driver; therefore the user application does not have control on it. To solve this problem (and to have simpler and more readable programs), we suggest using the pcap_next_ex(), which is presented in the next example (\ref wpcap_tut4).

\ref wpcap_tut2 "<<< Previous" \ref wpcap_tut4 "Next >>>"

@}*/
