Comment 19 for bug 1758037

Debugging pcap_activate and pcap_create with and without
  <parameter name='CTRL_IP_LEARNING' value='dhcp'/>

TL;DR:
- Bad Case: fd stays at -1 on pcap_activate
- Good case: pcap_activate sets a valid fd = 27

They use very different paths.
Bad Case:
1.
pcap_create(ifname, pcap_errbuf);
  ifname = "vnet0"
  pcap_errbuf is a local char* of [PCAP_ERRBUF_SIZE];
2. pcap_set_snaplen(handle, PCAP_PBUFSIZE)
   PCAP_PBUFSIZE = 576 by nwfilter_dhcpsnoop.c:237
3. pcap_set_buffer_size(handle, PCAP_BUFFERSIZE)
   PCAP_BUFFERSIZE (128 * 1024) by nwfilter_dhcpsnoop.c:259
4. pcap_activate(handle)

Good Case:
- doesn't even hit virNWFilterSnoopDHCPOpen.
- It reaches the pacp functions via:

#0 pcap_activate (p=p@entry=0x7f3234000bb0) at ./pcap.c:775
#1 0x00007f3290684b4c in pcap_open_live (device=device@entry=0x7f3280017768 "vnet0", snaplen=snaplen@entry=8192, promisc=promisc@entry=0,
    to_ms=to_ms@entry=500, errbuf=errbuf@entry=0x7f3284b9fb70 "") at ./pcap.c:840
#2 0x00007f32908cb575 in learnIPAddressThread (arg=0x7f3280017760) at ../../../src/nwfilter/nwfilter_learnipaddr.c:413
#3 0x00007f32adaa9ad2 in virThreadHelper (data=<optimized out>) at ../../../src/util/virthread.c:206
#4 0x00007f32ad1536db in start_thread (arg=0x7f3284ba0700) at pthread_create.c:463
#5 0x00007f32ace7c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Maybe this does something different in between?

It does
1. pcap_create(device, errbuf);
same device string
same size of errbuf
2. pcap_set_snaplen(p, snaplen);
len is BUFSIZ which is stdio.h _IO_BUFSIZ (that is 8192 by
/usr/include/x86_64-linux-gnu/bits/_G_config.h:61:#define _G_BUFSIZ 8192)
3. pcap_set_promisc(p, promisc)
 with promisc being 0
4. pcap_set_timeout(p, to_ms)
 with timeout being 500
5. pcap_activate(p);
Before that p->oldstyle = 1; gets set.

Following comment for that assignment:
        /*
         * Mark this as opened with pcap_open_live(), so that, for
         * example, we show the full list of DLT_ values, rather
         * than just the ones that are compatible with capturing
         * when not in monitor mode. That allows existing applications
         * to work the way they used to work, but allows new applications
         * that know about the new open API to, for example, find out the
         * DLT_ values that they can select without changing whether
         * the adapter is in monitor mode or not.
         */

Could it be that the libvirt usage just is "oldstyle"?

I'm now trying to recreate that against a local build of master to patch the differences one by one hopefully finding the weak spot we could fix.