4. Packet reception Do NOT keep the packet pointers received from pcap_next_ex pcap_loop pcap_dispatch pcap_next in your own data structures. They are valid only up to the next call to pcap_next_ex. Copy the packets if needed. 4
5. Packet dissection Packets can be truncated. Be savvy when dissecting packets, check boundaries. If you receive a 30 bytes IP packet, the IP header is truncated! Do NOT assume that the headers have a fixed length! The IP header is 20 bytes when there are no options Compute the header length properly IP header Ethernet header IP options L4 protocol 14 bytes 20 bytes 0 or more bytes 5
6. Data link types Do NOT assume that the link type is Ethernet (DLT_EN10MB). Check the link type with pcap_datalink In case of wireless (AirPcap), three possible encapsulations Bare 802.11 (no meta-information) Per-Packet Information (PPI) Radiotap 6
7. Packet API Do NOT use it. No longer documented (it was a mistake) It can change between releases Do NOT access the npf.sys driver directly IOCTLs change over time Use the pcap API 7
8. WinPcap installation Do NOT create your custom WinPcap installer. It works most of the times on Windows XP x86. What about Vista x64 or NT4? It corrupts any existing installation. Debugging installation issues is a major pain. Solutions Official WinPcap installer. WinPcap Professional. 8
9. WinPcap and services You can use WinPcap in a service. You MUST call any WinPcap function after you have notified the SCM that the service is started. Alternatively, put “nm” and “npf” as service dependencies using ChangeServiceConfigwhen installing the service VOID ServiceStart (DWORD dwArgc, LPTSTR *lpszArgv) { // // perform any initialization here // DO NOT CALL WINPCAP HERE // SetServiceStatus( ....SERVICE_RUNNING...); // // Service is now running, perform work until shutdown // Start using WinPcap here // } 9
10. Kernel buffers Do NOT use large kernel buffers. It’s a cache for traffic spikes or app processing slowdowns. Kernel memory is a precious resource. 4-8 MB is ok in most cases (even at 1Gbps). Optimize your processing code! 10
12. Multiple devices support You can open the same device multiple times Within the same process. From the same or different threads. Each instance uses its own capture buffer and filter. Packets are replicated among instances. Be careful with pcap_compile. It’s not thread safe (as of WinPcap4.1beta5). Future versions will fix the issue. Use a critical section to protect the calls to pcap_compile. 12
13. Dumping to disk Disks are generally slow. Dumping all the packets to disk without losses is not trivial on high speed links. Solutions Dump just the first n bytes of a packet (snaplen). Filter packets. Dedicated disks (not partitions!). RAID 0 (striping). 13
14. Use pcap_next_ex Why? It’s much easier to use. Especially to stop capture. Do notuse pcap_loop/pcap_dispatch/pcap_next They are less immediate to use. pcap_next_ex is blocking It respects the timeout set in pcap_open_live 14
15. Timestamps They are generated in software after The packet has been received by the NIC The NIC has notified the OS about available packets (interrupt coalescing) The NIC driver has processed the packet and notified NDIS about the packet The precision is in the order of tens of microseconds in the best case. Do not rely on timestamps for critical measurements. 15
16. Responsiveness vs. performance Packets are received by the app when the timeout elapses or at least mintocopy bytes are in the kernel driver buffer (whatever comes first) Small read timeouts can affect performance Small mintocopy values can affect performance Do you really need to get the packets as soon as they arrive? 16
17. Devpack samples Use them as a reference Header files to include (or not) LIB files How to open/close an adapter or capture packets from it 17
18. GUI applications The UI needs to be responsive while capturing. Use a separate thread to capture (or inject) packets. Use messages for inter-thread communication. SendMessage PostMessage Do NOT touch the UI in the capture thread! 18
19. Wireless capture Most adapters (excluding AirPcap) do not support promiscuous/monitor mode It’s a limit of the hardware/NIC driver It’s not a limit of WinPcap Bug in WinPcap: it doesn’t detect lack of promiscuous support. Fixed in 4.1 betas. Ethernet “fake” frames. No management/control frames, no 802.11 headers. Vista native Wi-Fi drivers? Not really. 19
20. Privileges to run WinPcap Pretty weak security model Admin privileges are needed to Install WinPcap Start the driver at each reboot Change the driver start type to SERVICE_AUTO_START to have the driver started at boot time Once the driver is running, a standard user can capture/inject packets 20
21. WinPcap and .NET You need to create your own wrapper, or use an existing one No official wrappers No support for 3rd party ones Marshalling packet contents (without copies) is not trivial Some APIs (e.g. pcap_findalldevs) are not .NET friendly Use managed C++ to create your wrapper 21
