Suricata IDS problems (pcap_dump_fopen) with recent Npcap versions

[fyodor]

Update: Our suspicion is that this libpcap change may be the cause of the problem. Since libpcap changed the function into a compiler macro, code which uses it will need to be recompiled with latest headers (such as Npcap SDK) in order to continue using it. We may want to talk to Suricata folks about using newer headers for next version. This could also be a good chance for them to update to native Npcap API, if desired.

I haven't fully investigated this yet, but am hearing reports of people having trouble running the free and open source Suricata IDS with recent versions of Npcap, even when older versions worked. There is an example report here or the error "can not find pcap_dump_open". I am checking whether there are other error messages. The person who reported it to me said that he had enable WinPcap compatability mode (which is apparently requried for Suricata to use Npcap). I installed Suricata 4.1.5 and did not see the WinPcap DLLs in the Suricata directly, but it's possible they were installed somewhere else. I haven't tried running it quite yet. We should test with Suricata and/or communicate with the project to ensure solid Npcap support. Ideally, Suricata would support Npcap native mode (it could still support Winpcap too).

[guyharris]

See the-tcpdump-group/libpcap#805 for the full sad story behind that change, and see the-tcpdump-group/libpcap#806 for the change.

The sooner the Universal CRT can smash the previous versions of the C runtime into the ground, plow the ground, and salt it, the better.

Until then, I guess libraries for Windows have to worry about FILE *'s being passed around (and about stuff allocated in the library and freed in something that might be compiled with a different VC version, or something such as that); hopefully FDs are just integers and it doesn't matter if the internal library data structures to which they refer can change without problems.