WinPcap Do’s and Don’ts Wednesday, June 17 th , 2009 Gianluca Varenni Senior Software Engineer | CACE Technologies,

1. WinPcap Do’s and Don’ts Wednesday, June 17th, 2009 GianlucaVarenni Senior Software Engineer | CACE Technologies, Inc. WinPcapProduct Manager gianluca.varenni@cacetech.com SHARKFEST'09 Stanford University June 15-18, 2009

2. Agenda • Do’s and Don’ts • Tips and tricks • Open discussion/questions

3. Do’s and Don’ts

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.

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 Ethernet header IP header IP options L4 protocol 14 bytes 20 bytes 0 or more bytes

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

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

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.

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 // }

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!

11. Tips and tricks

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.

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).

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

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.

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?

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

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!

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.

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

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

22. Questions?