Opening a WinPcap Compatible Network Interface

Sometimes a network interface is WinPcap compatible meaning it can be opened with WinPcap, but opening it with the methods found in the example code for developers can fail. The examples usually show opening the interface using the PCAP_OPENFLAG_PROMISCUOUS. While that normally works fine for wired interfaces, wireless interfaces (WiFi 802.11) may not open - in fact according to a Winpcap-users post from 2008 regarding v4, "most of the wireless cards do not support promiscuous mode. The call to pcap_open with PCAP_OPENFLAG_PROMISCUOUS should fail" - see http://www.winpcap.org/pipermail/winpcap-users/2008-June/002532.html

Here is typical code from the examples:

pcap_t *hDev = pcap_open(deviceName, 65536, PCAP_OPENFLAG_PROMISCUOUS, 1000, NULL, errMsg1);

If it fails to open because the interface cannot support promiscuous mode, hDev is NULL and errMsg1 will contain a string like this: "failed to set hardware filter to promiscuous mode".

A good way of dealing with this is to first try opening the interface, then if hDev is NULL try opening it without the flag:

hDev = pcap_open(deviceName, 65536, 0, 1000, NULL, errMsg2);

Then if hDev is still NULL, report both errMsg1 and errMsg2 to the user. If they both fail you will need to avoid doing any further winpcap function calls except to do pcap_freealldevs because you most likely uses pcap_findalldevs_ex before trying to open an interface and it allocates the device list from which deviceName was found.

Why is opening an interface in promiscuous mode important? When a network interface card (NIC) is opened in promiscuous mode, all packets seen by the interface are captured and passed to the host system, while an interface opened normally only captures packets strictly intended for it alone. So if you are running a utility like NetScanTools Pro Packet Capture or Wireshark, you will most likely want to be running in promiscuous mode so you can see all the packets passing by the interface.

Applicability:
WinPcap v4.1.3 is the most current version as of this discussion. Please visit http://www.winpcap.org/

Release != Debug: strange C++ problem

I've been working on the new Managed Switch Port Mapping Tool v2 quite a bit lately and ran into a strange problem: one function in the program (saving to an XML file) was causing it to hang up in Release mode, but never in Debug mode. The program imported three static libraries, one is the BCGSoft 18 library (cool stuff), another is the CodeProject Ultimate Grid (I'm the KVT in the source code notes) and the last is the CodeProject Ultimate Toolbox. Of the three, the BCGSoft libary is the most recent addition. This problem never happened in 1.99.9.8 and it doesn't use the BCGSoft library.

The first thing I did was convert the Release version code for all of them so that it included Debug info. That was a bit tedious, but went OK. Then I was able to press the Save button and step through to see where it was hanging up. That didn't go so well. It would hang up in different places. It seemed to be a stack or memory issue. I tried increasing stack and heap in the main executable, but it didn't help.

Finally after 5 hours, I decided to look and see just how much of the Ultimate Toolbox library I was actually using. It turns out I was only using the OXParser and OXRegistryItem. By moving them and their supporting files (roughly 6 other cpp and h) into the main executable, I was able to remove the linkage to the UTlibStaticR. I suspect that the BCGSoft library has some functions with the same name as Ultimate Toolbox, but I wasn't going to look through pages and pages of import listings to see wheich ones. Eliminating the library was simpler. And, yes, I put back the normal release settings to remove debugging from the release version and it works fine now.